[smart menus with memory]
Another option would be to always display everything, but add a first
section to each menu that has the 3 most common options. Make page-down
go to the next section. Then the muscle memory isn't cancelled, because
you can alway pagedown and start the usual sequence.

Combine this with the current filter-as-you-type, and I think it should
be pretty fast in the general case. 

I think like Tim's suggestion for dealing with limited screen real
estate - a simple scrollbar, only when needed. It's not fun, but it
should do the trick.

Daniel

Ned Konz <ned at bike-nomad.com> wrote:
> On Thursday 05 June 2003 08:57 am, Daniel Vainsencher wrote:
> > Those ideas sound cool.
> >
> > I would really like to see keyboard control of menus and other
> > common morphs become more practical.
> 
> Me too.
> 
> > For menus, I think the most important thing is to figure out and
> > solve the conflict between menus for PluggableTextMorphs, and
> > proper focus control.
> >
> > Then keyboard menu functionality would be much more accessible, and
> > any enhancements would be much stronger. I think the more... type
> > menus will eventually need to go, since they prevent any general
> > design solution to this problem. IIUC, this is what you're talking
> > about?
> 
> Yes, I'd like to have a more general solution to the big menu problem 
> that can work with screens of arbitrary size. The problem is that 
> there isn't very good management of the menus. Some automatically add 
> the "more.."; others don't. I'd like to see the menu management 
> always be polite enough to wrap the menus somehow on shorter screens. 
> One way to do this more nicely, I thought, was to initially display 
> only the most commonly used items if there wasn't enough space (or 
> maybe always). Then you could display the rest if desired (or maybe 
> if you left it up for long enough) in a way that wouldn't obscure 
> menu items.
> 
> > For example, adding an attachment to a Celeste mail from a
> > directory that has lots of files is depressing - I now have to
> > search through >10 page - more, more more... And keyboard control
> > doesn't help, because it does operate on the whole list, just on
> > the subset being displayed.
> 
> Well, using a long menu as a file selector is a problem without proper 
> visualization and navigation.
> 
> > I think menus as constructed by applications should not know
> > anything about size constraints to layout - they should simply
> > reflect the logical structure of the options.
> 
> They do, generally (except that sometimes people use submenus). 
> However, only one kind of menu is actually managed.
> 
> > Then the morphs can do whatever tricks are useful.
> >
> > Daniel
> >
> > Ned Konz <ned at bike-nomad.com> wrote:
> > > On Thursday 05 June 2003 03:18 am, danielv at netvision.net.il wrote:
> > > > This change is interesting, it does the job in a very
> > > > unorthodox way.
> > > >
> > > > I haven't made up my mind yet if I like it. What do others
> > > > think?
> > >
> > > I'm not sure about it myself.
> > >
> > > I think it could be done better. I've started to play with
> > > something that condenses menus based on "most used" statistics
> > > (kind of like the new Windows does), as well as thinking about
> > > using the keyboard filtering to actually shorten the menus even
> > > though they may have continuations.
> > >
> > > --
> > > Ned Konz
> > > http://bike-nomad.com
> > > GPG key ID: BEEA7EFE
> 
> -- 
> Ned Konz
> http://bike-nomad.com
> GPG key ID: BEEA7EFE