dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: NEWKEYS v2


From: c s <>
Date: Mon, 25 Aug 2003 14:11:01 -0700 (PDT)

--- Kjell Ericson <> wrote:
> On Sun, 24 Aug 2003, c s wrote:
> > I say that cancel should be eliminated rather than
> > overloaded onto the same
> > key used for backing up one menu level.
> I made the cancel function because I think pressing
> "stop" for accepting a
> setting is confusing.

It's not confusing at all. Changing to meaning of STOP
while in the menu is what is confusing. STOP is the
universal key used in every player menu to back up one
level, so when you have changed the setting to what
you want it to be, it's just common sense to press the
STOP key to back out of the current menu level. Why
would the user pressing the key known for going back a
menu level expect that action to cancel a setting?
This makes no sense and is horrible UI design.

> > After changing a setting, that change must be
> confirmed by pressing the play
> > button,
> Don't you press "OK" in you window dialogues? Don't
> you hate it if they
> removed a cancel button?

Your analogy is completely wrong. This is not how the
Rockbox cancel logic works. There is no OK/Cancel
dialog in the Rockbox settings menu. The Rockbox user
is given absolutely no indication that he has to
confirm the setting before exiting the setting level
and then when he presses a key expecting it to go back
one level, he accidentally invokes a hidden cancel
function. This would be equivalent to if a Windows
setting dialog box had no OK/Cancel buttons but only a
“close window” button which canceled your new settings
when you closed the window unless you performed a
<ctl>S before closing the window AND the windows
dialog box didn’t tell you that the <ctl>S was
necessary to save the settings. Even windows users
would find that unacceptable, but that is what we have
implemented in the Rockbox settings menu.

> > Then ON, ON, STOP could be cancel...
> Uhuu, are you really serious that this should be a
> logic thing and user
> friendly?

It beats using the key that everyone expects to go
back one level, and beats it by a long shot... no more
inadvertent cancels by people who intuitively expect
the stop key to go back one level like it does
everywhere else while in the settings menus.

> I have been testing settings (in Rockbox and other
> systems) and found that
> I need to cancel my new changes. Cancelling is much
> easier than trying
> to refind the original setting (you can't argue
> there).

That is a very poor argument. So we should give the
STOP key a hidden and inconsistent meaning in the
settings menu because you often change a setting and
then change your mind and want to revert? That's
hardly how the settings menus are used by the vast
majority of people. That's what makes the
implementation of the cancel function such poor
design. It's a little needed function that is rarely
needed or used, yet it is hidden and also mapped to a
commonly used button that everyone intuitive expects
to only go back one menu level.

> > so when the user intuitively uses the key that is
> used everywhere else to
> > back up one level, the setting change is
> unintentionally cancelled.
> Just see it that you haven't reached the last level
> in the settings menu. When
> I press stop in other menues and go up one level I
> see it as cancelling the
> current level.

That's ridiculous. Now you are just playing with words
to try to support a bad design. Everyone thinks that
the stop key goes back one menu level, not cancels a
menu level.

> If many users are confused then it would be
> friendlier for everyone to add a
> "confirm"-dialogue when pressing stop/cancel - not
> removing the cancel
> possibility.

I would not be for adding yet another level of
complexity to a function that there is already very
little need for, and most people wouldn't care if it
went away. If a few people absolutely want to keep the
cancel, it should be moved to a more obscure key
combination, not overloaded without warning on to a
common menu navigation key, and definitely not make
them respond to an additional confirmation screen just
because a small number of users might like to start to
change settings and then change their mind and don't
want to have to manually set it back to the original

> Be my guest, the source is free.

I fixed this design faux pas in my own personal
version a long time ago. My goal in this discussion is
providing a well thought out user interface to users
who have to rely on the official builds. I would
suggest that you look past your own atypical use and
need for this function and instead think of having a
good consistent user interface for the masses.


Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
Received on 2003-08-25

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy