[234] in Athena User Interface
Re: Usability testing
daemon@ATHENA.MIT.EDU (Brad Thompson)
Fri Jun 23 14:45:59 2000
Message-Id: <200006231845.OAA24019@rat-thing.mit.edu>
To: "Christopher D. Beland" <beland@MIT.EDU>
cc: aui@MIT.EDU
In-Reply-To: Your message of "Fri, 23 Jun 2000 08:31:02 EDT."
<200006231231.IAA08625@No-Whammies.mit.edu>
Date: Fri, 23 Jun 2000 14:45:56 -0400
From: Brad Thompson <yak@MIT.EDU>
> I mean for the window manager. MWM has a button you push to get the
> menu of window operations. I've seen people on Athena for whom this
> is the only way they move, raise, lower, and close windows. (This is
> why I think Move needs to be on the menu.) As a general rule, naive
> users will not think to middle or right-click, or hold down a meta
> key. Some Windows users eventually learn that if they right-click on
> icons, they get a useful menu. This doesn't happen with widow titles,
> which (IIRC) have a button you press to get the pull-down menu. I
> hope the popup hints can mitigate this, so we don't have to put the
> close button near anything else (it would look like a cyclops in the
> middle, and the bottom corners wouldn't work as well). We can get
> confirmation of this from testing.
You don't need the menu.
There is no operation on the menu that normal users need to do that
isn't availible everywhere else. In the past ten years I have _never_
seen a Mac user tell me "I can't figure out how to move windows around.
If only it were on a menu!".
If users are going to be using Gnome, one of the most important things
they will learn is "right-click to get a context menu". If we don't
tell them this, we suck. If they don't learn, they will lose. This is
not just the window manager; it is so deeply ingrained into Gnome that
you cannot possibly hope to change it if you don't like it.
> Personally, I'm used to the middle and/or right mouse buttons lowering
> a window, and the left one raising, and moving if I hold it down.
> Thus having the menu button-activated instead of right-button
> activated would be quite preferable. (The middle button moves when
> pointing at the sides; this should not lower instead just because you
> are pointing at the title.) It's really annoying to have to pull down
> a menu every time I want to lower a window, since it's a very frequent
> operation.
This is what configuration files are for. Go into Control Center ->
Sawfish -> Shortcuts, and you will be able to rebind keys to your
heart's content.
> Come to think, "frame style" and "frame type" are much more useful if
> they are persistent and/or apply to all "zwgc" or "xterm" windows or
> whatever. But from what I'm seen, Sawfish just doesn't have that
> capability. Nor does it have any apparent user-friendly way to change
> the "what does right-clicking on the titlebar do" etc. bindings -
> that's managed at the theme-creation level, which involves actually
> writing code, right?
See above: use the control center. For more complicated actions, like
"I want all of my xterms to float below my zwgcs (which should look
like MacOS windows) except those to class sipb, which I want to float
below my xterms and have no borders", use Control Center -> Sawfish ->
Matched Windows.
> We are creating a really nice interface that will probably be better
> than the default Windows one. But I think that some people really do
> want all the buttons in the Exact Same Place and to be the Right
> Color, just for the sake of mental consistency with their home boxes,
> or the interface with which they are most familiar (overwhemlingly
> Windows).
>
> I do agree it's a reeeally low priority if they don't already exist.
Themes to mimic MacOS 6/9/X, Windows 3.1/95, Plan9, BeOS, Amiga, mwm,
and twm already exist.
> >> - What keyboard shortcuts for Sawfish should we enable by default?
> > Probably all the default sawfish ones.
>
> That's M-Tab circulates windows, nothing more. Surely there are other
> useful suggestions...perhaps a informal survey is in order?
There's a hell of a lot more than that. I'm working on seeing which
ones conflict with other programs. I'm planning to leave in all the
bindings that do not conflict with major Athena software (like Emacs).
yak
