Bugzilla – Bug 5356
Browsing long lists doesn't work well
Last modified: 2011-11-06 23:24:10 UTC
I'm sure this is a well known problem, but I'm just putting it down again... When you have a large list of items, say 10,000 Artists, it's pretty much impossible to get to where you want to go. This needs to be resolved with intelligent scrolling, or with a smarter sorted list browser. Definitely not workable as-is. -Caleb
Navigation through long lists is a pain - it needs too much scrolling. I think it would be better if an intermediate A-Z level was introduced, so you could go My Music->Albums->B->Blue Lines (Massive Attack) etc. This could maybe be made nicer by making the intermediate A-Z 123 level appear as a pop-up overlay over the entire list. It could then slide in and out as needed. Demo session: My Music -> Albums -> A-Z 123 User scrolls to B and goes left, giving the whole list but with the first B entry selected User goes right, giving the whole A-Z 123 list with B selected
Max's suggestion is similar to how some mobile phones scroll through their lists of contacts. At first it scrolls through individual artists; then it switches to the first character. A good acceleration algorithm might be another option, but many people seem to disagree with that style. Max, if you're inclined, you could start a thread on our forums to discuss this issue. It's certainly something we'd like to solve in a way that our users like! If you do that, if you would put the url to the thread in a comment on this bug I would appreciate it.
Just found this bug. I'll add my $.02 having just toiled with the current scrolling on the jive device. The scroll wheel covers only eight entries in one revolution. If I have 350 items in a list (the number of artists I have in my rock/pop folder), that's 44 revolutions to get through the list. Simply increasing the scroll rate would help here. My 2g ipod nano click wheel which covers closer to 25 items on an average revolution from my thumb (it varies with the click wheel). But the ipod does even better acceleration over time - the more you turn, the faster it scrolls. I like that model ~much~ better than other options like adding an intermediate A..Z layer. Such a layer would obscure the available list entries. When I'm browsing a list of artists, for example, I ~do~ want to see all the artists, but I want to see them quickly. It's different than looking up a phone number in a cell phone where you know the name of the person before you start looking. When browsing, I don't know what artist I'm going to listen to - so I need to see them all in the list. I need to be able to scroll that long list quickly. Just my $.02, John
We'll be adding scrolling acceleration, stay tuned.
Ha ha, this is now a bug for myself :-)
*** Bug 5529 has been marked as a duplicate of this bug. ***
*** Bug 5817 has been marked as a duplicate of this bug. ***
Richard & Caleb: what's the status of this work? Are the hooks there for caleb to work on this?
Richard is working on this now.
Merged in the scrolling branch in r1380. This provides a significant improvement. Back to Caleb to work on the scrolling acceleration.
I'm lowering the severity of this bug due to the much improved scrolling behavior. CC'ed folks: can you try the latest code and comment on the current state? Richard: Can you point Caleb and me at the scrolling bottlenecks?
Richard: Can you point Caleb and me at the scrolling bottlenecks?
> CC'ed folks: can you try the latest code and comment on the current state? I find the new scrolling acceleration to be a huge improvment, but I suspect it's optimal usability will vary from person to person. For me, I would prefer to see the acceleration kick in more quickly and max out at a lower rate for smaller lists (a list with 1000 items should have a higher max speed than a list with only 100 items). Additionally, the acceleration is actually detrimental to navigating short lists (<25 items), so I think it shouldn't even be active in those lists. Also, I still have problems sometimes with the acceleration kicking out because I'm not turning the wheel at a steady enough rate. I think that covers my current gripes - overall I think it's well implemented.
Ping richard... I'd like to tweak the letter appearance a bit. Can you point us toward the bottlenecks? Then a more complete fix with Caleb's algorithm for 7.0.1.
richard says: look in pkg/jive/share/jive/ui/ScrollAccel. All the timings are in that class.
Ok, I fixed the last thing that was really bugging me about scrolling, namely the flashing appearance/disappearance of the big letter in change 1767. Punting the rest of this to 7.0.1 where Caleb's approach can be investigated.
*** Bug 7555 has been marked as a duplicate of this bug. ***
(In reply to comment #17) > *** Bug 7555 has been marked as a duplicate of this bug. I started the thread that resulted in bug 7555, and I don't think this is the same thing at all.
I agree, I've reopened bug 7555.
this won't make it into 7.1. retargetting for 7.2. a big task, but worth doing.
we need to improve the list browsing at some stage, but I've heard on complaints about the current implementation recently. re-targeting to future.
Richard is no longer available to us.
Unassigned bugs cannot have a priority.