[ENH] LongMenus-nk ([et] more opinions..)
ned at bike-nomad.com
Thu Jun 5 22:16:33 UTC 2003
On Thursday 05 June 2003 03:21 pm, Daniel Vainsencher wrote:
> [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
Not everyone has a pagedown key.
(I guess I do on my desktop machine, but I have to hit a modifier to
get to it. Definitely not something I use often).
Or even keys or the space for the extra options, for that matter, at
least on tablet PCs or PDAs.
I guess this could be a pref, though.
> 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.
What about menu items vanishing as you type?
> 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
> > > > > 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
GPG key ID: BEEA7EFE
More information about the Squeak-dev