[231] in Athena User Interface
Re: Usability testing
daemon@ATHENA.MIT.EDU (Christopher D. Beland)
Fri Jun 23 08:31:05 2000
Message-Id: <200006231231.IAA08625@No-Whammies.mit.edu>
To: aui@MIT.EDU
Date: Fri, 23 Jun 2000 08:31:02 -0400
From: "Christopher D. Beland" <beland@MIT.EDU>
Ok, I summaries a lot of your comments in annotations on my document,
so they'll be on record. Some of them merit replies...
In This Email:
- What to put on taskbar(s), where to put it/them
- Window actions
- Windows and Mac themes
- Shortcut binding
On the Taskbar
So I configured my login to look like what I think the default should
be. I quickly ran out of room on the taskbar, which is why I was
wanting to get multiple rows out of the panel. (Yes, you can make the
tasklist more than 2 rows, but you can't have more than 1 row of icons
and applets per panel like you can in Windows.)
What I have, from left to right:
- Icon: Gnome menus
- Icon: Mail reader (exmh for now)
- Icon: Web browser (netscape)
- Icon: Text editor (emacs)
- Icon: Terminal (xterm, soon to be gnome-terminal)
- Icon: Help (Gnome help browser)
- Icon: File manager (gmc for now)
- Applet (narrow): Removable media (non-functional)
- Applet (very wide): Tasklist
- Icon: Lock screen (panel GUI for xss)
- Icon: Logout (Gnome logout dialog)
- Applet: Text-only clock showing date and time
(And yes, all the icons are ugly - especially the cursor you get over
the minimize button on window, I think - and some of them are
dangerously confusing, and we are working on getting better ones, but
may need help.)
So the problem I had was mainly with the tasklist (the "icon pile" for
active and/or iconfied windows). When I had it on "make an icon for
all windows, iconified or not" I found I couldn't read the titles of
the windows. Then again, I may be atypical in opening a lot of
windows at once, and needing to see the latter part of the window name
so I know what host my emacs and xterm windows are running on, and
what web page my Netscape windows are looking at. Normal users may be
happy just seeing the icons (which are actually nice) and a truncated
name.
To solve this problem, I gave the tasklist a panel of its own at the
bottom of the screen, and moved everything else to the top of the
screen.
I still wasn't satisfied, so I put the tasklist in "only show
iconified windows" mode and popped the logout, lock screen, and clock
thingys to a small panel in the upper-right (where the Dash clock and
logout thingys are now). This is what I'm running now, and I kind-of
like it, though if I didn't have such a dinky monitor at home, I could
probably be happy with everything on the bottom. But I kinda miss
having *all* my windows listed as icons, because sometimes I lose them
under others. But maybe I'm ingrained. Then again, the Window
interface does things the same way I'm used to; maybe for good reason,
or maybe just biasing our users' preferences in that direction.
To resolve this, I'll add this sort of configuration question to the
list of tests. Dan's configuration is also nice:
> I use a tiny panel with icons and a clock at the top of my screen,
> and a large auto-hiding panel with the task list at the bottom. I
> think having the tasklist on an autohiding panel works very well,
> and lets you make it nice and big without worrying about it stealing
> lots of screen real estate. YMMV.
Note that icon lists work OK vertically, too; the tasklist does not.
I tried an L-shaped configuration, but my graphical design sense
kicked in and complained about things being "uncontained" and
"clashing."
On Window Actions
tb writes...
>> - Right-click to get pulldown menu is not obvious enough; add button
>> instead. Make it stay on top for very narrow windows, so they can
>> be closed, minimized, maximized, etc. intuitively.
>
> Which pulldown menu for which application?
yak also asks:
> Move is not [on the pulldown menu] (why should it be?).
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.
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.
yak writes...
> For the record, there are no bindings in sawfish as I have
> configured it that use double or triple clicks.
Users everywhere will sing your praises! 8)
<marypoppins>
"Super-hyper-open-apple-meta-exclamation..."
</marypoppins>
> For the sake of debate, the menu currently has "raise", "lower",
> "iconify", "maximize", "unmaximize", "close", "close forcibly",
> "frame style", and "frame type".
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? I suppose I could make a feature request of the
maintainer and leave it at that, or maybe there are third-party tools
available? This is only important for *real* power users, who might
very well be happy hacking code, anyway.
On Windows and Mac Themes
tb writes...
>> - Some iffy survey results came back on what people want Athena to
>> look like. 44% said Unix, 31% said Windows, and 7% said Mac. More
>> reliable numbers give 40%, 80%, and 25%, respectively, on
>> familiarity with interface.
>
>AFAICT, "More reliable" means "more what Beland wants". At least, can
>you say what makes you think numbers B are more reliable than numbers A?
The former was from a survey that had a smaller N and had reported
sampling biases (i.e. groups of Unix lovers filled out the survey with
the intention of biasing the results). Also, the question that
produced those numbers is measuring users' perception of what the
interface would be like, which is almost certainly different from our
perception of what the interface will be like and/or prototype
designs. I think that users might associate the Unix interface with
more power and reliability, and thus might be biased against the
others. Taking those numbers at face value would mean that people
like MWM, which is inconsistent with spontaneous comments both from
surveys and anecdotally. (Those same comments provide support for the
"Unix is powerful, please don't hurt that" theory.)
The latter numbers are extremely consistent with home ownership and
operating system choice, as well as anecdotal evidence and spontaneous
comments. But like I said earlier, feel free to ignore my
quantitative research in favor of our agreed-upon principles.
tb writes...
> If cannot find ones, I think it's pretty low priority to write ones;
> again, "n% prefer the windows interface" does not say anything about
> which things they prefer; the things that themes configure may be
> utterly irrelevant (as long as they can find the buttons at the top
> of the window, which yak is being very careful with).
I hear considerable buzz among people who know how to change window
managers about fvmw95. "Why do you run that? It's so slow and
clunky! Try twm." I say. "But I like that it looks just like
Windows!" they say.
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.
On Shortcut Bindings
tb writes...
>> - 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?
