FS#1432 - Improved menu consistency

Attached to Project: Rockbox
Opened by Magnus Holmgren (learman) - Monday, 09 June 2003, 09:17 GMT
Last edited by Magnus Holmgren (learman) - Monday, 29 August 2005, 16:58 GMT
Task Type Patches
Status Closed
Assigned To No-one
Operating System
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


The handling of the menus is a bit inconsistent (at
least on the player). Most notable is the difference
between the sound settings and the general settings.
E.g., in the general settings you must use "play" to
save the settings, whereas in the sound settings play
doesn't do anything. This patch fixes that problem (and
makes use of the splash function for displaying the
"cancelled" message).

Also, the menu button is added as an exit key on most
screens in the menus, which makes behaviour more
consistent. I have not done this for all screens in the
debug menu, however.
This task depends upon

Closed by  Magnus Holmgren (learman)
Monday, 29 August 2005, 16:58 GMT
Reason for closing:  Out of Date
Comment by Craig Sather (rb_dev) - Tuesday, 10 June 2003, 08:17 GMT

I hate the cancel function. It adds virtually no value and
mostly just clauses people to inadvertently cancel the
setting that they just set when they back out of the menu
item in the manner that other menu items are backed out of
when you are through with them. Just how useful is the
cancel function anyway? How many times have you actually
started to change a setting and needed to cancel it? Exactly
zero for me. I think that we should make the menus
operations consistent by getting rid of the cancel function.
Backing out of a menu item should mean that you are through
with it, not that you made a mistake.
Comment by Ofir Carny (whitemouse) - Tuesday, 10 June 2003, 10:55 GMT

I don't agree with the last comment, I often use the cancel
function, especially in menus I am not familiar with. It is
useful for getting to know them.
Comment by Remo Hofer (remo_hofer) - Tuesday, 10 June 2003, 14:33 GMT

My favorit configuration would be:

PLAY = accept setting and return to menu
STOP = cancel menu (if it makes any sense) and return to
parent menu
MENU = accept setting and leave menu completely (return to
wps or browser)

Of course with this configuration, MENU should leave the
menu everywhere in the menu tree.
Or even better:
MENU stores the position in the menu tree and switches to
wps (or browser). So you could use MENU to toggle between
wps and the menu and return where you left it (e.g. to
change the volume).

BTW I wouldn't care if there was no cancel option.
Comment by Craig Sather (rb_dev) - Tuesday, 10 June 2003, 19:31 GMT

The problem isn't that a cancel method is provided…. the
problem is that the key used to cancel is the same key that
used to perform the operation "I’m through here... go back
one level". That mixed use of a key in the menu screens
doesn’t follow good MMI design principals.

That would be like if in an operating system directory
browser such as Windows Explorer, if you clicked down into
your directory tree, renamed a file, and then clicked the
icon to go up one level, you wouldn’t go up one level but
instead you undid the file rename that you just did. Even
Microsoft wouldn’t do something like that.

If the cancel function is kept, it should be properly
mapped to a key other than the key used to go back one level
instead of breaking consistent key functionality in the menu
Comment by Anonymous Submitter - Monday, 04 April 2005, 21:46 GMT