UI Buttons was: [squeak-dev] MessageNames: clicking on class names

Oh yes, I agree about the button panes.  I keep them all turned off as
much as possible, and would like to add a preference to disable the
ones in the debugger altogether.

The main problem with buttons as a UI-element is that they provide
little or no output.  Instead, they just sit there, taking up valuable
screen space, waiting for one single type of gesture of input, a
left-cick.  I believe this is mostly to accomodate users who do not
have Basic Computer Literacy, the same kind of users who will not go
very far with Squeak anyway.

Not a bargain...



On Thu, Apr 1, 2010 at 1:59 PM, Ken Causey <[hidden email]> wrote:

Chris Muller wrote:
What are the alternatives?

Putting actions in context menus means you replace "click" with "click,
move, click". (Of course, actions like browse, senders-of,
implementors-of, version, ... are already there, in the second "page" of
the context menu.) Leaving the buttons out entirely means "How on Earth
do I Foo?" The buttons are a very clear indication of what you can do.

frank

I use keyboard shortcuts and the buttons about equally often. It all
depends on where the cursor and my hands are (like, if my hand is on the
mouse already and near a button it's faster to click the button than to
move my hand over the keyboard and hit some keys etc). This is especially
true when I'm in "stare mode" trying to figure out some code, then it's
buttons almost exclusively.

Speaking about the debugger specifically, there's a setting to have _two_
rows of buttons in the debugger which doesn't work in trunk anymore, but I
usually had that on and liked it.

rado

On Fri, 2 Apr 2010, Chris Muller wrote:

> Putting actions in context menus means you replace "click" with "click,
> move, click".

I like your thought that considers the additional "effort" required by
context-menu access.  UI designers should pay attention to the
_number_ and _type_ of gestures required to operate the software.

>The buttons
> are a very clear indication of what you can do.

The context menu is a more-complete indication of what you can do,
though, wouldn't you say?  Because there are not buttons for every
single option on context menus.

> What are the alternatives?

Hot keys.  The context menus should indicate hot-key accessibility for
the most-used options.  Then, once learned, accessibility to that
function is made with slightly less effort than a button:

  1 - gross-motor point
  1 - press of the hot key (+ 0.5 if modifier required)
=========
  2.0 - 2.5 total gestures

With buttons you have

  1.5 - fine-motor point
  1 - press the red mouse button
============
  2.0 - 2.5 total gestures

Admittedly, this a tight a race.  But, in many cases, there's no good
reason for the UI designer to force the user use a modifier key..
Also, the additional cost of the buttons is the screen-space, and
clutter associated with that.  Also, buttons are usually not
co-located with the object on which to activate the button's command
(consider how awful "Office" applications have become, where you have
rows of icon buttons along the top or down the left side, and all the
"content" in the middle).  So they continue to reinforce
"global"-commands rather a more OO thinking, which is sad..

Let me say, I think there is a place for buttons and I do use them.
Just sparingly, though..