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: c s <rb_dev_at_yahoo.com>
Date: Mon, 25 Aug 2003 03:21:05 -0700 (PDT)

--- Daniel Stenberg <daniel_at_haxx.se> wrote:
> 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.

I said "it's not stated in the goals section AND
NOTHING ELSE IN THE NEWKEYS V2 DOCUMENT TALKS ABOUT
CONSISTENCY". I don't know why that would that elicit
a smart-aleck response about me only reading the goals
section, when I was clearly talking about the whole
document.

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

Since lack of consistency is currently a problem in
the Rockbox user interface, and it should be one of
the top priorities of any good user interface design,
not making it one of the goals of a major remapping
effort is a glaring omission.


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

I would have to disagree strongly with that. The
implementation of the cancel function on the player is
a very conspicuous flaw in the current user interface
design. Since cancel is probably rarely used or
needed, it is a mistake to overload the button for
"back one level" with this function. As I stated
before, it is completely counterintuitive and
inconsistent, and therefore the current implementation
means that the cancel function is probably being
invoked by mistake the vast majority of the time that
the cancel key is hit... a sign of a poor UI design.


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

Fair enough, but this poorly implemented element of
our UI still should be corrected under the guise of
what should be one of the goals of any major UI
change... consistency.



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

Set is easy. When you exit the setting screen using
the same key that means "back one level" everywhere
else, the "set" value that would be used would be the
current value displayed on the setting screen. That
gets rid of the problem of breaking the intuitively
and consistency of the use of that key.

Now the play key is free to be used for cancel. Using
the play key seems to be a bit a bit counterintuitive
also, but at least it would cause far fewer
unintentional cancels than the current design.

Because it is desirable to avoid unintentional cancels
and since the cancel function is more of an obscure
function that probably isn't used much (and isn’t even
necessary to have), it could be mapped to something
more obscure that would only be known from reading the
manual and that isn’t likely to be accidentally
pressed, such as ON+STOP, but if you intend to reserve
ON+ combos for custom macros no matter what state or
menu you are in, that option would be out.

Since the player has such a limited number of keys,
(and the recorder does too... just not quite as bad),
perhaps it’s time to come up with a new concept of
additional possible key combos such as two quick
presses of the ON button within N milliseconds
followed by another button press within 1 or 2
seconds. Then ON, ON, STOP could be cancel... or ON,
ON sequences could be used for custom macros, freeing
up the ON+STOP for cancel.

I still contend that removing the cancel function is
an option that should be considered since it is of
very limited value, and is probably not used much,
plus if it is removed you still have the capability of
manually cycling back to your original setting.



=====
Craig

rb_dev_at_yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Received on 2003-08-25

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