The Perfect User Interface
Posted 2 Feb 2001 at 11:00 UTC by maphew
The computer User Interface is something I spend a lot of time thinking
about, and even more time cussing and fretting
over. :) I have encountered a number interfaces that I wish were more
widely used. This document is my own small
attempt to help that happen. I'm very interested in your thoughts on
the matter.
The home page for this doc is
http://polarcom.com/~patawi/matt/musings/perfect-ui.html.
There are a couple of graphics to break the layout. I'll warn you in
advance,
this is pretty Windows centric since that's where the bulk of my gui
experience
is. I've been using Unices for a couple of years, but mostly from
remote terms.
My home linux box doesn't have enough muscle to run X comfortably.
Unlike what the title suggests, I don't know what the
Perfect Interface
is or might be. However I do have some distinct ideas of what it
should include
(in no particular order):
- shortcut keys for all commands (where feasible)
- direct dynamic customizability
- collapsing defining/configuring modes and display/reporting
modes
- context sensitive menus
- context sensitive position dependant keyboard shortcuts
(analagous key arrays)
- always hot command-line integrated with the gui
- a facade proposal
Shortcut keys for all commands,
wherever possible
and it makes sense. The best examples of this I have encountered are
exemplified
by the pixel magic programs, PhotoShop and The
Gimp. In these programs all of the primary (and most of the
secondary and
tertiary) tools can be quickly activated with a simple keystroke,
and
not some tendon-stretching chorded combination either. A
simple 'z'
or 'b' to select the Zoom or paintBrush tools, not Alt-Z or
Ctrl-Shift-B.
PhotoShop is slightly superior (for the moment) in that
it has
temporary tool assignment. You can have a paint brush tool active,
and if you
push and hold the space bar, the active tool becames the hand (for
panning).
The moment the space bar is released, the paint brush (or whatever
the previous
tool was) becomes active again. Alt while Zooming changes to Zoom
Out, Ctrl
to Zoom In. To be fair, Gimp also uses temporary tool assignment in
places,
but I picked PhotoShop as the prime example because it is more
complete and
far reaching throughout the program, at this moment in time.
Gimp fans, don't despair, because it has something I've
never seen
in another program: dynamic key
binding. To assign
a new keyboard shortcut to a command, open the menu as you normally
would, select
but don't activate the command, press the desired key, and voila! the
task is
done. No messing with config files, no wading through many layers of
cusomize
this dialogs, just direct action on the object you are modifying. If
config
files and layers of dialogs are your cup of tea, they're there too.
It's glorious.
The Gimp's dynamic key assignment is a perfect example you can
see-right-now
of the next element: collapsing interfaces.
It is time for the programming paradigm of code >
compile
> results to fade to the background. Wherever possible we
should be <span class="inlineHeading">able
to directly interact with our data</span>. The symbolic image is a
potter throwing
away cumbersome utensils and placing their hands directly on the
clay.
An example of how C>C>R gets in the way is
customizing
the desktop. Currently the standard approach to adjust your colour
scheme is
to open a simulation desktop which does not resemble yours at all,
select an
element to change, pick the new colour, slap the apply button, move
the fake
model desktop out of the way, then open a few windows and see if you
like the
change. Most of the time the alteration is not quite what you
envisioned and
the process must be repeated several times.
A better approach would be to enter configuration mode,
have a
colour and an editing tool pallette open up, directly click on the
characteristic
to be modifed, title bars for instance, and then select the new
colour from
the pallete and apply it to the real desktop. For machines with
sufficient hardware,
most of them these days, skip the apply stage altogether and have
realtime preview.
Getting back to keyboards for a moment, there is a
window manager
for linux (whose name escapes me at the moment) which allows the
keyboard
to direct the mouse cursor. Slap a key to go into m-cursor
control mode and
arrow your way to freedom. Moving too slow? Hold the shift key and
the cursor
will gallop along. I hate having to abandon the keyboard just to
click an icon
and then come back to the keys. That being said, it sucks just as
much having
to move back to the keyboard for one stroke when a click or two would
do.
On to context sensitive menus.
Sometimes I really
think computer evolution is devolution. If an alt key modifies the
menu choices,
that fact should be displayed.
To be sure, WordPerfect had something like this at least
3 years
earlier, and who knows how old the idea really is. My main question
here is,
why didn't this incredibly useful convention cross over into the
graphical user
interface? I miss it.
Terminate also had something else which was common in
the era and
has since fallen into disuse, a quick reference keystroke
screen
available at anytime and from anywhere.
And before I finally allow Terminate to rest... a cool
feature
I still miss everyday: assigning usernames and passwords to
shortcut
keys. Logging in to Slashdot or Dejanews? Ctrl-F1, Enter.
done. Sure
Internet Explorer and Mozilla have 'remember this login' but
you have
to have already filled out the form, on that server, before you can
use it.
Actually, since the topic is the Perfect Interface, username
and password
is a bad idea anyway **link to useit** and shouldn't be there. Not
that that
matters since we all use cypherpunks, cypherpunks anyway
right? Anyway
the same feature could be adapted to any frequently filled field.
By now you may have decided I'm a keyboard bigot.
I'm not
Dan Kaminzky's Analogous Key Arrays {Hmm,
for some
reason Dan appears to have password locked his sight, or, he hasn't
paid his
netpedia bill, or something. Anybody know a mirror?} Now this
feature I
haven't actually tried yet, but I've read the description and I love
the concept.
Basically you always use the same shortcut keys, the numeric keypad
for instance,
but what they do depends on what feature set is active or what mode
you are
in. And, you don't have to remember them all because the gui buttons
gives you
the context. If the toolbar is a 3x3 matrix, the center button will
always be
activated by typing 5, the center left by 4, etc. Use the -/+ keys
(or whatever)
to move the button group in focus up or down. Sorry I can't be more
decriptive,
it's been awhile since I read the document.
One of my all time favourite interfaces is sported
by the
various versions of AutoCAD going back at least to 1987 (when I first
encountered
it). AutoCAD, being a drafting program, is inherently graphical and
it's graphic
user interface was in use a long time before Microsoft jumped on the
bandwagon.
And yet, not only did AutoCAD have a command line, it was essential.
You could
get around without it, pointing and clicking at layered menus, but
not very
well. Now the shoe is on the other foot, the command line is there,
but unless
you have a strong keyboard predisposition you're not as likely to use
it.
Some other programs have adopted an integrated command
line, but
most of the ones I've seen have missed one of the <span
class="inlineHeading">most
important elements - the principle of being always hot</span>. Any
keypress,
excepting an Alt chord, is automatically sent to the command line. If
you have
to grab the mouse and click on the command area in order to type you
negate
most of the reason for having a command line in the first place.
Another important element of the AutoCAD command line is
that any
(well almost any) gui command is echoed there. This means it can be
used as
a learning device. Can't remember the name of that command? Find it's
toolbar
button, push it, and you're off doing whatever you want to do and you
can see
the text-mode command you could use next time as an alternate
route.
Now the realism part. Everybody's an expert, there are N
thousand
Perfect User Interface proposals **google link**, and nobody really
likes anybody
elses. Also there are thousand of legacy applications which are in
use everyday
but nobody is working on anymore. So here's my solution: The
Facade.
Graphical Skins are wonderfully popular, you can even buy them for
your cell
phone. I'd like to take the idea a little further, don't stop with
changing
the program's look and feel, carry right on into changing how it
works.
The Facade, as I envision it, is a
small lightweight program which
stores your personal preferences and customizations and applies them
to any
program you use (at your discretion of course). Found yourself having
to use
yet another graphics program which hasn't seen the light of one
stroke tool
changes? No problem, have Facade intercept your keyboard commands and
translate
them into what the program expects. Don't want to look at their
inefficient
and incomplete menu layout? Have Facade cover their toolbar with
yours.
It will take a lot of work to build the
translation table
for any particular progam and nobody will want to do it more than
once. This
means the translation tables would have to be sharable among users to
spread
the work around. The shared tables could be called, you guessed it,
faces.
And since you are going to all the trouble of fixing that dumb
program anyway,
you might as well cover that face with a skin, right?
And since
all the developers reading this will see the light and want the
perfect ui we
need an API so the face and skin can be tightly integrated and bonded
with the
program. Might as well call that the skull, eh?
Feedback on how to improve this essay is welcome, a
working facade,
more so. :)
Try this: ctrl-shift-numlock (you hear a quick beep-beep), now use the
keypad
keys. Tapping shift while scrolling makes it speed up, 5 is mouse1 etc.
Press
c-s-numlock again to deactivate.
Much of what you say is fairly good, but is also mostly covered by
current research and writing in Human Computer Interfaces and user
interface design. It also seems that you are not familiar with much of
the existing work on HCI and interface design. I would suggest that you
check out Bruce Tognazzini's web
page and browse through
the user interface books in your local large/technical bookstore.
Shortcut Keys
Yes, but I actually like those "tendon-stretching corded
combination" shortcuts. I think that the use of some meta-keys to
represent sweeping mode changes is well established (e.g. Shift-
manipulate for multiple select or contrained draw/move/modify) and
usefully extends the shortcut vocabulary for specific applications.
(which is to say that I don't think the system standard shortcuts
should use corded combinations. Applications should be free to define
the behavior of corded meta-key combinations)
Direct Dynamic Customization (DDC?)
I've never used the Gimp for any substantial work, but this feature
sounds both intriguing and infuriating. If I had to put up with this
feature I would like a way to turn it off completely, once I have
defined my shortcuts, if only to prevent the feature from tripping me
up in daily use. I would also like to see a good management interface
for the entire list of defined shortcuts, since there is a complex
issue of shortcut redefinition, which is not adequately handled in any
current UI with which I am familiar.
Collapsing Modes
This is called progressive disclosure amoung HCI folk and
user interface designers. I'm a bit confused by how you connect this
with coding and compilation, however. It seems that what you really
want is more immediate feedback than most customization tools currently
provide. Better feedback is also a well established trope in HCI/UI
design.
Context Sensitive Menus
The main complaint against context sensitive menus is that they are
completely invisible to beginning users, and are thus fairly
mysterious. Clearly, however, any battle that may have been fought
against contextual menus has been lost. The mysteriousness of
contextual menus is increased when entirely different menus appear
depending upon what your mouse pointer is positioned over when you
summon the menu. To a user who doesn't clearly understand the
application's metaphores, the reason for the different contextual menus
can be pretty unclear.
Context Sensitive Shortcuts
If contextual menus are confusing, contextual shortcuts are doubly
so. I'd want to be able to turn this feature off on any program I had
to use.
Hot Command Lines
I've never understood why people liked a CAD package whose primary
interface was the keyboard, but I'm an old Mac-guy. There were some
development tools from Apple that did similar things (Apple unix for
the Mac II and the old Macintosh Programmer's Workshop environment) and
I never thought they were all that usefull.
the Facade proposal
I really like parts of this idea. I would like to see a layer
between the user interface and the rest of the program logic that would
be editable by end users. This would basically be a scripting langauge
in which the entire UI would be written. The UI script would determine
how the UI's appearance and behavior, and would generate a consistent
set of messages that would be sent to the program logic back end. Users
could edit the UI scripts in any desired manner, and the back end logic
would be none the wiser that anything had changed. Some of this was
possible with programs written using NeXT's interface builder, but I
have never seen this in any other commercial offering.
Ultimately, what I really want in a UI is twofold:
First, I want a nice, consistant UI on programs I have never used
before. Most common tasks should be performed in the same way as other
programs with which I am already familiar (having standard open file,
save new file, page setup, and print dialogs, along with standardized
behaviors for menus, text edit boxes, etc. is a really good start) and
any really new types of tasks should try to model the ways of doing the
new task after ways of doing similar tasks in other programs (I should
not have to operate scroll bars via left and right mouse buttons in one
program but then have little arrows and page regions in another).
Second, I would like to be able to edit the user interface to my
tastes, once I am comfortable with the program and know how I use it on
a regular basis. I should be able to move menu items and change
shortcut keys to my heart's content. This also means that any UI
feature that I don't like I should be able to turn off.
A lot of what you mention seems to not really solve many problems: my
take on what you say is that we should have better keyboard shortcuts,
and users should be able to change the UI to suit them better. To some
extent, in the GNOME world, this can already happen. GTK is what has
the dynamic keyboard shortcuts, not just the Gimp. Also, programs that
do their UI with glade are already prepared for users to modify the UI
(which is represented in XML) if they really want to. But this doesn't
really change anything about HCI. You still have to be the one
directing all the operations on your computer. I'm more interested in
looking at applications of Information Agents - little daemons that can
take care of things for me, and just give me reports if something
important happens. The Anti-Mac Interface (which there was an advogato
article about several months ago) has a lot of interesting ideas that
break free of the normal WIMP UI. I am interested in seeing how we can
be more expressive in communicating with our computers. Giving
computers more information about the objects we manipulate should
hopefully let them do some of the drudgery that we have to put up with.
And, when we do actively try to perform some operation, the computer
will be better able to help us. (A simple example: if all music files
had more metadata, like including the mood, or date recorded, etc, we
could ask our music player to play all "relaxing music"). The trick is
to figure out ways to give the computer this extra information without
being an overly burdensome task for the user. One possibility is having
the computer pay attention to what files you use together, and build up
relation graphs. So at the very least, you could open a file, and ask
your computer for all similar files - it would then traverse the graph
for what files are most used with that file. I'm sure more clever
things could be done than this though.
The Facade?!, posted 2 Feb 2001 at 23:55 UTC by Malx »
(Journeyer)
We have it already!
You could use TCL/TK - it is pretty what you need.
If you thinks it is too old - use Mozilla (www.mozilla.org) application platform.
Here JavaScript and XML are languages for interface. You could see mozilla-browser skin examples. You could
edit them if you know JS+XML freely.
All real components made in C/C++ - so you need to add just core function (or just a plugin) and then
access it through JS/XML.
What I really wont to see in new interfaces:
- First of all - It must minimize key strokes and mouse moves to accomplish a task (especially for repetitive tasks).
I thinks for WIN UI it is a problem to get any automatization work :)
- Second - APP must use window space fully! If I make window smaller it must leave there only usefull info (and never
it must try to place there all thouse garbage of menues). Look at Icon-style applications for WindowMaker
- In addition to previous - one must think of using same space for different data - you could use color/size/shape
to represent different data on the same place of screen!!! at the same time. It is easie to change your focusing than
to change image with clicking or presing keys.
So unix shell (text) interfaces still the best. :-)
Also I like Key+Mouse bottons press/releases shortcuts of GIMP very much. And GTK+ dynamic SC.
I think that most of your proposals would actually make for a worse UI.
My key argument is that a way to a better UI is by simplifying things as
much as possible not by adding new features that make programs more
complicated to use. Emacs, Vi, Linux, command line, they are all great
for power users. They'll make you more efficient if you're willing to
spend considerable time learning how to use them properly. Most people,
however, don't have this time and just want to have their work done
with the least amount of hassle. As far as specifics go:
Shortcuts for all commands should only be an option for power
users, turned off by default. It's good for people who spend a lot of
time in one program, (say, Gimp) but if I use Gimp as a novice I don't
want strange things to happen just because I pressed a random key.
Context-sensitivity again the value it might bring by making
operation more efficient can be overtaken by the fact that it makes
thing unpredictible for novices (sth. changes and you don't really know
why).
The facade limitless configurability is also bad for most users.
Consistency has much more value. This has been witnessed in practice
(Windows/Mac have more appeal for most users that Linux because, among
others, it's more consistent) and there is common-sense thinking behind
it as well (would you like street signs to look different in different
cities? why should programs/UIs be different?)
Now before you cry out loud please note that I acknowledge that those
ideas are very good for power user so it's great if your program targets
power users. For everyone else (and there's much more non-power users
than power users) a good UI should first and foremost strive for
simplicity not feature-city (as Alan Copper said "no matter how great
your UI is it would be better if there was less of it").
I found "The inmates are running the asylum" by Alan Copper to have a
great discussion of the issues involved. His main point is that design
(including UI design) should be a user-centered process and not an
implementation of arbitrary ideas (that's why "perfect UI" can't exist;
what's perfect for a secretary is not perfect for a seasoned programmer;
different sets of requirements will lead to different trade-offs in
designing UI). Some of the ideas presented have a reason behind them
(e.g., shortcuts in Gimp is a time-saver for power-users) but some (e.g.
facade) will bring more problems than possible benefits.
2 kjk, posted 4 Feb 2001 at 00:13 UTC by Malx »
(Journeyer)
There is one thing you have not thinks of.
It is transition from novice to power user. It would be
impossible for novice to become power in your case of turning on/off
features.
kjk:
I think that most of your proposals would actually make for a worse UI.
My key argument is that a way to a
better UI is by simplifying things as much as possible not
by adding new features that make programs more
complicated to use. Emacs, Vi, Linux, command line, they are
all great for power users. They'll make you more
efficient if you're willing to spend considerable time
learning how to use them properly. Most people, however,
don't have this time and just want to have their work done
with the least amount of hassle.
I agree that this may be true for entry level users, but I think you
encounter a significant problem if you simplify things: expressiveness.
A simple interface means that the story that you can tell the computer
has to be relatively simply. A simple interface gives you a grammar like
this:
Make Dick run. Make Jane run.
A more complex interface (admittedly with a steeper learning curve)
would allow more detailed and expressive interactions:
Have Dick move quickly in a random but southerly direction. Have Jane
prevaricate about the bush. If Dick encounters Jane, have them have a
conversation using <filename> as the idea source.
A well designed interface would provide both and would optionally
(defaulting to on) teach the user the more complex grammar as they go.
The context-sensitive "tips" that some programs have are an effort to do
this, but they haven't quite made it all the way there.
Ideally a workstation environment would adapt to you, sort of like a
parent talking to a child. As skills increased, so would the available
vocabulary and the complexity of the grammar. How to do that? I don't
know, I'll leave that as an exercise for the reader and go do some
reading myself. There's probably a lot that can be learned from foreign
language instructors, as that's really what we are talking about here:
learning new languages.
Speaking of learning, posted 6 Feb 2001 at 06:46 UTC by kjk »
(Journeyer)
Speaking of learning (not only languages): have you read N. Stephenson's
"Diamand age"? I was really impressed by the idea he presented there
which, I think, boils down to what you describe: an ultimate teaching
environment that adapts to your level of knowledge and guides you to
higher levels in the most efficient way. Granted, we don't yet have
technology to build such device if it's at all possible (with the
biggest, rather philosophical than technological, problem being: who
should decide what you should learn/be taught?).
2kjk, posted 7 Feb 2001 at 23:57 UTC by Malx »
(Journeyer)
No. How to find it in network? (also how to get your e-mail? :)
Thank you everybody for your comments. I'll respond in more depth once I've had a chance to ponder them more thoroughly and for
now restrict myself to a couple of general and necessarily shallow notes.
dutky: With the exception of the facade, there isn't supposed to be anything new, rather a collection of
Best of Breed features. My ideal UI would be something which I could throw my whole body into not just a few finger and wrist
movements, large movements as well as subtle twitches should be possible. Something akin to that will probably develop sooner or
later,
but my essay is purposely restricted to things which could be accomplished right now, with technology already demonstrated and in
use
somehwhere in a more or less popular fashion. I like graphics apps which use the keyboard because I have two hands and want to use
both of them.
Malx: I'm unclear how Tcl/Tk or Mozilla could bring new interface functions to legacy, possibly closed source, apps.
Please elucidate.
kjk: Agreed, a method of dealing with the complexity of limitless customization and concommitant confusion is a
must.
To my way of thinking the facade would deal this using templates. Most users will just use the default template aligned towards their
history: Apple, Emacs, Windows, VI or modes, etc. and the user will have to explicitly flip a toggle somewhere to allow them to enter
into
customization mode.The default state, a previously saved session, or an "official" template downloaded from [program].com /
facade.themes.org could be activated at any time.
Basically think of Facade as cascading style sheets applied to applications and user interaction instead of web pages and looks.
-matt
closed source, posted 9 Feb 2001 at 00:34 UTC by Malx »
(Journeyer)
I thinks it would be same way, as you using now Libraries or COM components.
TCL/TK uses TCL only as a glue for binari modules
Same - Mozilla uses JavaScript to call external binary plugins, which
do the real job.
But! It is agains MS way of programming :)
There you make UI first and then put there functionality.........