I don't like the idea of dedicated keys being required.  For my ideal
system, everything should be do-able with a one-button mouse. 
Dedicated keys could still be supported, of course, but they would
*always* correspond to something that can be done with a single-button
mouse.  Reasons:

--> The UI can be used on a PDA/tablet with no modification.  

--> Right-click/dedicated keys/etc. aren't discoverable.


The time has come for me to present my ideas on how I believe it should be done.

When selecting (left-clicking) an object:

--> If the object only has one action associated with it (i.e. button
click), that action is performed.

--> Otherwise, one or more palettes appear, floating above other
windows, which contain all actions that pertain directly to the
selected object.  These can have any controls in them (including
pull-down menus), and can be circular or whatever.


More about palettes:

--> One palette would be the "master" or "root" palette (like the Next
application menu), which provides access to all other palettes.

--> Each palette can be dismissed, and dismissing the root palette
causes the object to no longer be selected.

--> Selecting an object causes the root palette to appear again, and
any other palettes that happened to still be around the last time the
object was selected.

--> Selecting an object causes all palettes for the previous selection
disappear, as in OS X.  However, palettes for objects that contain the
currently selected object(s) remain.  (Palettes that apply to the
current project, for example.)

--> An object may have a "default palette" which appears under the
mouse when the object is selected.  This would contain the most common
actions, and may or may not be the root palette.


This scheme applies to anything that can be clicked; even a text
control.  In this example:

--> Clicking anywhere in the control causes the cursor to appear
there, and makes some palettes appear (one of which would be some sort
of "keyboard" palette).  There would be no default palette in this
case (i.e. palette under the mouse) as it would interfere with typing.

--> Selecting some text would result in a main palette appearing under
the mouse containing actions for the "text selection" object.


To summarize: palettes, not menus.


More rationale:

--> One doesn't select an object without the intention of doing
something with it.  The UI should be smart enough to realize this and
present options immediately instead of waiting around for a second,
redundant action from the user (such as right click) before showing
actions for the object.

--> It enforces a clear separation of the two types of object
actions--direct and indirect manipulation--by the UI.  All direct
manipulation stuff happens right in the controls (i.e. by dragging
stuff around), whereas all indirect manipulation stuff is done from a
palette.  Thus windows are not being cluttered with all kinds of
buttons and controls; these all get farmed out to palettes.  So for a
movie player control, for example, the control itself would only
contain the movie.  All controls for manipulating the movie are in
palettes.


The reason that everyone hates Apple's insistence on one-button mice
is that there are many, many things in OS X that a user can't do (or
at least do easily) with a one-button mouse.  If they could do it all
with a one-button mouse, there would be no complaint.

Reply via email to