"There is tremendous
duplication between the file navigation facilities offered by GMC,
Nautilus and the built-in "Open" menu in Star Office.
Other applications may have their own quirks in that regard. ...
Your interface style guide should have guidelines about how
applications that save and open files could/should handle tasks
related to file management."
Issues that need more design
thought
Those who are used to
single-user systems may have trouble understanding how UNIX
supports multiple users on the same machine
Logging into another computer
across a network may also be a new concept.
Getting used to the uses of the
various mouse buttons.
The idea of each file having
permission levels.
"My stable of newbies can't
stand to go back to windows now because they quickly became addicted
to the general linux idea of being able to configure everything to
work the way THEY want it to, rather than trying to figure out how
windows will force them to work. They express a feeling of
liberation. The most common complaint is that they cannot find
enough documentation on how to configure and what to configure.
This is a valid complaint - and a problem for many open source
projects."
"We should NOT be trying to
dumb the system down to the level of windows. We should continue to
build on and highlight the advantages offered - flexibility and
power. Try taking a user unfamiliar with Windows and have them
perform the same tasks. They will have a learning curve also. Same
for the Mac. Part of the confusion faced by your testers is their
misconception of the system, much brought about by the limitations
learned under windows. Their mental model of the system does not
match reality. It is impossible to completely remove the learning
phase, but it can most certainly be made easier by using more easily
understood icons, by making help more easily available, and
providing clear and appropriate feedback. We should not remove the
power and flexibility just because they don't use it all
immediately. Users can and will learn to make the system work for
them, and will appreciate the power and flexibility. Many of them
have put considerable effort into figuring out how to work in
windows to get things done, and will be much happier once they see
that they can do things their way instead of the one "blessed"
way (that may or may not work...)."
"When I start this thing
(Nautilus) it starts all this other stuff that I don't want. It
sometimes complains about something missing that I don't care about.
It's big and slow, just like windows." (Note - they really
dislike KDE for the same reasons - much amplified)."
"I'd also like to throw in
one more UI idea, in the hopes that someone up there might be
interested: Windows hasn't really used "barber poles" (aka
infinite progress bars) to indicate that a task of unknown duration
is in progress -- instead, it uses a totally nonstandardized range
of animated icons. At the very least, this places the burden on the
each programmer of producing a good chunk of appropriate animated
art. It also takes up a significant amount of screen space. The
barber pole solution has been well recieved on the MacOS, and in
various Windows products, like Navigator. I would like to encourage
the creation and use of a barber pole widget."
"'Really do such-and-such?'
can be slightly opaque in meaning to a naive user, but more
importantly, is suggests that the computer thinks the user's
command ought NOT to be executed. I recommend: It's more tactful to
ask 'Are you sure?', which suggests that the computer's attitude is
one of concerned help and moderate skepticism rather than outright
disbelief."
"I agree that the
relationship could be made more distinct - I suggest having "Colour"
at the top of the dialog, with the Wallpaper controls below that in
a groupbox where the "Wallpaper" label has been replaced
by a check box labelled "Add wallpaper". "
"GNOME should allow for users
to switch between novice, intermediate and expert levels. All GNOME
applications could be designed to accommodate these levels.
Applications that are designed only for advanced users could present
an alert when launched in beginner mode warning of the possible
skill discrepancy."
"Entries on the login screen,
such as 'marge-hci' should have popup descriptions to aid new
users."
"Overall, it seems like many
of the applications would benefit from an "Advanced Mode"
and a "Basic Mode" much like Apple(TM) used in MacOS 9.
This would help in the configuration menus and in things like the
search function in Nautalis, where the average user has no use for
such features as "regular expression" searching, even if
they are better explained, as you suggest."
It might be useful to have a GNOME
tutorial that provides brief training sessions for novice users
transitioning from a non-Unix system. This would eliminate 'hidden
features' and a more comfortable learning curve.
"Use 'Restart' instead of
'Reboot'."
Instead of using Yes/No dialogs,
the option to proceed should be replaced with the appropriate action
verb, and the option to keep from proceeding should be replaced with
'Cancel'. Thus, "Are you sure you want to cancel the missile
launch? [Yes] [No]" , becomes "Are you sure you want to
cancel the missile launch? [Cancel] [Launch]"
You said: "We can't let the
development process, of componentized, modularized pieces from
different origins, permeate up to the user's level." Yes we
can and should. We should also provide simplified views for
beginners. Frustration at too much complexity when first learning
is bad. Frustration at too many limits after the initial learning is
also bad. We need to provide simplified and consolidated interfaces
for beginners, but we should not remove the ability to get at the
underlying systems easily. More power and flexibility takes longer
to learn, but it is worth it - according to my users. We need to
make it as easy to start and learn as possible, but we should not
take away the power."
"Users NEED to learn about
that right mouse button. And the MIDDLE button. I know many
windows users who have as many as 7 buttons on their mice. They did
not know what to do with all of them "intuitively". Some
learning is required. We need to make that learning as pain-free as
possible. We should not remove access to the real power of the
system just to make the first few minutes of using it without
reading the manual easier."
"The GNOME Usability Study
Report at
http://developer.gnome.org/projects/gup/ut1_report/logging_out.html
recommends that the logout dialog Halt "checkbox label reads
'Suspend (Halt - stops the processor)'". I belive it should
say 'Halt (stop for poweroff)'. This better describes what happens
when the checkbox is chosen. (Usability Principle: Match between
system and the real world.)"
"I think the Sun people
mistook that Halt to mean the old-fashioned halt, which was not a
nice thing to do (it did stop the processor)... in most systems with
more recent versions of sysvinit, halt just runs shutdown. It would
be best if it just said "Shut Down" I think. :)"
"People _are_ used to having
to powercycle to recover. It's some folks default response! So I'd
go for the clarity of 'Turn off computer'. It contrasts plainly
with 'Restart computer'."
"I think the Sun people
mistook that Halt to mean the old-fashioned halt, which was not a
nice thing to do (it did stop the processor)... in most systems
with more recent versions of sysvinit, halt just runs shutdown. It
would be best if it just said "Shut Down" I think. :) It
already does [I think]. I know it's been applied to the
gnome-session, and I expect to gdm as well. "
"The Login / Username and
Password should not appear on the same screen because it is easy
for the text box focus not to change. This means that a user could
enter their password into the username (login) box by mistake.
Since text in this box is visible this would compromise security.
I would add a section on the password screen indicating that the
text will not be visible (I know most users of any system know
this, but it doesn't hurt) The help system - while I agree that the
extra items - HTML, man etc .. are distracting, I would hestitate
at using Gnome Help, since the help system is for more than Gnome,
it is for the whole OS. I think "Get Help" would be
better. Then the help browser / Application could be customised to
look for help on what you want."
"On the whole, the Gnome
system is getting better, though I do think that some icons could
be better and their placement more ordered. Having multiple ways to
complete tasks is not a problem either, in fact I would encourage
it. Everyone does things differently. I would want a more consitent
approach though so that these multiple ways worked for each task."
"Make every legend
=ABWinLux=BB or else, quite plain, for example: [ Username (login):
], [ Machine Name: _name_ ]. ... By all means, bring all comments,
instructions, help text, etc., over to standard english. In
Unix/Linux too many of them read like sourcecode written in =ABC=BB
with all coherence stripped (pun intended).
Be prepared to write parallel
=ABman=BB files (pages) devoid of jargon. (This was not addressed in
your study due, I presume, to its introductory nature inasmuch as
there is no such thing in Windows). These should not be mere
transliterations. It's not the words that count, it's their meaning
in sequence, that is, the ideas they jointly convey. The Windows
culture and language must be addressed on its own terms before they
can be translated usefully. Interpret precisely and explain in
standard English everything that may be unique to Linux. This helps
Linux, and Linux is the Future. Put together clear PS or PDF
user-oriented help files. (Not user-friendly, please, too often,
user-friendly becomes an excuse for repetitive dumb-user babble.)"
'The problem with the addition of
clock to the panel would be replaced cleanly with a panel
configuration dialog. Putting settings into menus is misusing menus.
They're not good for it, because an user wants to configure the
system in one run, not clicking again and again thru the same menu
levels. There could be a 'Select a clock' dialog, which would
consist a list with a scrollbar, and a preview what the clock looks
like."
" 'Terminal Emulation
Program' should be 'Command Prompt', and 'Integrated Help Sytem
(Info, man, HTML)' should be 'Gnome User Guide'."
"You recommended "username"
instead of "login"; why not "User Name:" or
"Please type your assigned 'user name' here." (so long as
you clearly call it "your user name" when assigning it).
The principle here is not to force yourself to use single words or
to use internal spelling conventions (such as "username"
without spaces. You might even instruct "Please type your
assigned 'user name' here and then tap the Return key." Why
not? Experts won't even bother to read it so it won't slow them
down, and it helps the novice."
"Another suggestion: the "OK"
button is an invitation to use the mouse to close the box. We know
that the users have just been typing, why then ever ask them to
move their hands from keyboard to mouse? It wastes over a second (on
average) and adds to the motions that cause RSI."
"Another suggestion involves
too much user overhead: "Not knowing what 'marge-hci' was did
not hinder users from successfully completing the task. However,
novice GNOME users' confusion did highlight an opportunity for us
to provide more assistance. To support new GNOME users we suggest
including a Help button or menu in the login dialog. Selecting this
button or menu should nvoke Help with information about the
elements and terminology found in the dialog..." There is
plenty of room in the box to say "'marge-hci' is the name of
this computer. The system will use the name when it is talking
about this computer." or some such. Why bother the user with
accessing a help system when you can just put the information where
it's needed?
"A number of suggestions for
a better logout icon are given, along with a recommendation for
testing. What would certainly have worked (guaranteed, without
testing) was button had containing not an icon but the words "Click
here to log out." The idea of not using an icon on this button
does not seem to have occurred to the designers, caught up in
standard GUI methodology. If this suggestions offends the graphic
eye, then put the design in the background with the words overlaid
clearly. The relevant design principle is not "Match between
system and the real world" but "Don't use pictures where
words work better." I guess you could say that this is a better
match to the user's real (cognitive) world. This same suggestion
applies to all the other icons that gave the test subjects trouble.
They also suggested improving the tooltip, which would have been
unnecessary if the buttons had contained text. Please note that
tooltips are words used to explain an icon; they are never icons
used to explain words (though now that I've said this, somebody
will deliberately build a counterexample). Even if there are a
handful of exceptions, words should be the first choice. "
"A good design principle is
to eliminate user preferences wherever possible. This is another
example where open-source development leads to poor interfaces;
everybody wants it to work the way they are accustomed to an
interface working. This leads to clutter, and to usability and
maintenance difficulties"
"Seeing the successful
deployment of MIT's analogs to your own usability testing in this
large scale way, I invite the GNOME developers to consider adopting
some or all of our solutions as implementations of the guidelines
raised. We might end up saving you folks some work. (And yes, it
would save us changing our look and feel when your improved versions
come along.)" [The MIT study can be found at
http://web.mit.edu/aui/notebook/charter.html]
"I agree with alot of what
you said, except where you talk about removing choices and
customizability from users. Nautilus has a drop down on preferences
that lets you select beg. inter, or advanced. This should be
integrated with the control panel and should apply to both. It will
help solve much of what is shown here. Second: I agree that the
three places to change a font is freaking crazy. The theme manager
could be shown as a subset of the window manager and be the only
place provided to change the font. Since theme managers have the
ability to select a default font (a feature that advanced users
like me like) this should be clearly explained in the panel and the
current override provided. Good stuff about the "Font"
wording though."
'I have to think that open source
people working on gnome make gnome for themselves as much as anyone
else... and that they must be comforable with the GUI or they would
not use it. If we take away options or programs to 'Dumb it down'
for newbies-- we are not doing anyone a favor. I hope the advanced-
intermediate - beg. selection idea can solve this without removing
any functionality that I currently use. I already had to quit using
KDE because of its dorked-ace window manager. I don't want windoze
or Smac. I like GNOME's power. I like the window manager and I like
having all the gnome programs and applets and keybindings. And I
like the name applets. I don't think we should change the
terminology of everything to make Joe Six pac happy. If you do you
will piss off Mary UNIX Lady, and you don't want her wrath. I think
a distinction needs to be made between easy to learn and easy to
use-- indoze is easy to learn and it sucks to use. Unix is hard to
learn and a delight to use. The user levels setting of Beg, Inter,
Advanced can give us both without sacrificing anything-- Just pick
the setting you can handle. And please don't make everything
right-click---- three buttons three times the power-- eliminate
confusion new users have through tutorials and documentation, not
by emulating a dumb-ace OS. It is no wonder one of your test people
who had problems with right-like was a MAC user. Narrow minded
GUI's make for narroow minded users-- one button on mouse for 15
years-- cannot comprehend three buttons-- brain overloading....AHHH.
Must use cnt-openapple-shift-mouseclick- umlock to access feature,
what is right click? '
'What is needed to fix confusion
is a good users manual, like you suggested. The ones so far are
quite abit better than they used to be, but need some integration
and organization. I would set up a seperate project leader to
integrate all GNOME documentation for consistent usability and
feel. This would apply to GNOME programs as well, such as GNUMERIC
and the GIMP. This person would not initially write the documents,
but edit and compile them-- a tech writer.'
'You recommended 'username'
instead of 'login'; why not 'User Name:' or 'Please type your
assigned 'user name' here.' (so long as you clearly call it 'your
user name' when assigning it). The principle here is not to force
yourself to use single words or to use internal spelling
conventions (such as 'username' without spaces. You might even
instruct 'Please type your assigned 'user name' here and then tap
the Return key.' Why not? Experts won't even bother to read it so
it won't slow them down, and it helps the novice.'
"You quite correctly suggest
that 'developers [should] involve a technical writer in the review
of any terminology, error messages, or other on-screen text'. Might
as well suggest that an interface designer be involved, too."
"For panel buttons that are
important but that are difficult to translate into a graphic icon
could be replaced with text-only labels. This same suggestion
applies to all the other icons that gave the test subjects trouble.
They also suggested improving the tooltip, which would have been
unnecessary if the buttons had contained text."
"I agree with the group's
suggestion that terms such as 'regexp' be replaced by the words
'regular expression'. This suggestion needs to be used more widely.
Especially in drop down menus, which are transient, we can afford a
lot more words, in those frequent cases where they would be
helpful."
"Another recommendation was,
'We recommend providing more visual indication that the user is in
viewer mode and cannot edit.' As has been shown repeatedly, no
amount of visual indication will always work, but if you cannot get
rid of the mode, then changing a border or the cursor shape is not
nearly as satisfactory as (1) giving a readable message (as was
done!) and carrying the grey background or some other design
element across the entire text. Text that is non-editable, for
whatever reason, even if it is part of a menu, should have a
uniform appearance, different from that of editable text. (See The
Humane Interface, p 41 for more discussion)."
"The log out dialog that you
recommend is inefficient. While correctly separating the Halt
option and renaming more clearly (good moves) you did not simplify
the entire box by having only three buttons,each of which did the
action listed on it, and eliminating the silly 'Yes' and 'No'
buttons at the bottom. That would substitute three large buttons
(easier to use) for three tiny ones (perhaps you can click on the
words, giving a larger target, but there is no way to know that
from the box design) and two large ones. As we know, due to
habituation, choose-and-confirm is no more secure than simply
giving the choise."
"'Match between system and
the real world' is a poor heuristic; we all have our own worlds,
and I'll bet that some of the bad design choices were caused by a
programmer matching the system to his or her real world. It is also
a vague standard."
"Another [recommendation]
states that 'Dialogs should not contain information which is
irrelevant or rarely needed.' but the researchers did not follow
this advice in some of their own redesigns. The principle, The
claim that 'The system should always support multiple ways of
accessing functionality' is wrong, perhaps even backwards. In fact,
in places, the authors correctly tell us to do just the opposite."
The tree sidebar in Nautilus
requires some reorganization: "Take a look at:
http://www.eps.ufsc.br/~juliano/nautilus/tree.png Right now, the
sidebar shows the tree as it is. It shows the root directory, and
when expanded shows home, usr, tmp, and so on. My suggestion is to
mask things a little, making navigation easier. In the base of the
tree is better to have the user home, the machine (/), and removable
media (when mounted). Maybe we can put here the magic desktop URIs
from RedHat Labs too. I think Windows, KDE, Mac work like that.
... I would be glad to reorganize the tree view but I think a bit
of thought overall needs to be put into how Nautilus presents the
filesystem and what common shortcuts there are. I'll post my
thoughts soon."
"I would really like to
change query-drags to be based on the middle button instead of the
right button, so the right-click menu can come up faster. Does
anyone object to doing this? I know Pavel (who did a lot of the DnD
work) objected before, but he no longer works on the project."
The change zoom widget on the
Nautilus toolbar needs to be rethought as well: "Take a look
at: http://www.eps.ufsc.br/~juliano/nautilus/zoom.png Again this
is just to make navigation faster. For example, I'm in the default
view (100%) and I want to zoom to 400%. I need to pass to 150%, then
to 200% and finally to 400%. With the widget change I can pass
directly from 100 to 400%."
"I decided to start working
on adding the ability to make components editable and have a
reasonable UI for saving and such. Since one of the top usability
concerns with Nautilus according to Sun's report is the fact that
the text view does not allow editing, I figure the best solution is
to make it allow editing."
"Regarding the proposed change to how "Halt" is portrayed in the
logout box: it doesn't go far enough. "Suspend" sounds to me at least
like something temporary and easily undone. I think the information
given there should include an indication that "halt" means that
the machine will
be shut down."
"It's too easy to remove things
from panels... One way to fix this problem would be to have a
"foolproofing"
option, probably in the Control Center under Panel (or under Advanced),
which would be enabled by default. If foolproofing were turned on, GNOME
would ask "Do you really want to add/delete to/from the
Panel?" This would cut down on novice users' frustration when they
accidentally delete something from the panel and don't know how to get it
back, as well as providing feedback that the item is being added to or
removed from the panel. Allowing users to turn off foolproofing would
enable power users to modify the panel without being harassed by dialogue
boxes."
"The tasklist and pager are
at least as important to
the panel as a logout button or screen-lock button, if not more so.
They should be on the "Add to panel" menu, instead of being hidden
under "Applets"."
"Another problem users have
noticed here is visibility of
important items on the panel. For example, I found the pager as
currently implemented very difficult to find on the panel. I thought it
wasn't there until someone pointed it out to me. The default theme
should have the pager be a different color than the rest of the panel,
and perhaps have default labels for the different desktops."
Users don't necessarily know that
they are using GNOME. Some of them have asked me for help, and I ask
them "Which desktop are you using?" Many of them aren't sure. They just
know that they are using the default desktop for their machine. Some are
confused by the "KDE Programs" choice in the foot menu, and think they
are running KDE. It would be helpful to have the login screen tell users
what desktop they are logging into, and perhaps to have the word "GNOME"
on the foot button."