I have noticed a general UI styles in Squeak that I question.
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.
2) The menus are too tightly spaced, and in too small a font. This can make selecting the proper choice much more difficult. The Yes/No promps in particular create very small targets. This may have been done to allow menus on very small screens, but should be adjusted on regular displays. A padding between menu items would help a great deal in both usability and readability.
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? In particular the use of circular menus would be more usable.
Michael
On Friday 24 December 2004 11:52 am, Michael Latta wrote:
I have noticed a general UI styles in Squeak that I question.
- 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.
We don't have disabled menu items. However, there's many cases where a menu item will be visible or not depending on context. Those cases where menu items appear but don't do anything are bugs.
Whether inactive or unavailable menu items should be visible but distinguished as unavailable vs. being invisible is another question.
- The menus are too tightly spaced, and in too small a font. This can
make selecting the proper choice much more difficult. The Yes/No promps in particular create very small targets. This may have been done to allow menus on very small screens, but should be adjusted on regular displays. A padding between menu items would help a great deal in both usability and readability.
Why not just change the menu font? You can do that if you want. If you look at the 3.9alpha default look (from Diego Gomez Deck), you'll see that there is a larger default menu font. See the attached image.
- 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? In particular the use of circular menus would be more usable.
A massive re-organization of the menus would be the first order of business here.
However, I don't find that hierarchical menus work particularly well beyond two levels (one level of submenu).
Circular menus are easier from a mouse point of view but often seem to take up more screen real estate for the same number of items.
Michael Latta lattam@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.
- 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.
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.
- 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.
- 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.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Fractured Idiom:- POSH MORTEM - Death styles of the rich and famous
On Dec 25, 2004, at 11:08 AM, Tim Rowledge wrote:
Michael Latta lattam@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.
- 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.
- 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.
- 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@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Fractured Idiom:- POSH MORTEM - Death styles of the rich and famous
On Sat, Dec 25, 2004 at 02:13:28PM -0800, Michael Latta wrote:
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).
Perhaps some entrepreneurial sort of person could produce a cute little Squeaky The Mouse accessory that looks like the mouse on wheels at Squeakland, and has properly colored mouse buttons arranged across its hindquarters.
Dave
On Sat, 25 Dec 2004 11:08:32 -0800, Tim Rowledge tim@sumeru.stanford.edu wrote:
And of course, menubars are the work of Dark Forces and should be rejected completely.
Apple?
Blake blake@kingdomrpg.com wrote:
On Sat, 25 Dec 2004 11:08:32 -0800, Tim Rowledge tim@sumeru.stanford.edu wrote:
And of course, menubars are the work of Dark Forces and should be rejected completely.
Apple?
Why thank you - as long as it's an organically grown Gala. <crunch>
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Fractured Idiom:- IDIOS AMIGOS - We're wild and crazy guys!
squeak-dev@lists.squeakfoundation.org
-
Blake -
David T. Lewis -
Michael Latta -
Ned Konz -
Tim Rowledge