Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: NEWKEYS v2

Re: NEWKEYS v2

From: Kjell Ericson <Kjell.Ericson_at_haxx.se>
Date: Mon, 25 Aug 2003 14:17:12 +0200 (CEST)

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.

> With the way it is overloaded now, I would be willing to bet that there is
> at least a 10-1 ratio of the number of times a user has mistakenly canceled
> a setting that he didn’t really want to cancel, as opposed to the number of
> times a user has changed a setting and used the cancel function to revert
> back to what it was.

Wouldn't those 90% ever learn and then make the the odds equal?

Why make it impossible for those 10% of times you want to cancel?

> 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?

I say the settings buttons are logic.

> Then ON, ON, STOP could be cancel...

Uhuu, are you really serious that this should be a logic thing and user
friendly?

I want the cancel, I think the stop-button is the only logic way to cancel
operations. I even use the stop-button when "cancelling" playing a song... :-)

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).

> 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.

> In other words you have a hidden cancel function overloaded onto a button
> that is intuitively used for some other common function... not very
> desirable for a good user interface design.

I think you just need to redefine the way you look at it.

If we have different behaviours then I agree it is unlogic, but the settings
menu are not unlogic for me.

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.

Be my guest, the source is free.

  // Kjell
Received on 2003-08-25

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