[squeak-dev] Re: MenuMorph fitting to height of screen/window/etc

tim Rowledge tim at rowledge.org
Fri Jun 20 18:24:45 UTC 2014


On 20-06-2014, at 7:01 AM, Marcel Taeumel <marcel.taeumel at student.hpi.uni-potsdam.de> wrote:

> Well, the user may not want to manually browse those long menu entries. To
> alleviate this problem, there is already support for text-based search. In
> its current implementation, unmatched items gray out. We should consider
> removing them to reduce the height of the respective menu.

This is true but I need to keep the entire user experience as ‘original’ as possible since teachers really don’t want to have to explain more UI cleverness when the lesson is supposed to be about building scripts. I *might* be able to do neat tricks later.

> 
> Other approaches like columns and/or scroll bars do not help here because I
> think it is tedious to manually look for an item in a list longer than ...
> say 7 items. There was a book/article about that phenomenon... what was

That’s a long established UI principle and I completely agree with its value. I’d love to have time to improve the menus in the main system to make proper use of hierarchical menus and so on but…
Having said that, there is a possible place for long menus for choosing from lists like available language translations but the menus really ought to grow scroll bars or some other affordance when too long. Proper chooser dialogues are better, but again, compatibility is an issue for now.

It’s likely you’ve read it but just in case, I recommend my old friend Jef Raskin’s book ‘The Humane Interface’ for some very interesting ideas and a good bit of well documented advice.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- One too many lights out in his Christmas tree.




More information about the Squeak-dev mailing list