Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Designing User Interfaces

By RadiantMatrix in Technology
Wed Mar 21, 2001 at 05:10:55 PM EST
Tags: Help! (Ask Kuro5hin) (all tags)
Help! (Ask Kuro5hin)

During the research stage of a recent software project, I was faced with laying out the design for the User Interface (UI), and I found that the most common interfaces seem either clumsy, complicated or difficult to learn (from the point of view of an average user). I read several texts detailing different approaches to design, and the discussion surrounding a previous K5 story on GUI's.

What I was unable to find was any information on how to design an approach to a UI.

It is difficult to pose the question I wish to ask without providing some background. In my experience with designing user interfaces, I have attempted three different approaches:
  • Command Line
    While simple and elegant, IMO, I have found that many non-technical users have difficulty learning the commands needed to perform even routine tasks. Constant reference to documentation slows the process and frustrates the user.

  • Traditional GUI
    By "traditional", I refer to the usual approach of using flat windows with buttons, text boxes, and the like. This is the most common GUI. While this approach seems to be very good, it breaks down when one must deal with processes that are lengthy or difficult to portray in two dimensions.

  • 3D GUI
    While I would like to work in true 3D space, I have been limited by the fact that most users use 2D display devices. :) This GUI uses 2D representations of 3D environments to navigate through. While excellent for spatially-related or very complicated processes, this approach is overkill for most applications.
I know there are other ways to design a UI, but I lack data on the tradeoffs each presents, and on the theory behind designing interfaces that are simple, powerful, and truly intuitive to a particular audience. Can anyone begin to explain the theory behind UI design, or point me to resources that may help me?


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


My favorite form of UI
o Text! 34%
o 2D GUI 30%
o 3D GUI 1%
o Voice 1%
o Telepathy 30%

Votes: 107
Results | Other Polls

Related Links
o previous K5 story
o Also by RadiantMatrix

Display: Sort:
Designing User Interfaces | 60 comments (52 topical, 8 editorial, 0 hidden)
2D Letters (3.75 / 4) (#1)
by Holloway on Wed Mar 21, 2001 at 05:00:50 AM EST

Um, almost all types of software use 2D letters (yeah, as opposed to 3D) so I don't think a new 3D interface pArAdIgM can change that. Most 3D interfaces just rotate the text so that it's always facing you. In real life you can read a page at a slight angle but then real life has a higher DPI. Flat-on text is pretty much necessary - and text is pretty much necessary for all interfaces. I think for most types of applications 2D is most suited.

I wrote something ZUIs which I really love the idea of: A 2 <sup>1/2</sup>D interface.

Oooh new screenshot from Berlin... it's a clock!

== Human's wear pants, if they don't wear pants they stand out in a crowd. But if a monkey didn't wear pants it would be anonymous

And now that I think about it... (5.00 / 1) (#2)
by Holloway on Wed Mar 21, 2001 at 05:35:49 AM EST

The conventional 2D interface you mention is usually called a WIMP (windows, icon, menu, pointer). And when is K5 finally going to allow the acronym and abbreviation tags?

Aside from the obvious useit.com I kinda like design articles on AskTog too.

== Human's wear pants, if they don't wear pants they stand out in a crowd. But if a monkey didn't wear pants it would be anonymous

[ Parent ]

OT: <abbr> and <acronym> (3.00 / 1) (#4)
by driph on Wed Mar 21, 2001 at 06:45:39 AM EST

And when is K5 finally going to allow the acronym and abbreviation tags?
Are the tags even supported by the browsers yet? I know they are HTML 4.0, but I have yet to see either of them used..

Vegas isn't a liberal stronghold. It's the place where the rich and powerful gamble away their company's pension fund and strangle call girls in their hotel rooms. - Psycho Dave
[ Parent ]
Google's pagerank made me do it. (4.00 / 1) (#5)
by Holloway on Wed Mar 21, 2001 at 07:17:24 AM EST

Opera 5 (and 4, I think) shows them as a tooltip and in the status bar. IE4 does (as a tooltip). Mozilla does. Not sure about others though. This page is chockablock full of acronym tags.

== Human's wear pants, if they don't wear pants they stand out in a crowd. But if a monkey didn't wear pants it would be anonymous

[ Parent ]
Some resources... (5.00 / 10) (#3)
by gavinb on Wed Mar 21, 2001 at 06:24:25 AM EST

You don't specify what sort of application you are trying to design. The best approach obviously depends on a number of factors, the problem domain and user profile being rather important. Some more detail would help us give more directed info... Anyway, I've designed a number of UIs on various projects, and I've listed here some of the resources I've found useful: Here is my "classic" list of books on design:
  • The Design of Everyday Things, Donald A. Norman, Doubleday, ISBN 0385267746
  • Envisioning Information, by Edward R. Tufte, Graphics Press; ISBN 0961392118
  • Tog on Interfaces, Bruce Tognazzini, Addison-Wesley, ISBN 0201608421.
  • Human-Computer Interaction, edited by Alan J. Dix, Prentice Hall, ISBN 0132398648
The first two aren't even specific to computers at all, but they are definitely worth reading for anyone doing UI design. Norman makes you think about user-centric design, not specific to computers but essential concepts of usability. In particular, 'affordances' which is something people seem to be designing away these days (especially in the too-trendy-for-you web pages).

Tufte is a masterpiece of graphic design and visualisation, and shows how to make potentially boring information a work of art.

The Tog and Dix books are both great books on interface design in general, the latter being a good textbook for an undergrad course.

If you are designing for the PC marketplace, I strongly suggest you get a hold of the CUA (Common User Access) Guidelines (originally published by IBM; sorry I don't have a reference). CUA covers stuff like what to stick under the File and Edit menus, where to stick Ok/Cancel/Help, layout of dialogs, etc. Windows (and OS/2 more so) is based on CUA, but deviates a lot these days.

You mention three paradigms; text mode, 2D and 3D. These days, only Unix junkies (count me in!) are still writing command-line or text-mode programs. Sounds like you are looking at a GUI. The design in the 2D world is well-explored, and there are plenty of conventions and design patterns to follow (and also plenty of examples of how NOT to design a UI). The 3D paradigm however is still very much in the experimental phase, so unless you are designing a game or visualisation software I suggest you stick to good old WIMP. (If you are still keen on 3D, have a look at the Berlin project, and Xerox's Rooms).

A final word; KISS - a good UI design is simple, clear and elegant. Most programmers make lousy UI designers; they try to cram in too much into the one screen, have no sense of style or balance for layout, and usually can't paint icons to save themselves. But I digress...

[ ::gavinb ][ "You can lead a moron to knowledge, but you can't make him think." ]

Also: Jef Raskin's Humane Interface (5.00 / 2) (#11)
by The Cunctator on Wed Mar 21, 2001 at 09:13:43 AM EST

Jef Raskin, one of the lead Mac developers (and the guy who named it), presents in The Humane Interface a pretty bold screed that has a well-opinionated analysis of user interface issues. I read it in one sitting. The man loved his Canon Cat. He attacks the scared cow of WIMP (Window/Icon/Menu/Pointer) quite well.

If you don't want to buy the book, just read Raskin's summary of The Humane Interface.

On a side note, poor Aza Raskin can't spell too well.

[ Parent ]

User groups specific UI's (5.00 / 1) (#12)
by iGrrrl on Wed Mar 21, 2001 at 09:19:51 AM EST

Mostly I want to strongly second gavinb's input on just about every point. Back when I had to think about such things we had monocolor screens, and all input was touch screen or text. For what we would now call low-tech, PLATO's original interface worked very well for a broad spectrum of non-programmer users. Which is the point

From the original article:

I know there are other ways to design a UI, but I lack data on the tradeoffs each presents, and on the theory behind designing interfaces that are simple, powerful, and truly intuitive to a particular audience.
The problem in UI's in general is that there some users work better with one interface, and others with another. If the project has a specific target audience, get to know that audience. What works for baby boomers might seem staid and boring to many younger people. What works for college students might seem confusing to to their grandmothers.

In a sense, though, there are two problems. There are the mechanics of the interface in terms of how it deals with the operating system, and the interface's look and feel. One comes from the programmer's art, the other from the designer's.

You cannot have a reasonable conversation with someone who regards other people as toys to be played with. localroger
remove apostrophe for email.
[ Parent ]

The classic mistake... (4.00 / 1) (#29)
by ucblockhead on Wed Mar 21, 2001 at 12:31:23 PM EST

The biggest differences are between people without much computer knowledge and more experienced users. Many of the interfaces we use today are designed for people who know very little about computers. Those interfaces are lousy for people who do know a lot about computers. Knowing your target is crucial.

But you have to be very careful. You want to look at your users, look how they do things, and look at what they are capable of. What you do not want to do is what I've seen happen all too often. That is, go ask the users what the interface should be. That can be disasterous as they are even less likely to be good at design than you are. Part of the designer's job is to lead the users into ways of doing things that are better.

This is k5. We're all tools - duxup
[ Parent ]

Donald Norman (2.50 / 2) (#17)
by ucblockhead on Wed Mar 21, 2001 at 10:39:24 AM EST

I had the pleasure of taking a class from him. Cool guy. His class was a bit of an epiphany for me. That book should be required reading for anyone thinking about designing anything.

This is k5. We're all tools - duxup
[ Parent ]

More IBM (5.00 / 1) (#19)
by sugarman on Wed Mar 21, 2001 at 11:04:59 AM EST

While I didn't find the CUA you mentioned, it may exist online. IBM's developerworks site is great, and you may try the Ease of Use website as well. The Desighttp://www-3.ibm.com/ibm/easy/eou_ext.nsf/publish/561n section is pretty complete.

That's all from the MLP front for now.

[ Parent ]

Fixed link (5.00 / 1) (#20)
by sugarman on Wed Mar 21, 2001 at 11:06:57 AM EST

That last one should be here

[ Parent ]
Learn by (bad) example (5.00 / 3) (#8)
by sugarman on Wed Mar 21, 2001 at 08:46:07 AM EST

For a run down of some things that should be high on the DON'T list, check out the Interface Hall of Shame. A plethora of tips and examples that *should* make you cringe.

As for decent examples, Apple provides one of the better ones with their HI Guide. Real tips that can apply to any platform.

From a personal standpoint though, my favorite UI would be "Menu + Hotkeys". Call it 2D, or a holdover from DOS, but this way you don't have to leave the keyboard, and the Menu is still there for when the brain skips on the exact command you're looking for. I know in Netscape, I've trimmed it so the icons are "Text only", which gives me a slightly larger bit of screen real-estate, at the expense of having no icons, which does slow down some 'guests' to the system. Oh well. YMMV.


keys (3.00 / 1) (#52)
by cpt kangarooski on Thu Mar 22, 2001 at 12:42:56 PM EST

although there is something very nice about being able to make an unconscious gesture to do things, which is basically how keycuts work, do know that they are slower than using drop down menus.

All my posts including this one are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
[ Parent ]
Premature specification? (3.00 / 1) (#10)
by jabber on Wed Mar 21, 2001 at 09:03:22 AM EST

I'm designing a machine. How many wheels should it have?

Unless you're designing an OS UI, you've got to give us more to go on. And even if it is for an OS, what's it's purpose? Is it to be a general purpose UI? Consider what's been done.. 3D is not really applicable for typical applications. 2D seems to rule the roost in the common apps since it supports typical metaphors pretty well. A letter translates to a 2D on-screen image nicely, as does a spreadsheet.

For systems management, you kind of have to have CLI, for it's raw power, but you can throw this into a window on a 2D GUI. For a 3D interface, you have to be dealing with an application in which the bulk of the metaphors is spacial. Off the top of my head, I can't think of any that CAD systems don't already cover pretty well.

3D, while very cool, is still looking for a context. Same as VR. Outside of a limited set of visualization uses, this sort of an interface is just overkill and misapplied.

Have you anything in mind about how the user would percieve the underlying system? If you have some 3D metaphors for a regular system, then a 3D UI might become the natural fit, but what doesn't work in how things are now?

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"

Clarification (none / 0) (#25)
by RadiantMatrix on Wed Mar 21, 2001 at 11:59:24 AM EST

I'm designing a machine. How many wheels should it have?

The question I pose is more along the lines of "I'm designing a vehicle - how do I go about determining the number of wheels I will need?" What I'm interested in is not the detail, but the approach.
I'm not going out with a "meh". I plan to live, dammit. [ZorbaTHut]

[ Parent ]

To further abuse the metaphor (3.00 / 1) (#38)
by jabber on Wed Mar 21, 2001 at 04:03:45 PM EST

You could be making a tandem tractor trailer (18), a dual axle pick-up (10 or 6), a car (4), an ATV (3), a motorcycle (2 or 3 if with side-car), or even a snowmobile (arguably 1). I really don't mean to be a bastard about it, but the purpose of the vehicle will pretty much dictate the number of wheels?

For office-productivity sort of work, a 2D interface has pretty well proven itself. 3D makes no sense for a programmer's workbench, except when used to arrange a set of editors and consoles in virtual space. For graphics, you have to consider the sort of application. As I mentioned, CAD has been successful at 3D extrapolation from 2D. For photo and graphic arts, you're again going 2D. For architectural systems, you want 3D capability, but the minds you will cater to will also want 2D of various perspectives. CAD again.

For virtual worlds, you definitelly want 3D. For novel visualizations of data, 3D may be applicable - and good ideas for 3D metaphors for the data involved? Some time ago, I was trying to conceive of a 3D approach to network visualization. I was looking at providing several 'perspectives', for example representing file servers as concentric spheres, with the outer translucent one being the storage space and the solid inner being the used fraction...

Most complex systems need some sort of console. I personally like 2D desktops with a 3D view and a console window, if an application needs to provide this sort of rendering. But the governing view will be dictated by the UI of the OS, and this is at best 2D unless you're looking to write your own.

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"
[ Parent ]

This metaphor is getting a -lot- of abuse (none / 0) (#40)
by RadiantMatrix on Wed Mar 21, 2001 at 06:29:52 PM EST

I really don't mean to be a bastard about it, but the purpose of the vehicle will pretty much dictate the number of wheels

Yes, but that is exactly my point. What criteria would I use to determine where the line between say, a single and dual axel pickup? That kind of information is what I seek. Your comments have been useful, but I'm interested more in the abstract: how do I define when to use what kind of UI, and how would I go about designing a new one?
I'm not going out with a "meh". I plan to live, dammit. [ZorbaTHut]

[ Parent ]

Problem domain specific (5.00 / 1) (#43)
by jabber on Wed Mar 21, 2001 at 08:04:16 PM EST

It's a tough call in that case. After all, even a 3D world can be represented as a string of bits, right?

It really depends on the kind of data in your peoblem domain, and as such ,it's very application specific.

Anything that filters or transforms data, or results in a very small and distinct result, is probably fodder for the CLI. A CLI can be easily wrapped in a 2D GUI by a variety of widgets, but it's still just a CLI front-end. Something like DOSSHELL comes to mind here, a 2D version of the file access commands for DOS overlaid onto a navigable tree of DIR commands.

2D stuff is anything where you need to see more than one line of data at a time. Typically this means text, but also applies to graphics. I think that the sense of 2D vs CLI is pretty natural, and determining the need for 3D is the real problem. We're in the habit of thinking in 2D, so a 3D extrapolation seems excessively ornate, much like a graph of performance may be 'too pretty' for someone used to poring over log files. Also, there are no consistent 3D metaphors just yet. Most everyday items can be represented as 2D icons with similar functionality, like folders or a trash bin.

For a successful 3D UI, you would have to have a need to show another dimension of information consistently. I thought a while about a good example, but decided against fabricating one since it would be completely contrived and subjective. Visual rendering, especially in 3D is very application specific. Add the ability to use color in 2D, various markup symbols... You really have to have multiple dimensions of data that necessarily need to be presented simultaneously, for a virtual world to work well with users.

Of course, if you want to model a real world, for example to walk around a molecule or geological data, or through a proposed construction of some sort, then nothing but 3D will do.

Another area that might lend itself to 3D rendition is DSP. You could show sound, for example, with time on the x axis, volume on the y and frequency on the z, but only if it suits the point you're trying to make in the UI.

Asking what the criteria are for an addition of a dimension to the UI, might be begging the question. The problem demands the tool, not the other way around. I think you're right in considering the issue, but I doubt that your question can be conclusively answered without that answer being arbitrary. If a problem needs to be solved, and a metaphor comes to mind that has 'x' dimensions, then that is a good solution. By even considering 3D you're looking further than many UI developers.

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"
[ Parent ]

3D Interface? (4.66 / 3) (#13)
by The Cunctator on Wed Mar 21, 2001 at 09:33:03 AM EST

3D interface? Who are you kidding?

If you actually think about it, nearly all tools we use are restricted to two degrees of freedom, from pencils to saws (yes, there are 3-D jigs, but for god's sake, let a computer run those) to screwdrivers. We see in 2-D projections, not in 3-D. 3-D is great for modeling complex data, but I've yet to see it as a useful interface. Especially since any 3-D interface is going to really be a 2-D interface, because we're stuck with 2-D monitors.

I'm willing to entertain the idea that we should move beyond the separation of "interface" (menus, buttons, sliders, textboxes, etc.) and "application" (think of Quake, for example) and recognize that when playing Quake, e.g. the entire game is an interface. But there dragons be.

Please, just follow the cardinal rule of useful interface design: usability. Make usability the cardinal goal, and make usability testing an integral part of the design process. It doesn't have to take that much time or effort, but you need to plan on having it be part of the process, or you just won't do it.

Agreement (none / 0) (#24)
by RadiantMatrix on Wed Mar 21, 2001 at 11:57:21 AM EST

Reading the story carefully, you will find that I agree that (a)3D interfaces are really 2D representations and that (b)3D is usually overly complex. However, I helped design a software package that managed the design of light programs for theatre/music productions. Having a 3D GUI was most helpful in locating lights to debug.
I'm not going out with a "meh". I plan to live, dammit. [ZorbaTHut]

[ Parent ]
Why 2D (1.00 / 1) (#54)
by kubalaa on Thu Mar 22, 2001 at 09:50:00 PM EST

We like 2D interfaces because we're land creatures. But I bet dolphins would dig a 3D interface.

[ Parent ]
Ahem (3.00 / 1) (#60)
by kubalaa on Fri Mar 23, 2001 at 11:16:51 PM EST

I wasn't kidding. It's easy to think that humans would find a 3D interface natural, being 3D ourselves. But, especially for nawigational interfaces, six million years of navigating over the relatiwely 2D surface of the Earth mean we think in 2D. That's why planar Euclidean geometry came first, and why I live at 3400 North 6th instead of 24 az 56 el 45th. 3D is almost never appropriate for human interfaces, and an inexperienced designer shouldn't consider it an option.

[ Parent ]
2D GUI!=WIMP (3.50 / 2) (#15)
by evvk on Wed Mar 21, 2001 at 10:24:05 AM EST

A two dimensional graphical user interface does not have to be WIMP (that I hate.) It can, for example, be fully keyboard-driven: traditional text user interface with graphics but not widgets. For alternatives to WIMP, take a look at, for example, Ion, XMLTerm or some older DOS programs, e.g. trackers.

PINE, too (3.00 / 1) (#30)
by Luke Francl on Wed Mar 21, 2001 at 01:28:12 PM EST

I think PINE (the email program) is a good example of a text-based program with an excellent UI. Once you find out that ^ means "control", you're all set.

[ Parent ]
Start with the User (5.00 / 7) (#16)
by Speare on Wed Mar 21, 2001 at 10:35:04 AM EST

There are books and books about designing user interfaces from the various widgets and controls and functions on given operating systems.

Before you get there, though, before you even think about the LAYOUT of the widgets, you need to step back and think on a meta-level.

Step 1: Identify your archetypal users.
Give them names if it helps, and write up a short blurb about each archetype. Susie the secretary, Tom the technician, Mary the middle-manager, who do you see using this product or feature? Important: Get peer feedback on your choices.

Step 2: For each archetype, list their tasks and goals.
What tasks require them to use the feature? What goals do they have? What do they want to get done? Susie only needs to look up individual entries. Tom needs to reverse-lookup people from their phone numbers or other technical data. Mary needs to edit lots of entries, usually from a separate list. Important: Interview people who embody your archetypes for your choices.

Step 3: Decide workflow needs for each task.
Susie is probably using the phone when she needs to do her lookups; keep it simple and minimize typing. Tom needs different fields available that would confuse or slow Susie down; consider using profiles for favorite query types. Mary uses a spreadsheet application to import data; how will she specify the file she needs? Important: Get user feedback on your choices.

Step 4: Make mockups and test them.
For each workflow, rough out a quick layout of the big windows you need. Don't worry too much about toolbars or where the OK buttons are. Definitely don't get distracted with skinning or drawing pretty icons. You and your peers should roleplay as your archetypal users, finding holes in your workflow, discovering the questions your software needs to ask your users, and discovering which questions can be avoided by making the software smarter.

Step 5: Finally, start getting specific.
Write out the specification and basic structure for your code, and then get coding.

As a cautionary piece of advice, quoted from Alan Cooper's "About Face" book on interface design: Don't Make the User Feel Stupid. Your application's interface should be arranged arround the way the USER thinks, not the way the DATA is built. Minimize the interruptions to the workflow, avoid modal dialog boxes where possible, think about the wording of questions your software has to ask the user.

It may seem like a lot of distraction before you get to the fun part of writing the code. The difference between an "engineer" and a "programmer" lies in how much thinking you put into the design of the code.

[ e d @ h a l l e y . c c ]
Most Helpful! (none / 0) (#23)
by RadiantMatrix on Wed Mar 21, 2001 at 11:54:37 AM EST

Thank you... Information like this is precicely what I'm looking for.
I'm not going out with a "meh". I plan to live, dammit. [ZorbaTHut]

[ Parent ]
I'd just like to add: (4.50 / 2) (#31)
by cbatt on Wed Mar 21, 2001 at 01:29:38 PM EST

Testing, testing, testing.

This can't be said enough. Once you've decided whom your target audience is, make sure that a testing plan is in place. Performace metrics and feedback are very important.

Gather people who are representative of your audience. Have them run through mockups, then functional prototypes, then your beta software. Keep them involved in the whole process, always pay attention to their feedback.

Do not fall into the trap of "role playing" your audience. You will miss something. There is no "maybe" about it. (unless, of course, the scope of the application is relatively tiny and/or not mission-critical)

One of the most important things about UI design is humility. Your gut instincts might be good, but never solely rely on them. Your audience will always have a difference in perception, and they're ultimately the ones that need to be pleased.

Two good resources not mentioned in this disccusion, so far, are:
HCI Bibliography : Human-Computer Interaction Resources
ACM SIGCHI (Special Interest Group on Computer-Human Interaction)

Before you can understand recursion
you must understand recursion.

[ Parent ]

data architecture (4.00 / 1) (#53)
by kubalaa on Thu Mar 22, 2001 at 09:47:59 PM EST

"Your application's interface should be arranged arround the way the USER thinks, not the way the DATA is built."

It's worth noting that if there's really a difference in these two, your software architecture will probably not be amenable to the kinds of changes you can expect from the client. Not to mention it will make it difficult for power users to learn what's really going on.

Software and UI engineering are both forms of mindreading; one you read the client's mind, one the user's. But if your client is of a different mind than the user, then their business is bound to fail.

[ Parent ]

Will take a lot of reading. (3.00 / 1) (#21)
by RangerBob on Wed Mar 21, 2001 at 11:26:25 AM EST

There's a lot of stuff out there on UI issues, and it's been discussed here many many times before. I've even got a book from the late 80's/early 90's that still one of the better interface books that I've seen. A lot of what I've found on the web isn't that great, because it's usually more posturing than indepth examinations.

Places like this aren't a great place to ask. People here are generally more advanced computer users, so things might make sense to us that wouldn't make sense to someone's grandmother. Also, people on sites like this are more than a bit biased when it comes to UI issues :) I'd continue to check around through lit searches and the like and spend a LOT of time reading, because it's a really big and involved topic that can't be solved on here.

Read These Books (4.00 / 1) (#22)
by greyrat on Wed Mar 21, 2001 at 11:54:36 AM EST

About Face and The Inmates are Running the Asylum, both by Alan Cooper.

I don't like the guy, I don't believe everything he espouses, and I don't like his writing style. However, these are two excellent resources to get you thinking about UI design.

Question Authority! Yeah, says who?

~ ~ ~
Did I actually read the article? No. No I didn't.
"Watch out for me nobbystyles, Gromit!"

Gesture Recognition (4.00 / 1) (#26)
by Giant Space Hamster on Wed Mar 21, 2001 at 11:59:35 AM EST

An interesting approach is the Gesture Recognition approach. Basically, the user moves his mouse or pointing device in a specific pattern to trigger commands.

One company that has a product that accomplishes this is Sensiva. I downloaded their product today and am trying it out. It is pretty interesting, and even somewhat useful. It's available for Windows, Mac, and Linux.

The game Black & White is attempting a similar system. Their goal is to have an icon-less game. I don't know how effective this will be, but early reviews/previews seem to look favourable upon it. Black & White will be released in early April.

The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
-- Bertrand Russell

Sensiva -> Yikes! (4.00 / 1) (#28)
by sugarman on Wed Mar 21, 2001 at 12:26:58 PM EST

I'm thinking that this gesture recognition thing would be best tailored to the application, and not something specific like general computer use.

I like Black & White's use of the gesture recognition for casting spells in a game. This coupled with something like Daggerfall's mouse-controlled sword swings can reall be a boon in creating an immersive experience in a virtual world.

But in general computer use...
I'm not sure about anyone else, but I tend to "doodle" with my mouse when I surf. I'll also highlight text, and make other basic movements. How does the mouse recognition differentiate between moving to the top of the screen to use a toolbar, and wanting to copy something to the clipboard? The movements need to be generic to be of use, but not conflict with common desktop moves that a user makes in regular usage.

Neat idea though.

[ Parent ]

Well.. (3.00 / 1) (#34)
by Giant Space Hamster on Wed Mar 21, 2001 at 02:03:06 PM EST

You have to hold down the right mouse button while you make the command. It's really good for forward and back in the web browser, as well as minimizing, quitting, copy and paste.

Plus you can easily define your own symbols for the general computer use or within a specific program. For example, if you gesture a "y", IE will automatically go to Yahoo.

I think its pretty neat.

I have no idea how it would work with a one button mouse (for those Macs out there).

The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
-- Bertrand Russell
[ Parent ]

Touchpad (2.00 / 1) (#36)
by evvk on Wed Mar 21, 2001 at 03:49:01 PM EST

I wouldn't like this with the mouse (I hate using the mouse anyway) but with something like a touchpad (properly positioned) or perhaps even a stick, this could be a great addition to the keyboard.

Hmmm... if the whole "keyboard" was a touchpad and it could recognize when I'm typing and when making other gestures... But I guess it wouldn't have the touch.

[ Parent ]
Yeah... (2.00 / 1) (#37)
by Giant Space Hamster on Wed Mar 21, 2001 at 03:54:21 PM EST

It works with a stylus or touchpad.

I used a mouse. It's surprising easy to get used to.

The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
-- Bertrand Russell
[ Parent ]

Don't forget about patents (3.00 / 1) (#33)
by Signal 11 on Wed Mar 21, 2001 at 01:54:23 PM EST

Don't forget, anything resembling an intelligent approach has already been patented using some incredibly vague wording somewhere. And if not, rest assured, your work will be plagarized and stolen in the name of profits.. and who the hell are you to stop P R O G R E S S ?

That aside, 3D UIs have already been looked at, specifically wrt filesystem navigation with mixed results. Sun Microsystems has a 3D file navigator lurking on their site somewhere, but I disrecall the link.

That aside, UI is great, but would it be too much to ask for just a UI that doesn't crash, lockup, explode, implode, or generally misbehave? I'll settle for anything which is consistent and relatively simple to use (for me, not joe average). You do that, and you've got my money...

Society needs therapy. It's having
trouble accepting itself.

fsn? (3.00 / 1) (#44)
by fluffy grue on Wed Mar 21, 2001 at 08:42:42 PM EST

You're probably thinking of fsn, SGI's (not Sun's) clunky 3D file browser. A much better one is <a "href=http://tanaka-www.cs.titech.ac.jp/~euske/prog/index-e.html">xcruise.
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Meh (4.00 / 1) (#45)
by fluffy grue on Wed Mar 21, 2001 at 08:49:14 PM EST

One link's broken, the other's malformed HTML. Damnit, I'm really on a roll tonight.

xcruise works. I have no idea where SGI's stashed fsn now. (I just love how they're always reorganizing their site, and ever since they dropped out of the graphics business they've let all that stuff just fester. Meh.)
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

If you can't find fsn... (4.00 / 1) (#55)
by SIGFPE on Thu Mar 22, 2001 at 11:08:45 PM EST

...just watch Jurassic Park. You can't miss it.
[ Parent ]
Suggestions for GUI design (4.00 / 1) (#39)
by jd on Wed Mar 21, 2001 at 04:50:54 PM EST

  • Keep It Simple. Simple designs work.
  • Users != Computers.
  • Verify & Validate Everything!
  • Programs should cater to the user, not vice versa. (Reformatting fields isn't -that- hard.)
  • Consistancy is better than Conformity. (Exiting is not a file operation.)
  • Users spend 99% of the time thinking, but expect results fast for that last 1%. Use the time productively, so that that happens.
  • Different hardware and/or different software means different output. Does the computer -really- care about the presentation? If not, then DON'T present in a way you know won't work.

GUI Design (4.00 / 1) (#48)
by FeersumAsura on Thu Mar 22, 2001 at 03:44:14 AM EST

Keep It Simple. Simple designs work.
Yes but sometimes a simple design makes complex tasks hard. This is where commandline is so powerfull.
Users != Computers
But also while many users are morons many users aren't. Remember the stupid people menu bars in Office 2000? Most people had to turn them off because commonly used functions were classed as too hard for most people.
Verify & Validate Everything!
You do this anyway no matter what the interface is.
Consistancy is better than Conformity. (Exiting is not a file operation.)
Well I've got so used to E&xit being under file I want to see it there. What do we have, a seperate menu titled Program? We could have Exit, Crash, Bomb under it.

I'm so pre-emptive I'd nuke America to save time.
[ Parent ]
'Program' menu (4.00 / 1) (#51)
by Nurgled on Thu Mar 22, 2001 at 11:32:40 AM EST

The current incarnations of desktop Windows at least already have a concept of a "Program" menu, although it's more accurately a "window" menu. It's what you get when you click that little icon at the top left of a window. It allows you to perform window-related operations, which include closing. If you close a document window within an MDI appication, you are closing that document. If you close an application window you are closing that application...

[ Parent ]
IBM developerWorks article (4.66 / 3) (#41)
by driph on Wed Mar 21, 2001 at 06:54:06 PM EST

Another IBM link, from their developerWorks site.

Debunking the myths of UI design

Paul Smith outlines and overthrows many of the common myths of UI design within software development. Very worthwhile read.

Vegas isn't a liberal stronghold. It's the place where the rich and powerful gamble away their company's pension fund and strangle call girls in their hotel rooms. - Psycho Dave

A fourth way (4.80 / 5) (#42)
by Irrumator on Wed Mar 21, 2001 at 07:31:30 PM EST

I don't know what your goals are, but there's a fourth approach, used by emacs and Niklaus Wirth's Oberon project, that I think is both simple and useful. It lies somewhere between the "Command Line" and "Traditional GUI" approaches, that is to activate arbitrary textual commands ("^X^E" in emacs and middle-clicking in Oberon). It gives you:
  • the power of textual commands
  • the convenience of WIMP
  • the flexibility of writing your own "menus" in a simple text file
  • freedom from resource intensive, fancy graphics (though there's room for that too if your editor is willing to support images as embedded text objects)

More References (3.50 / 4) (#46)
by Mabb on Wed Mar 21, 2001 at 10:07:36 PM EST

I second everyone's suggestion of Don Norman's book. It's the One To Read First.

I know Jakob Nielsen is often thought of as a pompous, opinionated fanatic, but he's got good reason to be so. He's a guru. Go to his web site (useit.com) for lots of stuff about designing web UIs. Good stuff. Also, look for his book "Usability Engineering" - there will be a link on his site (of course!). This book explains the theory, and what he calls the "Usability Engineering Lifecycle" which is a damned good approach to general UI design.

IMHO, UI design is ALL about usability. For a great reference to usability stuff available on the web, go to Usable Web (usableweb.com) where links are categorised (very helpful to drill down into a specialised area). It's the most comprehensive directory of links to information about information architecture, human factors, user interface issues, and usable design.

The most important thing to remember is to consider the goals of the system FIRST, and the technology that will be used to achieve those goals LAST. The best approach to interface design is to consign all technology-specific issues to the bottom of the pile until you know exactly what those goals are.

Lots of people have provided very good detailed advice on this and I can't emphasise enough: talk to the users, test with the users, fix the users' problems and re-test with the users again.

JN has some great information on prioritising usability activities and "doing as much as you can afford". He also discusses usability trade-offs, which are a fact of life in the real world. You'll find references to his "Discount Usability Engineering" all over the net.

Apologies for the lack of links/HTML.... I'm in a hurry and I can never get href syntax right without my trusty HTML editor :-)

QuiltBlog: WIP, SEX, WOW, MQ, LQS, HST...

jakob nielsen (4.00 / 1) (#49)
by agentk on Thu Mar 22, 2001 at 09:42:56 AM EST

A hillarious spoof on Jakob Nielsen: http://www.faxwerk.org/usabilitysucks/magritte.html

[ Parent ]
more jakob funnies (2.00 / 1) (#50)
by Mabb on Thu Mar 22, 2001 at 10:44:19 AM EST

.. he's a good target :-)


QuiltBlog: WIP, SEX, WOW, MQ, LQS, HST...

[ Parent ]
The situation often dictates (4.66 / 3) (#47)
by Eccles on Thu Mar 22, 2001 at 12:00:47 AM EST

The situation often dictates the interface.

I haven't bought a car MP3 player yet. Why? I want voice input. There's too many files to work with otherwise, and fiddling with controls even on a traditional radio/tape player contributes to unsafe driving.

(I also want it to be able to play different music for the front and back seat (with headphones for the back), but that's another story.

Warning: Offtopic (3.00 / 1) (#56)
by extrasolar on Fri Mar 23, 2001 at 02:05:42 AM EST

Sorry about this being off topic. But I have to say that this is *the* most mature and enlightening discussion I have ever seen concerning user interface design. This page is definitely being bookmarked and going into my hotlist.

Thanks a lot to all of you intelligent people!

Jef Raskin (4.50 / 2) (#57)
by drivers on Fri Mar 23, 2001 at 03:47:46 AM EST

I apologize in advance for my bad writing tonight. :-)

I recommend checking out Jef Raskin's "The Humane Interface". It's a fascinating discussion about how we can use what we know about human psychology to make a better user interface. It goes against a lot of common "knowledge" about user interfaces. He is in favor of a more scientific approach to figure out what really is a better interface.

He also shows why the current attempts at making supposedly easy to use interfaces are taking the wrong approach. After reading it, I was all fired up to implement some of his ideas. I emailed him my thoughts and his basic answer was that I would need a spec first and he was working on it. I get the impression that he believes only people like him could truly design a usable user interface and programmers like myself should leave it to the experts like him. After paying him a lot of money I'm sure. :-)

Well, anyway, it is still a really awesome book. Some of the main points are getting rid of "modes" which means different user "gestures" (a set of keyboard inputs or other inputs) mean different things at different times. Meaning the user must remember and think about what mode he is in and therefore what his gesture will mean in different contexts, which leads to errors. This is bad.

This is also why I make so many mistakes in vi and why CAPS LOCK sucks (especially in VI, heh). It's why the new windows feature that rearranges the menus on you suck. The commands should ALWAYS be the same gesture. If you have to search through the menu every time and can't just memorize it based on a kind of physical location (e.g. third item on the second menu) then the user can't become more effecient as he learns the interface.

Another items is the sacred cow of icons. How stupid is it that you have an icon (which is usually quite cryptic) and to figure out what it does, the operating system vendors have invented tool tips which tell you what it does in words. Why not have the words instead of icons? With words, it is actually faster to identify the command you want than with icons. It is also virtually impossible to pick icons that will mean the same thing to all people in all cultures of the world so you should just translate the words if you want to internationalize the software. (Remember when there was a big move in cars, signs, etc. to make everything icons that made no sense?)

He starts explaining a possible new type of interface that sounds very powerful. It is a kind of combination CLI/GUI. For instance, you can execute commands by typing them in. Your current command would be the current selection (selected/highlighted text) then you could hit an execute button (or something) and it would execute. However, since it is too hard for the beginner to know the commands, you could have menus with the commands, organized in a logical manner. However, the user can make their own menus just by typing them in as text, then executing a "create menu" command and then that bit of text would act as a menu. I hope that makes sense.

He also described a possible interface that involves zooming in and out and around documents (and the web, etc.) in a 2D zoomable world, in order to take advantage of people's spatial memory. When you are zoomed out you still are able to recognize constellations of data, etc. There would be no need for filenames (another sacred cow he butchers).

Why not 2D + CLI (5.00 / 1) (#58)
by razor69 on Fri Mar 23, 2001 at 06:10:22 AM EST

I don't understand, Why not just have something that looks and feels like windows (that works) or X (with desktop icons) but the background is like a terminal - you start typing and you start typing! Every function is shortcuttable for the keyboard, so the system works well for both advanced as beginner users: if you take the trouble to learn stuff things will go much faster. If you don't want to, you can still use the slow old mouse. Take the best of both worlds, don't call them mutually exclusive!

A Thought (or two) ... (4.00 / 1) (#59)
by Langley on Fri Mar 23, 2001 at 11:53:27 AM EST

Although trying to make an interface based off simmilar designs is a good for shorteing the learning curve related to your application, I feel it should not be your main focus.

Consistency, predicatbility, and minimal action needed to invoke commands are what I feel make up a good UI.

If I see some text on the screen I wan't to be able to select it, spell-check it, copy it, etc...

I do not care if that text appears via a character generator, a 2D UI kit, as 3D rotating text, whatever. It is text, it should behave like text.

Anyway I'm rambling. The key is UI's are clumsy and difficult, not because of the way they appear, but because of the way the react. If things react the sameway no matter the context, your interface becomes a bit more modeless, and your users become a bit more happy (and then people start to copy your trend, and the world becomes a better place, or we like to think :)

A Prohibition law strikes a blow at the very principles upon which our government was founded. -Abraham Lincoln (Sixteenth President of the United States of America)

Designing User Interfaces | 60 comments (52 topical, 8 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!