From: Daniel Stenberg <daniel_at_haxx.se>
Date: Mon, 25 Aug 2003 06:00:41 +0200 (CEST)

On Sun, 24 Aug 2003, c s wrote:

> Since it's not stated under the list of goals and nothing else in the
> NEWKEYS v2 document talks about consistancy, I would say that it is not
> clear at all.

If you only read the goals section, I can understand that many things
regarding this is unclear.

The issues you describe may be of importance but they have not been among the
goals for this remapping of keys and therefore it is not included in that list
of goals. It isn't stranger than that.

> > Which key would you want it to be then? There aren't many keys to choose
> > from on the player.
>
> I don't care. I think that the cancel function is of limited use and
> dispensable. Currently it looks like the ON button is the only unused button
> in the menu screens, but if the ON button gets taken for some better use, I
> say that cancel should be eliminated rather than overloaded onto the same
> key used for backing up one menu level.

ON is left unassigned (as much as possible) for a reason, and *that* is stated
among the goals.

Personally, I don't care that much for cancel either but I don't feel very
strongly about it. I would say that it is quite fine as long as we
consistently allow it all over and it is used the same.

Besides all that, the document is not meant to cover everything in regard to
what keys that do what, it only covers a vision of how the main screens could
function.

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

The cancel functionality was added for a reason. If you would need to keep it,
how would you instead suggest that we deal with SET vs CANCEL ?

> The current method is inconsistent and counter-intuitive. After changing a
> setting, that change must be confirmed by pressing the play button, but
> there is no indication to the user that this must be done, so when the user
> intuitively uses the key that is used everywhere else to back up one level,
> the setting change is unintentionally cancelled. 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 wouldn't necessarily call that overloaded. OFF gets you out from the screen.
Exactly in what state it leaves the things you were doing in the screen is
somewhat undefined all over and I don't see this huge inconsistency as you do.

Still, I too would rather have OFF not restore the original value. I just
can't come up with a more intuitive interface than having PLAY set the value
and without having it set, we go back to the old one.

-- 
 Daniel Stenberg -- http://rockbox.haxx.se/ -- http://daniel.haxx.se/

Received on 2003-08-25