Menu reworking

[fml2]

... For me these three screens (wps, recording and radio) should somehow be treated similarily.

Exactly this is the reason why I made a patch (FS#5049) to treat that screens similarly after start up (with a side effect of reducing the number of menu entries by one). The patch isn't completed yet. Any help is appreciated.

[Rincewind]

how about putting "view current playlist" in the root of the main menu?
My argument for this goes like this: View current playlist is an important screen (if we agree that rockbox is a playlist based player) and should be nearly as easily accessible as the file browser.

On many units there are no buttons left, so I think it deserves a prominent place in the main menu and the wps and browser context menus  (I know it is there, but not at top level).

On the irivers I suggest using a short press of record button to view the current playlist and long press of rec for recording screen.

A general thing: the menus are not in an organized order right now, entries were added at the bottom or inserted when new functions came. I would suggest to order entries with the priority that most used features should come first. Maybe a few polls on controversial priorities. Most things should be clear, for instance, in general settings -> system, battery comes first but you only use this if you happen to change your battery, roughly once a year if ever.

[Febs]

I wonder if it wouldn't be more useable if it menus were in alphabetical order.

[bascule]

I wonder if it wouldn't be more useable if it menus were in alphabetical order.

More consistent, but surely not more usable.

In concordance with other views expressed here, most-used functions should be at the top of their respective menus. In particular, I would like to get to View Current Playlist even quicker than I currently can...

I know it would be difficult to support and potentially hazardous for the 'WTF!!1! i changed the menus and now i cant use my ipod rockbox is crap' user, but I really like the idea of a config file for menus so I could design my own. I already re-wrote the tagnavi.config to suit myself and I'm really happy with it.

It seems to me that, with a suitable key combination to restore menus to a default, that it would give the best of bothe worlds - those that fiddle, can; those that like it simple, leave it alone...

[Rincewind]

I wonder if it wouldn't be more useable if it menus were in alphabetical order.

I disagree, a similar idea would be to have short entries first so that the screen looks nice...
alphabetical is only a superficial order which doesn't make sense to me if we only have about 10 menu entries in each menu.
in a .cfg file alphabetical order seems logial to me, because there are all entries at one level.

[Llorean]

I think that a short press of the Record key should go to the record screen. The short-press of a button is it's "Primary" function, and the record button is the Record button, so it only makes sense. People already complain about the button mappings being counterintuitive without a button with so clear of a purpose being retasked.

This would still leave long-press open for an alternative function such as view current playlist.

[Febs]

I wonder if it wouldn't be more useable if it menus were in alphabetical order.

I disagree, a similar idea would be to have short entries first so that the screen looks nice...

I don't think that it's quite the same thing, considering that alphabetical order makes it easier to locate an item within a list. 

In theory, I think that putting most used functions first makes sense.  However, I'm not sure that we could achieve a consensus as to what constiutes a "most used function."

[Llorean]

I think that we're missing a few things here:

1) Context menu. This exists for the 'most used functions in this context' which of could benefit from some small reevaluation.
2) The context menu could be enabled from the main menu. So, click the menu button, then call the context menu, and you get a smaller main-menu sorted by "Most used". This wouldn't contain everything, but it would be what people most commonly enter the menu for. This would allow for the normal menu to be alphabetized for easy finding of things.
3) Menu depth and locations. Some things are possibly miscategorized, as well it could be reconsidered as to whether the menus should go as deep as they do, or if some categories should be brought up on their own (LCD settings being a subcategory may not be the best idea.) In this case Alphabetizing will help even more for finding things, if some subcategories are floated up.

[Rincewind]

I think alphabetical order is only important for very large lists. If you can see every list entry at once on the screen, the eye sees catch phrases (for instance words with Capitals) first, you don't scan a short list with maybe 10 entries alphabetically (at least I don't).

A consensus on what settings should have priority can't be find everywhere of course, but in these cases we can just leave it like it is now. We don't want to do everything from scratch, I see it that we are suggesting improvements, not a completely new concept.

and with alphabetical order you would think "ah, its alphabetical, ok, I want to find playlist options, that begins with a P that comes somewhere after N... damn, playlist options aren't in this menu, they are somewhere else..."

It would make sense to provide a special menu, where every settable option is inside one big alphabetically orderd list so that you can find options there when you know the name but not in which menu they are in. But this is much work for such a small feature.

On the record button thing: I wouldn't want to have a button that stops playback and maybe even activates the internal mic and monitors it to my ears if I accidentally press it. A long press is safer and you don't lose much convenience (and shoot me down for this, but this is actually the use that is labelled on the back of the player)

[Llorean]

I personally many times tapped the Record button expecting it to take me to the Record screen quickly only to find it changing the EQ settings on the original firmware. So, while others may agree with that, to me it's always been a bad design choice on iRiver's part.

My theory is this: If you don't want accidental keypresses to interrupt your music, put hold on. There's already two keys that can interrupt the currently playing song easily, as well as a host of combinations that can do various things to it. Turn on hold on the base unit, and use the remote, or simply turn off hold when you want to change things. One more music-stopping button does not, in my mind, significantly increase the chances of your playback experience being altered.

But again, these are just my opinions on the feature.

[Mr. Brownstone]

I think having "Bass" and "Treble" options right next to "EQ" is a bit redundant.

Indeed, there are about four ways of modifying the EQ and they all achieve the same objective.

So I guess this is a vote for a little less duplication.

[Febs]

The EQ is software based, while the  'bass' and 'treble' controls are hardware based, so these settings really control different things.

[Mad Big Sausage]

Just a quick note without any extra opinion.

What are deemed to be the most important features are at the top so it takes a few button presses to get to them.
Yes?

So the single most important option is #1 at the top, the second most important #2, the third at #3, the fouth #4 and so on till we get to the least used feature right at the bottom.

The first entry can be reached without any up/down presses, the second and last by 1 press, the third and second last by two.

Couldn't  the less used entries be located somewhere in the middle of the list?

[mnhnhyouh]

I would chip in here to support the option to config the menu structure....

h

[Llorean]

From my understanding there are a host of complications that could come with this regarding properly voicing and localizing a configurable menu.

I'm sure they can all be resolved, but is there really *that* much benefit to such a thing considering both the work, added complexity to rockbox (including likely increased size, very bad for the archos targets, and increased bugginess for a long time) of such a feature?