PDA

View Full Version : Time taken to traverse menus



gerph
2007-10-17, 22:19
Hiya,

I'm pretty sure this has been discussed but 'something' needs to be done to simplify the traversal of long menus. Trying to scroll down the artists list on the remote from the start point (which is always the top, unlike the squeeze box display which remembers where you were last) to 'Pink Floyd' took me 38 seconds, measured by that scientifically accurate method known as 'counting in your head'.

Maybe a method that restricted the menu items to around 20 would help - not using the alphabet, because obviously there are more artists for some letters, but using the artist names. Let us say for the sake of argument that instead of 20 artists, we used 4 items as the top level menu (because I can work that out in my head, whereas working out 20 artists would hurt my little head).

The menu might have something like...

Around 'The Corrs'
Around 'INXS'
Around 'Prince'
Around 'The Verve'

(I've selected these so that they're at a useful position in the list; and not starting at the top. For simplicities sake I used 26/4 (because I want 4 items and I'm going to pick them from the latin alphabet 'cos I know it), then added half that as the starting point, so ASCII 64+3.25+6.5*0, 64+3.25+6.5*1, 64+3.25+6.5*2, 64+3.25+6.5*3, which gives me the letters to start at and then I just picked an artist starting with that letter. That's just my way of giving the example, but the same principle could be used to the entries in the list. The addition of half the multiple means that the 'around' points don't start at the beginning of the list which is (I've found) almost never where you want to be, and when thinking as a human about what's a 'around A' I don't tend to think backward to WXYZ).

Selecting one of these would then give the full list, but start you at that point, so you could still go forwards and backwards to find the item that you wanted that was near to the name given.

My reason for using the 'around' method, rather than giving a range is that the range will invariably scroll if it has to say (for example) 'Boomtown Rats - Fine Young Cannibals', which will look ugly (and isn't as easy to read). I realise that putting 'Around' at the front also makes the lines longer so maybe this could be omitted; if it was just me, I'd put a ~ at the front to mean approximately, but this is hardly a well known practice. Maybe 'Near' would be a better word, but I'm sure there are languages in which there will be a word that is just sillily long and impractical as a prefix.

This method could also be used for the Genres and Albums lists, and possibly the Years list (although the Years list might be better subdivided at decades).

Anyhow, those are the things I observed and my suggestions as to a possible solution.

Caleb Crome
2007-10-18, 16:16
Hi there. I plan to do the implementation of the list traversal algorithm. I implemented the current squeezebox algorithm years ago, before I was a SlimDevices employee. I did this because I had a large music collection, and the scrolling algorithm in use was impossible to use for lists over a couple hundred items. (I was using a SLIMP3!)

The current plan is to use a mechanism very similar to the one that is currently in use for Squeezebox. How does that one work for you?

The current Jive algorithm has not been optimized at all (well, that's not quite true -- it's much improved from the original version :-).

The new Jive algorithm will accelerate intelligently to where you want to go, and you will be able to traverse lists of 1,000,000 items as easily (more or less) as lists of 100 items. It would take quite a bunch of typing to describe the whole thing in detail, however suffice it to say that it will be the squeezebox algorithm, but enhanced to deal with wheel motion, rather than just up and down buttons.

So, my question is, would an algorithm similar to squeezebox but optimized for wheel motion be acceptable? I believe it would work extremely well, and it does not require any meta layers, such as first letter choice (a la iPods).

The idea of breaking the list down in terms of 'near xxx' and 'near yyy' is good, but only works for lists that are in a certain range of size. That is, for lists smaller than N you list all items, and for lists greater than N you do the meta layer. The problem is that when your lists get very long, you'd have to have so many, "near this" and "near that" layers that it wouldn't be that helpful and you might need . However, the good thing about it is that it will minimize the requests back to the server.


So, in short, I haven't worked on the algorithm at all yet, but once it's done it will work in virtually any list size. It may not be absolutely optimal for every list size, however it will be close to optimal given the fact that lists can vary from 10 to 100,000 items in the UI.

After I implement the scrolling my satisfaction, we will need to re-evaluate and determine if we still need any meta layers of scrolling. I hope we don't need to go to that, but we may be forced to.

gerph
2007-10-20, 01:20
When I had tried using the squeezebox to scroll through a large list in the past I hadn't noticed the accelerative scrolling. Now that I see it, it's 'ok', but not great. What's the problem ? Well, it goes too fast to be useable at times. The problem is that it's scrolling so quickly that you don't get to see what the first letter is that you're on. I just tried scrolling from the start to the end of my artists and once it got past about E I saw H, I saw L and M, I /think/ I saw S and then I saw a T and it stopped when it hit The Zutons (last entry).

As I was looking for Pink Floyd, this was no use; my reactions were hardly fast enough to stop on the T before the end was reached.

Maybe because most lines would be displayed on the Jive the accelerative scroll would work better because you'd have more things you could see.

I'm not letting go of the 'near x' idea yet though. It might be a no go for many reasons, but your objection of the multi-levels is fair, and I feel that my 'too fast to see' objection for the squeezebox is also fair (others may not have the same problem). So how about combining them...

Here's the idea... when scrolling becomes too fast (for some definition of too fast) we stop showing every result. Instead we show a 'near x' type name and scroll slower, so that the user has a chance to read that (maybe one scroll per 1/2 second, or something). The scroll speed is still the same so after 1/2 second it displays whereever in the list the accelerative scroll would have reached. If the user stops scrolling however, the 'near' point is the one that is displayed.

This is sort of like the initial letter scrolling, but works better for lists that aren't sorted by initial letter (eg ignoring 'The', 'Le', etc), or where there are huge runs of things starting with the same initial letter (for some reason, artists starting with B and S in my collection are large).

I think this avoids the over-fast scrolling and the secondary layers and (touch-wood) should scale well to huge lists.

Mostly I've described this with regard to its use on the Squeezebox where a single 'near x' line makes more sense. Not sure if it would work for the multi-line Jive though :-(

Anyhow; it's an idea...

Craig
2007-10-20, 12:04
A couple of things spring to mind here, using the standard remote, you can press P to jump to P J Harvey then it's a simple matter to scroll down to Pink Floyd, We don't have this functionality on Jive.
On the plus side, the scrolling on the SB is determined by the algorithm whereas on Jive it could be controlled by the wheel thereby allowing for gerph's reactions :-)

Craig

gerph
2007-10-20, 13:25
A couple of things spring to mind here, using the standard remote, you can press P to jump to P J Harvey then it's a simple matter to scroll down to Pink Floyd, We don't have this functionality on Jive.
On the plus side, the scrolling on the SB is determined by the algorithm whereas on Jive it could be controlled by the wheel thereby allowing for gerph's reactions :-)

Craig

<laugh>

And yes, I do forget about the key presses on the regular remote, but I had always wondered how that worked for a non-ASCII environment; whilst you can find Pink Floyd with a 'P', how do you locate an artist written in Korean or one of the many forms of Chinese, or whatever...

Anyhow, that's an issue for a different day.

2eleven
2007-10-23, 11:26
I need to throw in my two cents here so this doesn't get implemented "wrong" (meaning to my disliking). I feel rather strongly on this subject.

The navigation of long lists must be able to accomplish two goals:

a) rapid browsing for those who have not decided
who/what they want to listen to

b) very quick location of a specific artist/album/song for
those who have

The mechanism for making both of these goals work well together might be tricky to get right, but we absolutely must get this right!

Because of goal a, we cannot impose an intermediate menu layer, meaning we must not select artists and be presented with "a-c" "d-f" or even "near abba" "near devo". This eliminates the ability to effectively browse (in my opinion). If something like this must be implemented to achieve goal b, then it must be an optional menu layer - perhaps triggered by a very active scroll wheel.

At the moment, the best mechanism I can think of (with the current hardware) is an accelerating list which would yield to an intermediate list (like a first letter display) after reaching some threshold. If the user slows the scroll wheel, it would return to the full list. If the user never turns the scroll wheel too fast, it would never switch to the intermediate list, but it would still accelerate the full list as long as the user keeps turning the wheel. With this model, we don't force the intermediate layer. Instead we use some logic to determine an appropriate time to present it. We also make it easy to avoid for those who simply want to browse (what I find myself doing much of the time).

Of course, if we are open to hardware changes, we could implement this even more slickly. The current squeezebox/remote interface works pretty well (though I still would like the acceleration to happen more quickly). To browse, I use the arrows and let the built in acceleration make the long list manageable. To jump to something specific, I use the keypad. It is unfortunate that there is no keypad on the jive remote, but I understand the tricky balance between elegant design and bells and whistles.

At least one member of this forum has voiced a preference for a jog wheel in place of a scroll wheel. I think what he is referring to is the spring loaded wheels which sense urgency by the amount of pressure applied in the forward or reverse direction. These do have some advantages over a simple scroll wheel. Someone turning a jog wheel with a good deal of force jumps right to the intermediate list. Less force would scroll the full list at varying degrees of speed depending on the amount of force applied. These jog/shuttle wheels were often paired with a scroll wheel in the center, so you could have the best of both worlds. Maybe this is an option, though they look clunkier than simple scroll wheels.

Anyway, I hope we can find a good solution to this. It is my number 1 gripe with the current jive interface.

Cheers,

John

Caleb Crome
2007-10-23, 16:52
We all agree here that the current issue with stuff scrolling too fast on SB can be a problem. We noticed this a few years ago when I implemented the scrolling the first time around. Dean had a great suggestion for resolving that -- it just never got implemented. Keep the letters that remain constant during a scroll stationary, and let the rest keep going. Sort of like a many-wheeled slot machine with the first characters stopped.

I *think* this can eliminate any need for any meta levels. It lets you read what's going by easily. This would require some rewriting of the squeezebox code to scroll partial lines. (As well as rewriting squeeze center code of course). I think the same thing could work for Jive, though maybe with some compression of the list. I.e. each page wouldn't necessarily display 8 consecutive artists, but would be a localized 'near here'. I don't know if that would be useful or confusing.

I really want to maintain a simple mental model of a continuous list, though we may need to break that for very long lists.

Apple does it with 'A'-'Z' selection on the iPod, but we may end up with very many more items than you can get on an iPod. (Say if you want to scroll through all songs on Rhapsody :-)

We'll have to work on that. However, for Jive, I don't think we can support that until we get time to rewrite some of the rendering bits of jive. I'll chat about it with UI people and engineering team.

The comments above are very good, and I will try to solve all the problems brought up. When I start work on the scrolling, I'll keep this thread updated with thoughts and code.

-Caleb

2eleven
2007-10-23, 17:38
Dean had a great suggestion for resolving that -- it just never got implemented. Keep the letters that remain constant during a scroll stationary, and let the rest keep going. Sort of like a many-wheeled slot machine with the first characters stopped.


That sounds like an interesting idea. You wouldn't need to limit the stationary "wheel" to the first letter either. You could make all letters which aren't changing stationary. That would aid further in the super-long (rhapsody) lists.



I *think* this can eliminate any need for any meta levels.


That should be a requirement (no meta levels). Meta levels screw up the ability to browse.



I think the same thing could work for Jive, though maybe with some compression of the list. I.e. each page wouldn't necessarily display 8 consecutive artists, but would be a localized 'near here'. I don't know if that would be useful or confusing.


Confusing. When browsing, I am looking for something I want to listen to, but I don't know yet what that is. If eight artists names are compressed to "near Devo", I don't get to see Dire Straits scroll by. Maybe Dire Straits was just the thing I was looking for. Please don't compress the list. This is just as bad as adding an meta level IMO.

I ~really~ want to get this implementation right. If it works well, I'll replace all 4 of my IR remotes with Jive remotes. If it's clunky, I'll stick with the IR remotes. This is a fundamental feature which will make or break the product for me. Thanks for working on it.

Cheers,

John

cliveb
2007-10-24, 10:01
The navigation of long lists must be able to accomplish two goals:

a) rapid browsing for those who have not decided
who/what they want to listen to

b) very quick location of a specific artist/album/song for
those who have

The mechanism for making both of these goals work well together might be tricky to get right, but we absolutely must get this right!
Absolutely agreed. This *has* to be done well. At the moment, Jive is better than the standard remote for arbitrary browsing, but it's *worse* for finding a specific album.

In another thread (about the Lazy Search ideas, I think) I suggested that people take a look at the way the Rio Karma DAP does this. I still think it's about the best compromise. To briefly summarise: when you bring up the equivalent of "My Music" on a Karma, you get the letters A-Z to navigate through, but you also get an option (at the top) to browse everything. (One could invert this, of course, so that "My Music" on the Jive gives you a full list to browse, but with the first item being a "browse by initial letter" instead).

I've seen the ideas being suggested about measuring the scroll rate of the wheel and switching modes based on how fast you go, but it sounds like a recipe for frustration to me - I can imagine it behaving a bit like automatic gearboxes from the old days, "hunting" between two settings. I'd much rather know exactly what mode I'm in and that it's not going to jump to another if I happen to accidentally twiddle the wheel a bit too fast or slow.

radish
2007-10-24, 10:47
I like the idea of keeping the unchanging letters constant, I think that could work very well. One request would be that anything done in that regard be backported for the transporter dial :)

As an aside (and this is really just putting the idea out there, I don't have a strong opinion on the matter) - do we really need to cater for the two different use cases (browse & locate) with the same UI? Interfaces often end up over complex because they try to be everything to everyone. I think it _may_ be better to have one interface (based around a long list) for browsing and one (maybe based on a branching tree) for getting straight to a known thing. You can see iTunes doing something similar with Coverflow for browsing and a hierarchical narrowing (genre/artist/album) for rapid locating.

cliveb
2007-10-24, 11:32
I think it _may_ be better to have one interface (based around a long list) for browsing and one (maybe based on a branching tree) for getting straight to a known thing.
So the top level menu would have two entries: "Browse Music" and "Find Music" instead of the single "My Music"? I like that. Sign me up.

2eleven
2007-10-24, 11:53
So the top level menu would have two entries: "Browse Music" and "Find Music" instead of the single "My Music"? I like that. Sign me up.

Hmm... I don't think there should be two top level entries. I think we need to be careful about not cluttering the top level menu. I could go for a two-mode approach though, but I would prefer the rio karma model you mentioned over two top level entries.

John