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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Chris Muller-4
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:

> On Thu, 2010-04-01 at 13:20 -0600, Chris Muller wrote:
>> > I noticed that the new search morph in the docking bar will bring up class
>> > names as well as selector names. For instance, searching for "obj" will show
>> > things like "AbstractObjectsAsMethod".
>> >
>> > If you hit the browse button on these entries, though, nothing happens.
>>
>> This is because the preference, #alternativeBrowseIt is disabled, by
>> default.  Crazy isn't it?  If just enable that and you can (b)rowse
>> hierarchy's, i(m)plementors, or se(n)ders with those keys..
>>
>>  - Chris
>
> It's not that simple.  There is another clearly related problem that
> this does not address (oh, and your solution does not fix the problem,
> it simply leaves out the most glaring instance of the problem).  The
> 'instance', '?', 'class' buttons have the same problem as the alternate
> browser buttons.  Even more fun because they are in a subpane of the
> upper frame, try to enlarge just the source code pane by pulling the
> main divider up...the instance/?/class button pane is squashed and once
> it reaches it's lower limit you can't move the main divider up any
> farther.  Instead you have to start by dragging up the divider between
> the pane listing the classes and the button pane then drag up the
> overall divider leaving enough space for the buttons.  Not intuitive in
> my book.
>
> Ken
>

Reply | Threaded
Open this post in threaded view
|

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

Frank Shearar
Chris Muller wrote:

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

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

> On Thu, Apr 1, 2010 at 1:59 PM, Ken Causey <[hidden email]> wrote:
>> On Thu, 2010-04-01 at 13:20 -0600, Chris Muller wrote:
>>>> I noticed that the new search morph in the docking bar will bring up class
>>>> names as well as selector names. For instance, searching for "obj" will show
>>>> things like "AbstractObjectsAsMethod".
>>>>
>>>> If you hit the browse button on these entries, though, nothing happens.
>>> This is because the preference, #alternativeBrowseIt is disabled, by
>>> default.  Crazy isn't it?  If just enable that and you can (b)rowse
>>> hierarchy's, i(m)plementors, or se(n)ders with those keys..
>>>
>>>  - Chris
>> It's not that simple.  There is another clearly related problem that
>> this does not address (oh, and your solution does not fix the problem,
>> it simply leaves out the most glaring instance of the problem).  The
>> 'instance', '?', 'class' buttons have the same problem as the alternate
>> browser buttons.  Even more fun because they are in a subpane of the
>> upper frame, try to enlarge just the source code pane by pulling the
>> main divider up...the instance/?/class button pane is squashed and once
>> it reaches it's lower limit you can't move the main divider up any
>> farther.  Instead you have to start by dragging up the divider between
>> the pane listing the classes and the button pane then drag up the
>> overall divider leaving enough space for the buttons.  Not intuitive in
>> my book.
>>
>> Ken
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

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

radoslav hodnicak
In reply to this post by Chris Muller-4

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:

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

Reply | Threaded
Open this post in threaded view
|

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

Chris Muller-3
In reply to this post by Frank Shearar
> 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..