On Dec 25, 2004, at 11:08 AM, Tim Rowledge wrote:

> Michael Latta <lattam at mac.com> wrote:
>
>> I have noticed a general UI styles in Squeak that I question.
>
> Quite a lot of the UI in Squeak is really not terribly well handled. I
> wish we had more suitable resource (time, experienced talent, etc)
> available to iprove this area.

Good to know the option exists to improve things.

>
>>
>> 1) The menu items in the system do not enable/disable based on 
>> context.
>>   For example you can set a gradient fill on a morph that does not
>> support gradient fills.  You can select "remove method" from a method
>> list with no selection.
> Greying out or otherwise incapacitating menu items is probably
> something that could be done fairly simply from the menu point of view
> but it involves quite a bit of work in each application to make use of
> it. Even without such incapacitating it is possible to make a suitable
> menu with innapropriate items left out when the menu button is pressed.
> Not many apps seem to bother right now.

I suspect improved UI will come over time with new versions of tools.  
If new things like OmniBrowser, MC, etc could be done using some of 
these UI approaches things will move in that direction.

>
> Jef Raskin is currently trying to convince people that you should
> design systems that work without need of such greying out (etc) by
> making sure that all options work (as in do something intelligable) at
> all times. Nice idea but seems to me to be a really difficult thing to
> achieve. Take a look for pages on The Humane Interface if you're
> interested.

Yes.  We used him as a consultant and read the book.  In general, to 
get benefit from his ideas you need to create an entirely new UI.  
Which is why I am looking at some of those things for a new project.

>
>
>>
>> 2) The menus are too tightly spaced, and in too small a font.
> Ned pointed out that the font can be easily changed, and it would
> probably be easy to alter the leading. Personally I like menu items
> quite close though. What I don't like is having gaps in the selectable
> areas - those regions between menu item texts where you aren't 
> selecting
> anything.

I agree that the menu items should be fully covering the area.  I 
suspect that the grouping of menu items by lines should really be 
replaced with a sub-menu, or other approach.  When you need to break up 
the list of actions, it is too long!  But graphical menus break down 
after a certain number of options.  The use of ring menus to present 
hierarchical menus allows easier gesturing, but it still is an issue.  
Jef's use of command entry actually works pretty well for a touch 
typist.  Do not forget that the GUI was meant to support casual users.  
Some way to deal with a large number of verbs is important.  Our 
current application has >150 unique verbs, and if you consider the 
contexts of those verbs the number is > 700.  But, a restructuring of 
the approach can greatly reduce the number of verbs, by allowing more 
general gestures to replace specific ones.  For example, in Squeak 
there are many commands to deal with the appearance of a morph (color, 
border, etc).  These are duplicated on the menus, and on the properties 
screen.  Having an enlarged version of the morph with a halo of tools 
that could drop various colors and borders on the morph would replace 
all those menu items with a set of object manipulations.  Just an idea. 
  The real issue is too many options presented as equally important 
verbs.

>
>
>>
>> 3) There are very long menus that require selecting "more..." to get
>> the remaining selections.  Has anyone thought about hierarchical menus
>> that would bring more choices closer to the mouse point and be easier
>> to both use and habituate on?
> Hierarchical menus of shallow depth would indeed be an improvement in
> many cases. Ought not be a terribly difficult thing to implement given
> that we already have menus. Again, it's getting all the apps to make
> use of them properly that would be the labour.
>
>> In particular the use of circular menus
>> would be more usable.
> I'm pretty sure those are patent encumbered - oddly enough by a patent
> gained by an old Smalltalk using company, Momenta. They were a putative
> competitor to the Active Book and the PenPoint/Go machines back in the
> 89-91 timeframe. Momenta and Active Book were both Smalltalk systems!
>
> And of course, menubars are the work of Dark Forces and should be
> rejected completely.

Right.  Unless you have the menu bar at the very top or sides of a 
small screen, they are more harm than good.  The smalltalk approach of 
menus where the mouse is, are far better.  Calling the mouse buttons by 
colors however is a pain (since we do not have Alto mice with really 
colored buttons).

>
>
> tim
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Fractured Idiom:- POSH MORTEM - Death styles of the rich and famous
>