[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Toolbars (Was: Re: Unimplemented AppKit classes)

From: Alan West
Subject: Re: Toolbars (Was: Re: Unimplemented AppKit classes)
Date: Thu, 23 Jan 2003 23:45:54 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030120

Jeff Teunissen wrote:

On the other hand, an Office-style "Toolbar" (which is pretty-much exactly
what NSToolbar implements) is one of those things that is added to a
program to cover up for a number of fundamental stupidities. It's a
symptom of brain damage, not a feature of note.  And worse, they're
configurable -- so you can't rely on muscle memory to find the button,
because somebody else might have moved it or you might not be on your
computer. You have to recognize the functions on the toolbar by image, not
location. Apple had these same arguments when it wasn't their
implementation being argued about...the wheel turns, does it not?

Getting right down to it: Apple needs toolbars because they broke their
menus and eliminated the normal "right-press menu" that makes toolbars a
completely superfluous distraction. In this manner, the app menu is like a
complete toolbox that is always directly beneath the mouse pointer -- so
it doesn't need the precision mousing necessary to reach a button that's
way off in some random part of the window (or outside it). And what's
more, commonly-used menu entries have command-key alternatives, and you
can add your own keyboard alternatives for commands (although I don't see
any way to specify that an alternative is triggered with the Alternate key
instead of, or combined with, the Command key at this time).

"We can't be bothered to actually work on our menu system or to make our
program operate intelligently, so we'll force you to design your own
button-based interface."

Toolbars are great for simplifying the user interaction with the interface for often used actions - although too many buttons will ruin it.

Normal users love toolbars because they're simple to use and can streamline their work, one click and the action is performed, if this action was located only in a menu it could be 2 or more clicks to activate, plus the extra time reading the menu items. Think about a web browser, if it took 2 clicks to go back a page because you're only opion was a menu, you'd get annoyed at having to read > move > click > read > move > click action.

I think toolbars should be the opposite to what is commonly implemented in Windows - where all actions seem to have a toolbar button, and its upto the user to hide what they dont use. If the application started off with a minimal collection of toolbar items - the user can add buttons if they use further functionality frequently. Toolbar customizations should be stored on a per user basis anyway.

For most users keyboards are for entering information into an application, rather than a method of performing actions.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]