[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: State "button" in Customize is not a button
From: |
Drew Adams |
Subject: |
RE: State "button" in Customize is not a button |
Date: |
Tue, 10 Jan 2006 08:15:00 -0800 |
In our case, State looks like a button, so it won't be
mistaken for simple text. But it can be mistaken for an action
button, as opposed to a menu.
So what? Someone will click it, and see a menu. If he doesn't
realize at that point that it's a menu, he's not smart enough to use
Emacs.
People shouldn't need to try things just to have an idea what they are.
That's a pretty simple UI principle. If it doesn't make sense to you, let it
drop.
A "button" called something as vague as "State" is asking to be improved -
especially in a context designed to be accessible to newbies. They will need
to find and use this menu to put edit changes into effect and save those
changes, so we had better draw their attention to this menu for those
purposes.
Or are you concerned someone will be afraid to click it because
he's worried about what it might do?
Yes, that's one possible consequence of not having things show clearly what
they are. Someone will click it and find out; someone else won't click it
and won't find out. And neither is necessarily "smart enough to use Emacs"
or too stupid to use Emacs.
This is not about dumbing things down; it's about making things clear (truth
in advertising vs hiding important functionality behind misleading
appearances and names) - to save people time and effort.
Why should users spend time wondering, guessing what something might be or
do, trying different buttons to see what they are for? I've nothing against
curiosity and exploring to discover things, but it shouldn't be an imposed
obstacle - when someone wants to get a job done, he doesn't necessarily want
to play Adventure through the Labyrinth to find the holy grail.
Some people think that we don't even need to provide doc, that the source
code is clear enough for anyone who is "smart enough to use Emacs". I think
such an attitude is narrow-sighted. I know and applaud your attitude wrt the
doc. I see the UI as le meme combat.
The tooltip should help.
Sure it helps. So would using a different "button" style for such menus, and
a different label from "State". Names like "state", "treat", and "do" (and
even "value" and "process" in some contexts) don't mean much, because of
their generality. We can do better, and the cost of doing better is not
great.
When I suggest making menus, buttons, and links have 3 different
appearances, you reply "Tough luck". Why the resistance? What do we lose by
doing that? Sure, it's something minor, and it doesn't need to be done
before the release. But why not signal an intention to do it?
- State "button" in Customize is not a button, Drew Adams, 2006/01/06
- Re: State "button" in Customize is not a button, Bill Wohler, 2006/01/07
- Re: State "button" in Customize is not a button, Richard M. Stallman, 2006/01/07
- RE: State "button" in Customize is not a button, Drew Adams, 2006/01/07
- Re: State "button" in Customize is not a button, Richard M. Stallman, 2006/01/08
- RE: State "button" in Customize is not a button, Drew Adams, 2006/01/08
- Re: State "button" in Customize is not a button, Richard M. Stallman, 2006/01/10
- RE: State "button" in Customize is not a button,
Drew Adams <=
- Re: State "button" in Customize is not a button, Richard M. Stallman, 2006/01/11
- RE: State "button" in Customize is not a button, Drew Adams, 2006/01/11