Circa 2001-Jul-26 13:56:01 -0400 dixit Gregory J. Barlow:
: > From the perspective of some users, there's no reason that
: > [MiddleClick] on the Workspaces menu ought not to make the menu go
: > away, [...] Yet middle-clicking appears to do nothing.
:
: The workspace menu is a remnant from when you generated it by pressing a
: button on the toolbar. When I first wrote the patch that changed this, a
: middle click simply opened this menu in a different spot. Because you can
: access the workspace menu from the root menu also, keeping all close
: behaviors the same is the best path.
You obviously are missing what i'm saying. If [RightClick] on the root
window posts the Applications menu, and [RightClick] again without
moving the pointer closes it, then, if [MiddleClick] on the root window
posts the Workspaces menu, [MiddleClick] in the same spot ought to
close it. If the Workspaces menu is posted from somewhere else, the
software should be able to figure out the difference. The user
shouldn't have to.
: > In the same vein, one might expect that [LeftClick] on a submenu's
: > parent item would close it. [...] How do i close it?
:
: The submenu is still connected to the parent. To get rid of the submenu,
: select something else on the parent.
Say the parent menu is pinned/torn-off. I click on a submenu item,
look at the submenu, and change my mind, deciding i want to go back to
what i was doing. How do i get the submenu (and the highlighted parent
menu item) to go away? I can't without putting my leg up over my head
to rest behind my neck. I should be able to.
: > Obviously, putting close buttons on pinned (torn off) menus' titlebars
: > won't solve these problems. [...]
:
: Thats my point, close buttons dont really solve any problems with
: consistency, and they dont provide complete redundancy for closing
: menus.
But the menus where they don't work aren't pinned/torn-off menus;
they're merely posted. Torn-off menus act differently than menus that
are merely posted---they shouldn't look the same. In fact, they act
more like regular windows: you can move them around using the
titlebar. I maintain that, if they act a bit like regular windows,
they should look a bit like regular windows. Hence, the close button.
: > [...] That the menu is visible suggests that it's open. Not all
: > visible menus are torn off[....]
:
: The only way a submenu can exist on its own is to be torn off.
But why should i, the user, have to remember whether this is a
just-posted top-level menu or a torn-off submenu? The software should
remember this for me, and tell me in a subtle, unobtrusive, yet obvious
way.
: > : [...] adding a close button is not only inconsistent, its just
: > : redundant.
: >
: > Then a close button is redundant on a regular window as well, since
: > there's a perfectly good "Close" item on the titlebar menu. Likewise,
: > the resize handles, since [Meta+RightClick] can resize a window.
:
: Thats right. But a close button does not give complete redundancy, the
: other two almost universally do (unless the window doesnt want them).
You're too close to the code---to you, menus are the same whether
they're torn off or merely posted, and they're different from regular
windows.
From the point of view of human interaction, however, torn-off menus
act differently from merely posted menus; they act more like regular
windows. See the difference? To humans, it doesn't really matter that
the two differently-acting kinds of menus are the same; they act
different. They should look different---and making them look more like
regular windows gives human user a visual cue that they *do* act like
regular windows.
If you've not done any of the reading i suggested, then you really
should---Norman and Cooper are two fairly well-known experts in the
field, and, while many don't necessarily agree with everything they
have to say, their observations about design and software/human
interaction are spot on. In particular, while MS-Windows-centric,
Cooper's "About Face" gives concrete examples of both poorly and
well-designed user interface designs and explains why.
: > Then please give some references to back up your opinions.
:
: See the rest of this discussion.
I've seen the rest of this discussion. I asked for references, i.e.,
empirical, anecdotal, or even careful analogical evidence to support
your opinions.
--
jim knoble | [EMAIL PROTECTED] | http://www.pobox.com/~jmknoble/
| [EMAIL PROTECTED] | http://www.jmknoble.cx/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
PGP signature
