Improving Software Usability?

kevin_conaway asks: "Software usability is one of the hardest things to get right. Writing good, usable software is the holy grail of software development, yet few developers give it more than an afterthought. As a professional developer, I delight in writing software for other developers but shy away from writing an interface that the end users will see. What resources/books are recommended for improving your Human Computer Interaction (HCI) / software usability skills?"

Comments

here are a couple:

[yagu]

Don't Make Me Think and The Design of Everyday Things... two of my very favorite books.

"Think" is more web centric, but has many tips and insights, and is an accessible read cover to cover.

"Design" is a bit more pompous, and I don't agree with all points, but I give it high marks for making you take a different look at things you'd always taken for granted (Microsoft asked me a question at my interview from this book, btw).

A few more thoughts: don't confuse usability with user responsibility. If a task if tediously complex, it's going to be difficult to design a thin elegant easy-to-use interface. For example, photoshop can be amazingly obtuse to use, but there's a reason. Overall I give photoshop a "5" (out of ten) for their ergonomics, but I give them a "10" for what their application can do. I consider it partially my responsibility to climb that learning curve to do real work in digital graphics.

On the other hand, the unusable applications out there are infinite. My favorite example is Windows Media Player. I still have to figure out what to do just to play a CD with WMP. (And what's with the disappearing window?)

(Here's an interesting non-software example of horrible design: my parents have an RCA TV, not that old, but not HD. It has Videos 1, 2, 3 input, Cable/Air input, and VCR. There's a "SETUP" button on the front panel that lets you change the signal input from Cable/Air to VCR (or something like that), but the only way you can get Video 1, 2, or 3 is by tuning the TV channel to 91, 92, or 93 respectively. Until I found the manual and got to page 60 I was convinced the TV was broken.)

My favorite example of transcendental usability: Google.

(Some runners up: Picasa; Amazon.com (one-click), wish list, etc.)

(Also, I am opposite as to who I like to write for: I cringe when writing for other professional software developers, they're some of the biggest whiners about "what should be". I do however delight in writing software for clients. If you do it right, it's a genuine high.)

Re:here are a couple:

[vanyel]

I consider it partially my responsibility to climb that learning curve to do real work in digital graphics.

For the stuff that is technically advanced, I agree, though it should still be intuitive for someone who is technically advanced in the field.

Photoshop and Illustrator are classic examples of what I consider bad user interfaces, because things that should be simple and obvious, aren't. For example, cropping a picture (Elements actually fixed this one): you drag the border as you'd expect, then you want to fine tune it. Bzzzt. You had to use some combination of shift-alt-click-something to adjust it, or do the add/subtract from selection thing.

On the other hand, Elements has broken something simple and basic: resizing images. Something even earlier versions of Photoshop did well. No more: "resize/image size" just changes some parameter it saves that says how big to print it, and the only options you get are printer units. OK, fine, leave "resizing" to the printer people, there's a canvas size option, but no, that is effectively a crop if you shrink it and adds blank space if you expand it. How about the scale menu item, that should work. Nope: "transformations should be applied to layers. do you want to make the background a layer?" Despite the word "should", your only options are to cancel the entire operation or to let it make a layer out of it. And I don't want to resize one layer, I want to resize the entire thing!

Sorry, but crappy non-intuitive user interfaces are a hot button, and I just recently tripped over this one. In my mind, the entire point of a GUI is that you shouldn't have to RTFM to do the basic functions of the application.

Just because a tool is powerful doesn't mean it has to be non-intuitive...

Re:here are a couple:

[yagu]

You said, "Photoshop and Illustrator are classic examples of what I consider bad user interfaces, because things that should be simple and obvious, aren't". I agree.

I did, by the way, say, "Overall I give photoshop a "5" (out of ten) for their ergonomics...". Yes, I still consider a steep digital graphics curve my responsibility to climb, but I'm not letting Photoshop skate completely. ;-)

Re:here are a couple:

[bishiraver]

"Overall I give photoshop a "5" (out of ten) for their ergonomics, but I give them a "10" for what their application can do. I consider it partially my responsibility to climb that learning curve to do real work in digital graphics." This reminded me of my trials and tribulations with 3D graphics applications. Maya allows you to do some amazing stuff. Arguable, it's much more obtuse than Photoshop. 3D Studio Max allows you to do just as amazing stuff - but it's more obtuse than Maya. Silo3D, on the other hand, doesn't allow you to do as much - right now it's a simple modeler, though they're adding advanced UV mapping (arguabley one of the most difficult tasks in both of the above) and displacement painting in the next version. However, it has a very clean interface, and one of the fastest workflows of any modeller I've tried (from blender, to Maya, to 3Dstudio, to softimage). The keyboard shortcuts are intuitive and accessable. The interface is intuitive and accessable. It took me about a week of practicing Silo to get fast in modeling with it. I've been working with maya for about a year now, and it still confuses me sometimes. It's hard to explain what it is exactly about the interface that makes it so easy to use. It feels more like an art program than an engineering program - using it just feels natural. (note, although I'm not affiliated with Nevercenter in any way, I am a happy customer of their $109 tool; because there are many who haven't heard of the tool, I'm including this link [nevercenter.com]. If you model with polygons, it really is a must-try, and has a full-featured 30 day trial.)

Re:here are a couple:

[julesh]

My favorite example is Windows Media Player. I still have to figure out what to do just to play a CD with WMP. (And what's with the disappearing window?)

Err... insert CD, wait for the dialog box to appear, click on "Play this CD in Windows Media Player", click OK. Doesn't seem hard to me.

The disappearing window bugs the hell out of me, though. As does all the crap it does. I started a media player... why would I want it to load a web browser in it?

It's so annoying that I usually use media player classic for everything other than playing DRM'd files.

Re:here are a couple:

[BenjyD]

IIRC, you have to click "Resample" in the Image resize dialog to actually resize the image in pixels. Not exactly intuitive, but it is there. I think PSE4 gets a lot right in the UI in general, but it has some rough edges.

Re:here are a couple:

[bpd1069]

If you think Photoshop has poor ergonomics, then I don't think you know how to use it.

Having a steep learning curve is one thing, but usability once the fundemental skills are known is another.

Photoshop as it is now, works in the same way as Keyboard/Mouse FPS do. The secert is in the keyboard shortcuts, and with that the ability to program keys/functions.

Also when using photoshop on a regular basis, the use of actions (then mapped to a shortcut) makes it even more powerful and extremely fast.

If you are using the menus/fly outs to accomplish most of your tasks in PS then your learning is incomplete.

Re:here are a couple:

[Anonymous Coward]

Then you must not be real advanced in the field. Anyone who seriously does work in graphics knows Photoshop quite well. I do not know how anyone "advanced in the field" could not know how to use PS, heck I am not advanced in the field and I can figure it out.

Really, I just think some people are downright dense when it comes to software.

Re:here are a couple:

[Darth_Burrito]

Me too with respect to those books. I read them in graduate studies and found them both helpful. They are both very easy reads. In addition, anyone technical doing web design would benefit from a basic study of print design topics... how to align things, set up good contrast, using proper fonts and all that.

Re:here are a couple:

[vanyel]

So it is, thanks! When you click on "resample" (at the very bottom of the dialog, then the pixel values become editable. The workaround I had found had been to scale it in "Save for web"...

Re:here are a couple:

[SPF22]

The point is, with Photoshop, it would be practically impossible to create a thin, easy to use UI because of all the functionality.

The reason it is so difficult to change the size of a file in Photoshop, is because of all the final output options you have for different mediums, and the power that level of control gives you. If you were to just click on a resize button, what would you want to resize? One of many layers? The pixel aspect ratio? the image dimensions? The canvas? The overall image size?

Do you want to create for web (72ppi square pixel, RGB), or create a screen for display on Standard def TV (720 x 480, 72ppi, DV/D1 NTSC 0.9, RGB) or High Def (1080 x 1900 72ppi, DV/D1 NTSC Widescreen 1.2, RGB)? Do you want to size for print (300dpi, 133 dpi, 72dpi, square pixel, CMYK).

How do you intuitively ask the user if they want to scale their styles, or leave them as is on resizing, but size the rest of the layer? What about scaling an image proportionately when using square pixels at 720 x 480 when the final output is going to a 640 x 480 screen? How do you think the image should scale the pixels if up sizzed? Bicubic / Nearest Neighbor?

IMHO, the need for the multiple resizing methods is necessary, and it would greatly effect the creation speed, and output if all those methods were not there. They did a good job identifying the categorization, and once you use the resize tools, you'll see that they are all in the same location, except for free transform which effects a layer, and crop.

My point is, this is an expert level application with a TON of functionality, and if you are having problems with resizing, cropping, or whatever, then you *SHOULD* pick up a manual. You might learn something that you didn't know before. Photoshop is an expert level app and what might be intuitive to you, might not be to the next person.

It's easy to say it should be more intuitive; so should 4 way stops, and I see people messing those up all the time.

Re:here are a couple:

[vanyel]

The reason it is so difficult to change the size of a file in Photoshop

I don't remember it being that way before, but maybe I'd already found the resample button and somewhere a way to tell it to do that always.

Yes, there are a bazillion odd cases that Photoshop has to deal with, and yes, for some given person, any one of those cases may be the "norm". Nevertheless, it would be very intuitive to *not* grey out the pixel fields, but have an Options button there that lets you select which of those weird cases you want, and have a checkbox for "Make this the default". The manual and Help buttons should then explain why and when you would want to select each of the options and why and when you would want to avoid selecting each of the options (if there are some gotchas that could trip people up). And in really complex areas, perhaps even link to or recommend reference sites and/or material.

My point is, this is an expert level application with a TON of functionality

Photoshop Elements, as I understand it, is the stripped down version for the masses, which would imply to me two modes: screen and basic PC printing. It also doesn't help that the "experts" redefine common terms: it is not at all intuitive that "resizing the image" means "change the way it prints without affecting the image at all" in a tool that is an image editor (i.e. it's whole purpose is to change the image). It would make more sense to make that redefinition in Illustrator, though that sort of thing still ought to be in a "print setup" menu, not a "resize" menu.

How do you intuitively ask the user if they want to scale their styles

If you don't *have* any styles (or other complex modifiers)... But even if you did, I would expect such things to be in a Styles menu, i.e. "Style/Resize" just like this one is "Image/Resize". This brings up another case that adds complexity that is often frustrating: greyed out items. If you wanted to scale a style, you would need to have a scale selected (if you had more than one; one frustrating (for a lot more than this minor reason) tool I've used requires selecting an object to edit even when there's only one). I've run into several cases where I didn't understand *why* an item was greyed out, so I would like to see greyed out menu items, either when clicked, moused over, right clicked, whatever, to bring up something that says 1. why it's greyed out ("You don't have a scale selected, so I don't know what you want me to work on") and 2. what you need to do to activate it ("You can select a Scale in the Tools/Misc/Buried/and/Hidden/Scale Select menu").

It is is a little work, but not really that hard to do an intuitive interface if you ask the question, "what is the user trying to do?" rather than the more commonly asked question "what do I have here that I need the user to get to".

IMNSHO ;-)

Re:here are a couple:

[Alaska Jack]

They should supplement Anonymous Coward with a new title: Anonymous Jerk.

    - AJ

Interface design != Software design

[teh moges]

As much as everyone here loves to create their own programs and websites, for professional jobs, it must be known that those that create the software should NOT be responsible for designing the interface. Its a challenging field. While almost everybody here can create a good design without thinking, creating a great design is alot harder. Its the same with everything. Using certain software, ANYONE can create a good website. It takes skill to create the great ones though. Using certain software, the company I work for has their interns creating press releases. They work, but they aren't great. Anyone can design a logo, but theres a reason the big companies hire design artists. The very same is true in interface design. If you are worried about it and your budget can afford it (it should be budgeted for anyway), hire an interface designer.

Re:Interface design != Software design

[josepha48]

Yes, and that's why they have people called UI designers.

That being said, just because someone is a developer, does not mean that they cannot do things to make their UI better.

For web development there are a few things you can do to make your site better and a book I read called "Defensive Design for the Web" by New Riders, is actually a pretty good book and a must read IMHO for anyone doing web site design, expectially if you are doing a web site that provides more than a personal home page. It goes over things like forms and how to make your forms better.

Even if you are a developer, you should be concerned with UI, because how can you design things for UI person to use, if you have no idea what makes good UI?

After reading this book, I was inspired to create a custom JSP tag for date handling that allowed preferences to determine the layout of the tag (MMDDYY or DDMMYY ). Because it is dropdowns there is little room for error here and I can always add date checking so someone does not try to enter a date with June 31 where June has only 30 days.

I think developers can make good UI's and bad UI's and even though the developer may not make the best UI, a good UI is easier to clean up than a bad UI. Trust me, I've seen developers do bad UI and good UI and all has to do with the developer not understanding the use of the program or application and how others will use it.

Re:Interface design != Software design

[cgenman]

As much as everyone here loves to create their own programs and websites, for professional jobs, it must be known that those that create the software should NOT be responsible for designing the interface.

While this may be true in some sense, things will still rely heavily upon implementation architecture. Good user interface is NOT about a pretty front end, but about a logical hierarchical control layout and a minimalist featureset. On a PC, a highly usable program should be possible without a single piece of art. The programmer should work with, not for, the designer and artist to create a great interface.

Really, one of the key parts of a great user interface is sending people home. Figure out the bare minimum of what you need, implement that in the most straightforward logical fashion, and go home to your wife / husband / slashdot. It will still have a learning curve for people who aren't working on it all day every day (like the developers), but it will be far more comprehensible than the average "let's pack every feature in" mess.

As a tech artist friend of mine likes to say "I want one button that says 'Do what I want,' and I want it to work."

Re:Interface design != Software design

[foxpaws]

Having worked as a Developer and a Usability Expert... Boy do I have an opinion! ;)

Here is the crux...as developers, programmers, engineers, etc, we are really advanced when it comes to usage of software and websites. We are way overqualified as "users" in other words. We are too advanced to behave as average users.

Even in UE roles, I sometimes find myself getting impatient with "average users" - "How can you NOT SEE THE NEXT BUTTON!!!???" (Of course, I keep the seether quiet.)

There is some neat stuff on how usability tends to evolve in dev. I have a draft of a ppt or odp, if you want to take a look. It also shows some of Neilsen's numbers on ROI- which are pretty impressive, actually.

All feedback welcome- pos or neg.

http://neptuneskitchen.com/usability.html

FoxPaws

Re:Interface design != Software design

[Anonymous Coward]

As much as everyone here loves to create their own programs and websites, for professional jobs, it must be known that those that create the software should NOT be responsible for designing the interface.

Curiously, note the "developer's bigotry" hidden in your comment - you implicitly assume that "creating the software" is about programming [the developer], and that creating usable software is just a secondary matter of building "the interface". Back to the remedial user-centered-design class for you, Mr Moges!

Re:Interface design != Software design

[Anonymous Coward]

So great achievments can only be accomplished by a few people? That's not an insightful comment - this can be applied to almost any field of profession and is self-evident.

Gnome Usability Report

[Enderandrew]

http://developer.gnome.org/projects/gup/ This is definitely worth a read. Many people who are good programmers aren't necessarily good at user interfaces, or worrying about how people will interact with the software. That is an area that open source software really needs to improve on, both in efficiency in usability, and in aesthetics.

Re:Gnome Usability Report

[julesh]

If I didn't find Gnome software so damned difficult to use, I'd probably be a little more interested. But they don't even seem to be able to make an open-file dialog box that's intuitive and easy to use, let alone a complex application.

Re:Gnome Usability Report

[Anonymous Coward]

Kind of ironic, then, that usability is the thing Gnome does worst.

They concentrate entirely on complete newcomers, people who've never used a computer before, and try to make everything simple for them. Unfortunately, this completely ignores the fact that the majority of people in the developed world have learned just enough about computers to blunder through Windows - which means that Gnome, by deliberately making things work totally differently (the "spatial" thing is a great example), actually makes itself less usable for the average person.

Seriously, I've watched people try to get to grips with Gnome. People who type with two fingers. People so clueless that, when they want to switch from one file in Word to another, they close Word, open Explorer, and spend ten minutes laboriously browsing for the file they want, because they don't know about Word's handy "recent files" list or ability to edit multipled documents simultaneously.

People that Gnome should be designed for.

It sucks for them. Even petty differences like the order of buttons in a dialog box throw them completely, and they can't figure out what do press because the options are "Save" and "Don't save", and they want "OK". And using the "spatial Nautilus"? Forget it. Far, far too difficult. They cannot figure out why it keeps opening more windows, or why they pop up all over the place instead all in the same spot.

So much for "usability first". Seems to be more "ideology first", where the ideology in question is "Windows users? We don't need no stinking Windows users".

Re:Gnome Usability Report

[pugdk]

I couldn't agree more. Trying to tie usability and gnome together is like saying oil mixes well with water...

Gnome usability makes me puke, this socalled "linux desktop" does not remotely do what anyone would want a desktop shell to do - hence when we are talking about gnome, we should talk about useless instead of usability.. *sighs*.

KDE now, here we have a consistent user interface, usability is high and you can actually get it to function as you would like - heck, this even goes a long way for Windows (XP) as well.

So yeah, lets talk usability in terms of KDE or windows or whatever else, but definitely NOT gnome.

-pug

Making data export difficult or expensive

[Freaky Spook]

I can't stand software that makes it extremly difficult to get your data out of, that is one of the worst things about a lot of software.

Developers deliberatly giving people software, then making them "upgrade" to a premium version if they want to export their mail, documents, photos, or anything else should be shot on site!

Easy import and export of data should be the one thing your product should be easy to do, aggrevating your customer because you chose to take their data then try to extort it out of them definatley does not go well for easy usability.

Re:Making data export difficult or expensive

[Jeff Molby]

I can't stand software that makes it extremly difficult to get your data out of

It sounds like you're pretty bitter. Do you think software inherently comes with import/export functionality and these developers take the time to hide it from you, just so they can extract more money?

Import/export functionality takes time. Time costs money. It is also something that most users don't care about. Sounds like a premium feature to me.

BTW, If import/export functionality happens to be especially important to you, it would behoove you to test it out when you're evaluating the software in the first place.

Re:Making data export difficult or expensive

[metamatic]

Software will either use a common file format (XML, Berkeley DB, a SQL back end, whatever), or it will use a proprietary file format.

If the software uses a standard format, all you have to do is document what it is. This is the approach Apple takes.

If it's a proprietary format, then if the software is competently designed, there will have to be some documentation of what the format is, somewhere. So all you need to do is make that documentation available. Examples: GIF, Digital Research GEM file formats, TIFF.

The third option is that almost always, you'll have some code which can conveniently be turned into an API at very little cost. Example: Lotus Notes.

So generally the only time it costs significant money to allow data export is if the software is hacked together by code monkeys.

Re:Making data export difficult or expensive

[metamatic]

Developers deliberatly giving people software, then making them "upgrade" to a premium version if they want to export their mail, documents, photos, or anything else should be shot on site!

Or off site, if they don't offer on site support.

Users are the best resource

[miyako]

The best resource for making sure your software is usable is to watch people use it. While large companies can afford professional UI designers and formal usability studies, even a humble F/OSS developer can do some simple UI testing.
When I'm working on software that is intended for users who are not developers or otherwise computing professionals, I usually try to get a regular user to sit down with my software for a half-hour or so and I watch them use the software. Generally, I just say something along the lines of "hey, wanna do me a favor? play around with this program for a bit and tell me what you think". Then watch over their shoulder. Generally this is a good way to get a list of what sorts of things are poorly placed "how do I...?", things that are confusing "what is this?...", features that users will like "can I ...?" and it's a good way to start finding bugs that only a user will discover.
A few tips that I've found doing this include
If any option is unavailable then it should be obvious WHY it's unavailable.
No matter how obvious your icons are, they should ALWAYS have text with them.
Avoid dialog boxes as much as possible
If you make your program look too much like another program, then you better make sure it looks and works exactly like that program. In other words, either stick completely with the standard way of doing things, or do it completely different. If you take some common UI element and tweek it, then you'll just confuse users. Menu bars tend to be the most common violators of this.
Understand color. A lot of applications throw colors around willy-nilly, if you are going to use color then study up on color theory and learn what colors go together, what colors are calming, etc.

Re:Users are the best resource

[strider44]

As an addition to this when someone asks how to do something, even if it's clearly documented in the manual the simple question "How do you think it should be done?" can be very enlightening. Often the users are better UI developers than programmers are.

Re:Users are the best resource

[Jaruzel]

Extending on from this - Don't forget about accessability. A correctly placed well named button is only half as good as a correctly placed well named button with a shortcut key. If your application is more than just a use-occasionally tool, and is something users are expected to use on a regular basis, ensure that they have many (standard) ways of accessing each function. Also although you think you've found a really nice way to render dialogs, or buttons, or toolbars, think about whether partially sighted people can use them, and whether yout custom widgets are screen-reader compatible or not.

My UI pet hates: Windows Media Player (we're all agreed on this one I think), Lotus Notes (So many chances to get it right, and they fail), and at the moment, Windows Vista (waaay to much eye candy).

My IU pet loves: Firefox (it just works), Windows Messenger 4.7 (MSN messenger on the other hand is unusable now), and Microsoft Word 2003 (for such a complex app, a lot of it is quite logical)

-Jar.

Re:Users are the best resource

[smcleish]

One important thing to remember which comes before you can do any actual usability testing is that you need to know about the potential users for the product. You have to bear them in mind during the design of the program; miyako touches on this by mentioning making your application look like other applications and what this means, but there is more to this. If your application is closely linked to another (a Firefox extension, maybe), then the users will be users of the other application and will have expectations based on how they use this application. So it needs to fit into the design decisions made for the other application. (That doesn't mean that your application can't be innovative - look at all the wonderful Firefox extensions there are.)

Many applications are more standalone, though, so you would then need to consider how your software fits in with your users' general experience of computer usage. This will be massively different if your users are software engineers than if they are gamblers in a Las Vegas casino than if they are old age pensioners communicating with grandchildren than if they are receptionists on a hotel front desk (and so on). Knowing how your users currently do the job your application is going to perform for them is really useful (and what they like/dislike about how this procedure). Too much innovation in terms of user activities (this is not just in terms of the actual interface, but in how the software does its job) will make it hard for users to start using the application. Google didn't re-invent the search engine interface completely; what they did shares many features with the interfaces used by Altavista and Lycos before it came into existence. What they did was to improve the experience that the users of search engines already had, by concentrating on what they wanted to do: get relevant content quickly and simply. So the Google interface is a streamlined version of other search engines circa 1998, but the major innovations are ones the user doesn't see (the relevance algorithm).

I guess this can be summed up as: do formative user research to work out how you will present your application to them, as well as testing how good it is when you've got a prototype.

Re:Users are the best resource

[mikeisme77]

I definitely agree that Windows Media Player 10 (and below) were pretty crappy UI wise. But I'm still debating about WMP 11 (as I just started playing with the beta). It actually does a lot of things fairly well--like grouping by CD (with an image of the CD), although this would be nicer if you could change the way you view the CD's so that it would be more like picking a CD off of a CD rack (especially since scrolling through 100+ CD's can be tedious in the way it's currently layed out. Of course, on the other hand, what's really annoying about the new version is the way of changing media types and I didn't find it very intuitive to be able to view all my music (I was expacting the link for that to be on the top--but it was near the bottom). Plus, I had to jump through hoops to delete some images from my library that I just wanted deleted from the library (and not my whole computer)--before it used to ask you which you wanted, now it goes by an option setting. So now that I'm thinking about it... WMP11 sucks as well... it just has a pretty gloss :P

Speaking of messengers... I think Trillian Pro (with the exception of SOME of the options menus) is very nicely designed for a messenger--and I'm a huge fan of the history tracking feature that's part of 3.1+ (it's so much nicer than trying to sort through a text log).

Re:Users are the best resource

[rossifer]

Often the users are better UI developers than programmers are.

I might say that each user brings a different perspective to the discussion, and maintaining perspective on the UI they're writing is a skill that is very difficult for most developers to maintain.

Restates, I disagree that the user is a better UI designer, but instead, they can help developers get outside their normal "deep in the guts" perspective. I intensely dislike the assumption that developers are "bad at UI development". Most are actually pretty good at identifying poor designs and making them better.

Regards,
Ross

Re:Users are the best resource

[strider44]

As a developer I'm not going to say that I'm a bad UI designer. Actually quite the opposite, I regard myself as a good UI designer. That doesn't mean that I can't accept advice even from users because as you say they bring a different perspective (and most notably a different skill level).

I just said that they "often" are better UI designers for rhetoric effect, it wasn't designed to be looked at with pedantry.

Re:Users are the best resource

[99BottlesOfBeerInMyF]

Restates, I disagree that the user is a better UI designer, but instead, they can help developers get outside their normal "deep in the guts" perspective.

Software is designed with a purpose. Users obtain software and try to use it to solve a task. While no single user should be taken as the epitome of all users, you have to remember the point of the software. In general a user-centered approach is ideal and the UI should have some disconnect from the underlying code. Ask users what they need to do to solve a problem. Then design a UI to do it. Then write the code to make the UI work.

The problem is, most open source, and even closed source developers develop for themselves first. This means, they get the code working, before they code the UI. The problem with this is, by the time you have the code working, you've biased yourself as a user. As a result, most UI designs made after the underlying code reflect the code's perspective more strongly than the things the user wants to accomplish.

I intensely dislike the assumption that developers are "bad at UI development". Most are actually pretty good at identifying poor designs and making them better.

I agree, mostly. Developers are just as good at UI design as anyone else, provided they do it before they write the underlying code and don't have making the underlying code easier in mind when they do it. This, of course, almost never happens, hence the reputation.

Re:Users are the best resource

[nmos]

The best resource for making sure your software is usable is to watch people use it.

Agreed 100%. I'm not a real programmer, just a sysadmin who sometimes has to whip up small tools to fill the gaps in between the customer's real programs. It always surprises me just how often users to put my tools to use in ways I'd never considered and once a person decides they like a tool they try to use it for everything.

I'd only add though that even an individual user's expectations can/will change as they become more familiar with your program, especially if they have to use it all day long. I once put together a very simple crm type app for a customer who has several blind and low vision employees. The very first thing I learned from the prototype was that the people using screen readers HATED information presented in tables, especially with lots of columns. Once you get more than 4-5 columns it's really easy to loose track of where you are and you cannot just glance up the screen a bit to remind yourself which column you are in etc. So for the production version I added an alternate view that explicitly labeled each piece of data. At first they liked it a lot better but as time went on I started getting feedback that it was too verbose. No one want's to hear "Customer Name" 5000 times/day. By the time the year was up most of these same users had actually switched back to the table view and actually liked it better.

I guess I'm just saying that what is good for someone who is going to use something day in and day out may not be obvious the first time they look at it and they guy that says he prefers large, friendly, easily identifiable icons at first is going to be screaming for more screen realestate later.

suggestions

[illuminatedwax]

Jef Raskin's The Humane Interface

Re:suggestions

[4D6963]

I think that Jef Raskin is overestimated when it comes to interface design. He doesn't even deserve that title of father of the macintosh, since his original contributions from the late 70's can hardly be found as such in the Macintosh, and then, he's over rated. The last stuff he was working on with his son before he died was a concept of GUI that would be based on zoom. I tried that flash demo at his website and it's an euphemism to say that I wasn't convinced.

Well OK i'm talking about the man and not about the book, but I just want to say that he's not such a reference.

Re:suggestions

[BenjyD]

I read The Humane Interface and it's an interesting book. Raskin had some odd ideas, but the book gives you a different view on interface design beyond the standard menu, toolbar and mouse layout.

I think his concept of a zooming interface is basically what iPhoto, Picasa and Photoshop Elements use in their browse modes and it works pretty well there.

I quite liked

[LukeRazor]

I recently read "About Face 2.0" I found myself dis-agreeing with some of the details and felt there were a few ommisions but the definitions of software was sound

Also Joel on software has a great book excerpt online to get you in the mood

About face link
Joel book excerpt

Re:I quite liked

[PixelJonah]

I on the other hand was quite impressed with About Face (albeit 1.0). It and other books like The Psychology of Everyday Things / The Design of Everyday Things (diff. versions of the same book) by Donald A. Norman get you in the correct mindset to think about / understand the issues in the right way.

Re:I quite liked

[bensch128]

I hate to be a me tooer but I agree with the parent. I am really enjoying About Face 2.
They're challenging the basic assumtions that us programmers make about how the user works:
1) Why do we need a save button? Ideally, the program will backup a version of the document after every change and if the user undos, then the program will move to a previous backup seemlessly
2) Why do we have so many dialogs asking for comfirmation?
3) Why isn;t undo/redo universal in the operating system, or at least in the part of the system which the user uses always?

I find them to be very refreshing to read.
Ideally, the filesystem would support the kinds of behaviors they are talking about. (basically have a SCM instead of flat files and it'll track all of the modifications, branches and merges)
I think that this would be a very good direction for one of the KDE/gnome projects to move towards.

Cheers,
Ben

Christopher Alexander is also a good read

[2nd Post!]

There is information about him on the web, and he has a few good books such as "Notes on the Synthesis of Form".

Why do I mention him? To a certain extent, especially to users of software, the interface IS the product. The interface is the only way they will ever use any of the features, so if something is hidden, hard to find, hard to use, or designed to be misused, then that feature will never be of any prominence.

So remember to design the interface around your users and your problem. Your program is literally the interface that sits between the users and the problem, a bridge as it were.

A textbook I used last semester does a good job...

[deezilmsu]

Designing from Both Sides of the Screen. Worked really well for the project I worked on, and it's a great process and implementation book.

Ask Tog

[Arker]

Tog on Interface and Tog on Software Design.

Usability Studies are a must

[jchenx]

I think too many companies focus just on heuristic evaluation. That's basically paying a UI expert to tell you what to do and what not to do. A lot of companies won't even hire a usability expert, instead relying on their own engineers to "read a lot of books" and try to wing it.

This is bad.

Just like how software engineers should not be trusted to test their own code, they should also not be trusted to do "good usability". I'm saying this as a software engineer, who also has a Masters in usability engineering and has been in the field for a few years. Too often I'm surrounded by fellow engineers who think they know what's best for the user. Also, they'll claim that a certain design is best because it also makes for a "clean UI" and "clean code design". Then we sit users in front of the application, and all hell breaks loose.

Don't do this. Spend the money to hire a good usability expert, and have THEM perform proper usability studies. Good usability is NOT necessarily about a "clean UI" or "clean code". It's about a product that people know how to use. After this is established, it is then up to the engineers to make sure the actual implementation itself is clean, extensible, un-cluttered, etc. Not the other way around.

Re:Usability Studies are a must

[Decker-Mage]

I couldn't agree more. As a systems analyst and systems engineer, the first thing I do is spend at least a week working with and observing the people (workers) that will be using whatever I design. After I have the semi-final product, I do the same thing again, this time observing and talking to them about the program. Sometimes a rewrite of the UI is required and I don't have a problem with it on my end. If they are unhappy with the product, they won't use it or will use it reluctantly which is unacceptable in my book. The guts of the program are easy, the UI can be very hard. It's more about psychology than engineering in my book.

Re:Usability Studies are a must

[ErroneousBee]

I think too many companies focus just on heuristic evaluation. That's basically paying a UI expert to tell you what to do and what not to do. A lot of companies won't even hire a usability expert, instead relying on their own engineers to "read a lot of books" and try to wing it.

This is bad.

But it is a start.

In an ideal world we'd all be at stage 5 or better. Unfortunatly, some of us are still at Stage 1 and spending 50% of our development time just fighting political battles simply to stop developers adding modes and non-standard interface features (like entering YES/NO into textfields rather than using a checkbox).

So my aim at the moment is is to get interface development out of the hands of one particular development group. Then I hope to start refactoring the interface and applying heuristic evaluation before I even consider getting any kind of useability testing or outside expertise going.

I'm even battling the interface testers, who have loads of regression tests for the current interface and dont want to have to start again. Testing mostly constists of checking a new feature is implemented, not whether its implemented well.

Re:Usability Studies are a must

[jchenx]

Hey, that's a really good link. Thanks for sharing it!

Yeah, I understand that not everyone can jump up to stage 5+ immediately, and most companies are going to have to take "baby steps". I was just venting at developers who are still stuck in the early stages, and think that it is "good enough" to read books, with never the thought that they should go beyond. Frankly, I think that's a lot of the problems with open-source apps and why their usability often lags behind. Devs don't want to take the next jump, either because they don't think they can, or they don't want to. :(

How about wyoGuide?

[wysiwia]

See http://wyoguide.sf.net/, it can be used with any programming language with any framework on any platform. So far it's the only guide which gives advice in a cross-platform fashion, has sample code and if you happen to use C++ a demo sample for use as your starting code base.

O. Wyss

Re:How about wyoGuide?

[mikeisme77]

I glanced at your guide and then I glanced at your Desktop. Two quick suggestions:

On screenshots for a desktop usable by "everyone" the first screenshot should ABSOLUTELY NOT BE A TERMINAL WINDOW... My grandma wouldn't use a terminal. Oh, and maybe not have the login as 'Root'--although that's a lesser issue since it's just a screenshot.

The other thing is that you may want to consider switching from wxWidgets or GTK+ or whatever you're using to Qt. It has more controls available to it and its considerably easier to create more inviting looking interfaces. While, yes, ease of use and functionality should be the primary focus, there's no reason to sacrifice the look and feel. Qt simply has a much nicer look and feel that user's of Windows and OS X will feel much more at home with, and thus it would be more for "everybody".

That's just some creative criticism for you. But really, overally, it looks like fairly good work, so keep it up! I mean, really my criticism is just sort of nitpicking and is sort of aimed at Unix developers in general.

Re:How about wyoGuide?

[wysiwia]

On screenshots for a desktop usable by "everyone" ...

wyoGuide and wyoDesktop are two separate projects, one is about applications the other about a desktop. So far I spend almost all the time for wyoGuide which leaves nothing for wyoDesktop.

The other thing is that you may want to consider switching from wxWidgets or GTK+ or whatever you're using to Qt...

It's amazing that everytime I bring up wyoGuide a QT-Fan tells its story albeit no QT-Fan seems to be willing or able to provide sample code for QT. Why?

wyoGuide can be used with any framework and no preference of QT so there's no point in switching and definitely not as long as there isn't appropriate sample code.

O. Wyss

A few simple guidelines

[c0d3h4x0r]

Just by following a few simple common-sense guidelines, you can drastically improve the usability of any given software:

• Simplicity: keep things as simple as possible. Fewer options/settings/etc means less to have to figure out. If you must provide an option for something, supply a reasonable default. The user should never have to configure a bazillion options before being able to just use the program.
  
  
• Sane hierarchical organization: The human mind can only processes and deal with the external world by grouping, categorizing, and thinking of a collection of items as a single "chunk". So sanely organize options in hierarchical menus; sanely organize navigation into a tree-like path; etc.
  
  
• Direct manipulation: users always expect to be able to direclty manipulate an on-screen object by clicking directly on it, dragging it, etc, so design your UI that way. (Example that violates this: a listbox with items in it, with buttons underneath that must be clicked to act on the selected item, rather than allowing the user to right-click on the item itself to get a pop-up menu.)
  
  
• Data transparency: there should always be a way in the UI for the user to clearly see the information they want organized in the way they want it, and it should never be a mystery to the user where some calculated field came from or how it was calculated.
  
  
• Terminology: keep technical lingo out of the program's UI as much as possible, and make all text and phrasing clear to non-technical users. Whenever an error occurs, present a dialog that clearly explains the nature of the error and which also suggests a course of action that might rectify the error.
  
  
• Real-time on-screen feedback: when a user performs an action, they need immediate feedback to know whether the action succeeded or failed. Real-time responsiveness is super important. If a user-initiated action will take longer than about 0.1 seconds to achieve the ultimate result, then you need to put up a suitable progress indicator that updates itself responsively as the operation proceeds. If the user clicks on something and they don't realize the system is just busy processing their request, they are likely to click on it again and again without realizing the first time succeeded. (Example that violates this: you launch an app from the Windows XP start menu... you don't hear the hard drive churning or see a hard drive light because you are remoted in via Remote Desktop... no visual on-screen cue is given that the app is actually loading up... so you try to launch it again... in the end you get 2 or 3 instances of the app).
  
  
• Don't assume user expertise: always assume your user knows NOTHING about computers.
  
  
• Scenario-based design: don't merely dump a bundle of functionality on the user; give them a program that guides them through all the steps needed to solve their scenario. It's the difference between handing someone a graphing calculator and handing them a math expert.
  
  
• Users won't read, and shouldn't have to: users don't read text -- it's a proven fact. Nor should they generally have to. For most people, reading is an unpleasant expenditure of valuable energy and time that could instead be used getting something done. If you need more than one brief sentence in the UI to explain something, then your UI is too unusable and you're just leaning on text (that won't get read) as a crutch. Users should be able to jump in and start being productive with your software without having to read a manual, README file, or any other long-winded explanation whatsoever.
  
  

Re:A few simple guidelines

[stymyx]

And, most importantly:

• Software model should conform to user model: Always have the program do what the user expects.

Re:A few simple guidelines

[wysiwia]

Just by following a few simple common-sense guidelines, you can drastically improve the usability of any given software:

I just read your comment because of two reasons, first it just comes after mine and second because it's just about what I had in mind when I designed wyoGuide (see http://ask.slashdot.org/comments.pl?sid=186617&cid =15399619. But the difference is you tell just common sence while I show how this common sense can be implemented into code. I invite you to look through the guideline and discover the points where common sense might be improved so at last we get better applications.

O. Wyss

Re:A few simple guidelines

[isj]

Don't assume use expertise

I am one of the few people that have read the CUA guidelines, and they make at lot of sense, although many of the specific details are now outdated. The CUA guidelines say that you have to first decie if the UI is going to be a standard UI where it has the conform to system defaults and in general user's expectations; or if the UI is a so-called walk-up-and-use UI (such as ATM interfaces). The difference is that the standard UIs have to conform to standards but can contain many features, while the walk-up-and-use UI has to be simplistic and require absolutely no learning, but can break any standard as long as it makes it simpler to use.

So the guideline should be:

• Know your users: Don't assume your users have no expertise, but neither assume that they have. Find out. This impacts not only the program UI but also the documentation. If you do not know your users (or the intended target group) then the program is always too simple and to complex at the same time.
  

Re:A few simple guidelines

[Haeleth]

Just by following a few simple common-sense guidelines, you can drastically improve the usability of any given software.

You appear to be claiming that the guidelines you quote are universal and apply to every conceivable bit of software. I would beg to differ.

Simplicity: keep things as simple as possible. Fewer options/settings/etc means less to have to figure out.

Photoshop would not be a popular program if it only provided the five most common graphical operations and only let you configure three aspects of each. It's successful precisely because it's insanely configurable.

In other words, while there is indeed a place for simplistic software (witness the popularity of basic photo editing programs that literally only offer crop, size, and red-eye removal), it is by no means desirable for all software to be simplistic. Complex tasks require complex interfaces. Simplistic interfaces limit users to the options you have chosen, and I find it hard to believe that you can imagine all the possible ways a user will want to use your program.

Don't assume user expertise: always assume your user knows NOTHING about computers.

You cannot possibly believe this applies to all software. Are you seriously saying that the writers of a kernel debugger should assume their users know nothing about computers?

Scenario-based design: don't merely dump a bundle of functionality on the user; give them a program that guides them through all the steps needed to solve their scenario. It's the difference between handing someone a graphing calculator and handing them a math expert.

If a mathematician asks for a graphing calculator, you think they should instead be handed another mathematician?

Yes, simple tasks should have simple interfaces. Anyone should be able to answer emails, browse the web, write letters, keep an address book and diary, and print photos from their digital camera.

But that does not mean that simplicity should always be prized over functionality. Some things in life are tough. I've never driven an 18-wheeler: I would not expect to be able to sit down in one and take it across the continent. I've never filed a lawsuit: I would not expect to be able to waltz into a court and win a billion-dollar case. Why should I expect computers to be any different? If users won't read manuals, that is the users' problem.

Re:A few simple guidelines

[tepples]

If you must provide an option for something, supply a reasonable default. The user should never have to configure a bazillion options before being able to just use the program.

In an e-mail program, what is the "reasonable default" for outgoing server, incoming server, user name, and password?

Terminology: keep technical lingo out of the program's UI as much as possible [...] Don't assume user expertise: always assume your user knows NOTHING about computers.

Should each program for Windows, Mac OS, or X11 have to explain what a keyboard is, what a mouse is, what a scroll bar is, what a title bar is, what a close box is, what a menu bar is, what a file is, what the Internet is, etc.? If the user knows nothing about computers, then how did your software get onto the user's computer in the first place?

If a user-initiated action will take longer than about 0.1 seconds to achieve the ultimate result, then you need to put up a suitable progress indicator that updates itself responsively as the operation proceeds.

If a user-initiated action requires connecting to a remote host over the Internet, how can the indicator "update[] itself responsively" if the round-trip time is several hundred milliseconds?

Whenever an error occurs, present a dialog that clearly explains the nature of the error and which also suggests a course of action that might rectify the error. [...] Users won't read, and shouldn't have to

So how do I get this "clear[] expla[nation of] the nature of the error and [] suggest[ion of] a course of action that might rectify the error" through to the user if the user does not read? Should all programs that use dialog boxes default to reading the dialog box aloud through the screen reader? Should all programs designed for operating systems that do not have a screen reader come with one?

Scenario-based design: don't merely dump a bundle of functionality on the user; give them a program that guides them through all the steps needed to solve their scenario.

How can a developer of modest means know exhaustively what the user's scenarios will be?

Re:A few simple guidelines

[jholzer]

I don't think Photoshop is successful because of it's "outstanding" interface. People use Photoshop because it is very good at image editing. Photoshop is an example of; if your application is very good at something, people will use it inspite of it's crappy interface.

For simple image editing/processing I use iPhoto first, since it is very easy. If I need a little more I'll use Photoshop.

I personally hate these monolithic applications. I much prefer the iLife flow with simple, more specialized applications to complete my workflow. I edit a movie in iMove then go to iDVD to author the DVD. It works out much better then trying to shoehorn DVD authoring and movie editing into a single application.

Re:A few simple guidelines

[jskiff]

Don't assume user expertise

I disagree with this. Unless you are working on an application that is only going to be used rarely, you user will not be a novice forever. They may never become an expert with your application, but they will in relatively short order become an experienced user. It seems like you should make it accessible for both extremes, but focus on the middle ground.

Re:A few simple guidelines

[c0d3h4x0r]

It seems like you should make it accessible for both extremes, but focus on the middle ground.

There appears to be a common misconception that making an interface usable for newcomers means making it annoying for experts, but no such trade-off is necessary. A truly usable interface is one that is both easily mastered by newcomers and efficient and transparent to experts.

Just because some existing software (like Microsoft Bob or the Office Clippy) tries to accomodate newcomers in a way that annoys the hell out of experts, that doesn't mean you have to trade off between the two. It just means the designers of those programs did a terrible job with usability.

Re:A few simple guidelines

[GWBasic]

Nice post. A few points:

• Almost everything you say applies to APIs as well as GUIs. I can't stand APIs that don't let me directly manipulate objects or make it very difficult to debug my "user errors".
• I disagree with "Don't assume user expertise: always assume your user knows NOTHING about computers". Are you going to explain how to use a mouse and keyboard in every program? I think it's fair to say that it's better to spend some time picking a minimum knowledge level.
• Scenario-based design is over-rated. It's given me far too many programs that try to force me to do some imaginary task that I don't want to do! (Think of Word's infamous paper clip.) IMO, wizards serve two purposes: They help teach a user how to use a complex program, and they act as shortcuts for tasks that would take longer using a fat cliet. The way that Microsoft embedded .zip file handling in the shell is a great example of scenario-based design. Word's auto-formmating is a horrible example, because it never gets it right.
• I find the statement "Users won't read, and shouldn't have to" is misleading. It's true for simple web applications and utilities. There are applications where a learning curve is worth the hassle. Maple is an incredibly powerful mathematics program; yet it is only powerful because its interface has a steep learning curve. On the far extreem, it's impossible to use Visual Studio without prior knowledge of a programming language. Trying to go 100% intuitive GUI also leads to repetative scenarios that can't be automated. For example, Surcode's DTS CD encoder can't be called from the command-line, thus making it difficult to automate.

Re:A few simple guidelines

[c0d3h4x0r]

I find the statement "Users won't read, and shouldn't have to" is misleading. It's true for simple web applications and utilities. There are applications where a learning curve is worth the hassle. Maple is an incredibly powerful mathematics program; yet it is only powerful because its interface has a steep learning curve. On the far extreem, it's impossible to use Visual Studio without prior knowledge of a programming language. Trying to go 100% intuitive GUI also leads to repetative scenarios that can't be automated. For example, Surcode's DTS CD encoder can't be called from the command-line, thus making it difficult to automate.

Your reply isn't the first to cite math modelling or programming software as a supposed counterexample. But these are not valid counterexamples.

A mathematician using math modelling software should only have to know about their field of expertise -- math. They shouldn't also have to be a general computer/OS expert to be able to use the software.

A C++ programmer using Visual Studio should only have to know about C++ programming. They shouldn't also have to be an expert on system administration and the inner guts of the OS just to be able to use the IDE and compiler.

And just because someone is a math genius or a C++ programmer, that doesn't mean they will be any more inclined to read a manual, README file, or text in the software's UI. It's generally human nature to want to read as little as possible as quickly as possible, regardless of how smart you are or what field you are in. If your software is designed well, there shouldn't be any need for the user to read any instructions or documentation up front.

Re:A few simple guidelines

[GWBasic]

I agree that requiring the user to read a README file, in general, is bad practice. My point is that, for complex tasks, it's impossible to avoid a learning curve.

I'll use a non-computer example: Think about the car. Practically all cars are intuitive; yet at some time you need to go through the effort of learning to drive. The same applies to cooking; it's very easy to boil an egg or grill a steak, but at some point you need to go through the effort of learning how to use a stove or grill.

Going back to Maple: When I was in college, my entire freshman class used to curse Maple out for being hideously difficult to use. It was so difficult that I participated in a 6-month project that compared its usability to other mathmatics programs. The result was that we determined that the "beginner-friendly" alternatives were significantly less powerful. (At the time, Maple primarily consisted of a command-line interface that was similar to Pascal.)

The same can be said for Visual Studio. On a daily basis I use important features that can only be learned by reading a manual. Yet, Visual Studio is a good example of making an effort to reduce the need to read a manual:

• Instead of spending a lot of time leafing through API specs, I can use Intellisence and auto-completion.
• Instead of reading a document for compiler switches, I can configure compiler settings in an API.

Again, returning to the point, one must find a good balance between intutiveness and usability. A non-computer example is the automatic transmission vs. manual debate, the automatic is intuitive, but the manual performs better. Another example is the Windows command shell compared to the Bash shell; Bash is significantly harder, but more powerful then the Windows shell.

Perhaps it's better to say that the "effort to learn" a program must be appropriate to the intended use of a program; a README file is a sign that the "effor to learn" is too high.

Re:A few simple guidelines

[c0d3h4x0r]

My point is that, for complex tasks, it's impossible to avoid a learning curve.

Yeah, obviously, I get that. But my point is that the learning curve should always be minimized as much as possible (to be as close to non-existant as possible), and the learning curve should never include things that are tangential to the task at hand (why should someone have to learn how to be a Linux sysadmin just to paint something in the Gimp?) That should always be the aim of a good software designer.

Again, returning to the point, one must find a good balance between intutiveness and usability. A non-computer example is the automatic transmission vs. manual debate, the automatic is intuitive, but the manual performs better. Another example is the Windows command shell compared to the Bash shell; Bash is significantly harder, but more powerful then the Windows shell.

But your example just proves my point: wherever a choice exists between something with lower learning curve and something with higher learning curve, the option with the lower learning curve is the obvious correct choice for newcomers. And if a design is truly usable, it will be equally efficient and hassle free even for an expert -- that's exactly the case for the "automatic vs. manual" transmission, since no person accustomed to driving a manual transmission has difficulty figuring out and driving an automatic.

Re:A few simple guidelines

[elcid73]

Why should I expect computers to be any different? ..because you're more apt to run across a computer when you are, let's say- getting money (ATM), getting gas, balancing checkbooks, writing, etc.. than you are to... oh I don't know, let's say, go to court or drive an 18 wheeler.

Re:A few simple guidelines

[GWBasic]

So we agree!

Re:A few simple guidelines

[Anonymous Coward]

since no person accustomed to driving a manual transmission has difficulty figuring out and driving an automatic.

Imagine someone used to manual transmissions trying to drive an automatic for the first time. The road is a bit slippery, the car starts to slide. Reflex action: Left foot hard down on the left pedal.

"no difficulty"?

Nielsen & Norman

[Anonymous Coward]

These are two guys who have some good stuff to say about usability - Jakob Nielsen (http://www.useit.com/) and Don Norman (http://www.jnd.org/) - Don Norman is the author of 'The Design of Everyday Things', mentioned above.
Also worth a mention is Joel Spolsky - http://www.joelonsoftware.com/

Order of appearance

[Anonymous Coward]

Fixing complex intra-application behaviour and logic later in the UI is hard.

Building sane backends to UIs that have been built first is easier and more purposeful.

So start with the interaction design, with people, on paper and let it flow from there. You'll then know what needs to be done and how.

J

Apple got it right

[cpct0]

If you want to that the basic principles, simply go with the Apple Human Interface Guidelines. Yeah I know, sometimes Apple do weird things too... But the first part of the book (the first 3 chapters) contains the basic information you need to create a good interface, totally platform-agnostic. It's been my guideline for years, since the System-Finder times. *sigh* back then the interfaces were easy and there was no brushed aluminum to foil the day.

http://developer.apple.com/documentation/UserExper ience/Conceptual/OSXHIGuidelines/index.html

That version contains updated and modern Part I for the super buzzword "U-Ex". But they decided they did not have sources anymore ... so I suggest you go for the "Original" Classical environment Human Interface Guidelines book for the first two appendices:

http://gemma.apple.com/documentation/mac/HIGuideli nes/HIGuidelines-2.html (on total bottom of page)

The resources are relatively adequate, but the bibliography extends to much more than the basics, it covers all the "why's" and "how's". It predates Mac OS, though, so the books were mostly rewritten, but the basics are still prevalent on many topics.

Jakob Nielson

[MythMoth]

Read Nielson's essays. Then do what they say. Specifically conduct usability testing in the manner he prescribes - anything else is a waste of time and money.

Inmates

[Kman_xth]

I've recently read ' The inmates are running the asylum: Why high tech products drive us crazy and how to restore the sanity'

Found it an interesting read, giving lots of examples on how usability should be approached and shows some good examples on how it can fail. It also introduces some techniques surrounding 'personas'. But for me, the most important thing the book did was triggering a certain way of thinking about usability, which I think is far more important than any technique a book can throw at you.

Usability is sometimes fighting windmills

[SlappyBastard]

For example, we tried several times to start using Ajax (forgive me for saying it) to make interfaces more like desktop applications.

Users completely rebelled. The general sentiment was, "Why doesn't that bring up a page when I click on it?"

The importance of "usability" is overstated by people who make money parroting it.

Yes, simplicity and obviousness are important. Just don't confuse those objectives with usability as it is now sold.

Usability starts with a set of normative values that most users accept. This often includes accepting that most users accept a version of the internet that is closer to 1996 than 2006.

good question

[Anonymous Coward]

I'd like to say something clever, but... ah... oh, well, don't make me think... http://www.sensible.com/buythebook.html

The Golden Method

[Spit]

Just interface your program with an electrode in the control device. Then when the user does something stupid, you zap them! Problem solved.

Re:The Golden Method

[Anonymous Coward]

I'm predicting that your kids are going to be on TV one day.

Holy Grail

[Anonymous Coward]

Good, usable software is not the holy grail of development, because it's been done. Holy grail means something everyone wants to find but no one has.

Re:Holy Grail

[Anonymous Coward]

This is not the conventional Monty Python wisdom:

What? He says "he's already got one!".

Starting a CD without autorun?

[tepples]

insert CD, wait for the dialog box to appear

The dialog box won't appear because I held Shift while inserting the CD to prevent autorun from installing malware. How do I start a CD without using autorun?

Re:Starting a CD without autorun?

[oojah]

I think that autorun and "auto do a particular action" are different things and can be disabled individually. I may be wrong though. Can't help you more than that I'm afraid...

Re:Starting a CD without autorun?

[Otter]

If you have a desktop icon for the CD drive, right-click on it. Or use "Play->DVD, VCD or CD Audio".

Model-view-controller in programming books?

[tepples]

1) Why do we need a save button? Ideally, the program will backup a version of the document after every change and if the user undos, then the program will move to a previous backup seemlessly

For the same reason we have a commit statement in an SQL DBMS: to make our changes visible to other processes that expect reasonably atomic updates. Even in applications that commit after typing each word, the "Save" command marks a specific version more prominently so that the program can suggest reverting to that version.

3) Why isn;t undo/redo universal in the operating system, or at least in the part of the system which the user uses always?

Because not enough beginning programming books mention the model-view-controller paradigm that treats all changes as reversible transactions. Because implementing some (more major) changes as reversible transactions causes disk thrashing. Because there's a limited amount of space on the hard disk so you can't just "undo Empty Recycle Bin".

Re:Model-view-controller in programming books?

[bensch128]

For the same reason we have a commit statement in an SQL DBMS: to make our changes visible to other processes that expect reasonably atomic updates. Even in applications that commit after typing each word, the "Save" command marks a specific version more prominently so that the program can suggest reverting to that version.

Users are NOT processes. Besides, if the files were treated as being in an SCM, specific versions would be version 1.3.4 (Date 2006-25-3 13:34) or whatever other tag the user wanted. Maybe add a "Tag" button so the user can mark a new version but I doubt it would be used very often.

Because not enough beginning programming books mention the model-view-controller paradigm that treats all changes as reversible transactions.
Maybe these ideals should be aimed only towards advanced programmers?

Because there's a limited amount of space on the hard disk so you can't just "undo Empty Recycle Bin".
Hard disk space is pretty cheap nowadays. Besides video, maybe audio and maybe image processing, there's no applications that take a huge amount of space (besides word files packed with embedded images) If the files were stored as diffs (even the binary files), you probably wouldn't be using very much space...

Cheers
Ben

Alan Cooper's...

[fleck_99_99]

The Inmates are Running the Asylum (disclaimer: Amazon link provided as a courtesy and is not a referral link to the best of my knowledge)

This is a good book by the designer of VB that has a nice model of user-oriented design and some pretty interesting case studies -- design of airplane entertainment units, scanner software, and others.

(1) Consistency.

[James A. V. Joyce]

(2) Good error reporting and recovery.

GUI Bloopers

[Anonymous Coward]

If you're more interested in practical GUI advice, I highly recommend GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers (not a referral link). ISBN: 1558605827

The book goes in-depth on the basics of good GUIs laid out using your standard widgets (little, if any, talk of bleeding edge HCI theory). It gives tons of examples of what the author views as good and bad GUI practices. Some of the things he cites are more nitpicky IMO, but overall it's a valuable resource that'll make you more aware of the common pitfalls of GUIs and how really good GUIs are laid out. It also talks about proper messages to display to the user, like don't present a user with a yes/no question and give them OK/Cancel as their buttons...

First mistake

[TheSkepticalOptimist]

Thinking that reading a book and using the HCI (Human Computer Interface) buzzword will improve the user experience of your software.

Few software development managers give developers enough time to hone their user interface. In my firm, software developers are often involved in the back end code, writing complex algorithms or process functions. This is the meat and potatoes of the software, without it, there is no reason for the software to exists. When they need some UI associated with the back end code, it truly is a last minute implementation and an afterthought, but only because they are pressed to get the product released on some arbitrary deadline management and sales arrived at. What happens tends to be sloppy and poorly written UI for the sake of brevity.

Good UI just takes time to develop, and until your firm realizes that it should account for at least 40% of the development time, then reading a book isn't going to help you. Also, I have read those books, and its just a bunch of blowhards telling you what they think is good UI, its not necessarily what is going to be good UI for your applications.

You also should find and take the time to hire or cultivate at least one developer that is skilled in UI design. Having at least one good UI developer on your team frees up the other developers to focus on the internals and lets a dedicated developer focus on the UI. This also prevents the idea of "too many cooks in the kitchen" problem that many firms have, the idea that numerous developers are writing UI code and each have their own personal idea of what the UI should look like. You can create a UI guideline that is supposed to force developers to write UI a certain way, but in the end, they are going to do what they think is right, and your application will have a mismatched look and feel to it. Having one or two dedicated UI developers will ensure a consistency across the entire application.

It is a talent, its one of the few areas where creativity and talent comes into play when developing software. The talent is in understanding and putting yourself in the place of an end user. Its understanding your target audience and catering to their needs. This varies with every software project you work on and no book is going to cover all the bases.

In the end, if your a single developer responsible for both front and back end code, then take the time to USE your software. Most software developers only use their software in so much as to test their back end code. But using your software just as your end users would is the best way to ensure you UI works and flows well. Try to imagine all the stupid things your end users will do with the software, or all the different ways an end user will interact with the software. For instance, I don't use keyboard shortcuts, so I tend to overlook them when I develop a UI. Learning to realize that end users might exclusively use keyboard shortcuts instead of the mouse means that when I test my UI, I will notice the weakness before I release the software.

But it takes time to both learn what makes good UI and to develop good UI. You could read a book and it could offer a few insights, but the best way to learn to code and to learn how to write good UI is to do it, use it, and allow enough time to properly develop it. In the end, if you write software you hate or wouldn't want to use, then your not writting good UI.

Re:First mistake

[99BottlesOfBeerInMyF]

First mistake... Thinking that reading a book and using the HCI (Human Computer Interface) buzzword will improve the user experience of your software.

I disagree. There is definitely low-hanging fruit for usability improvement. Certainly procedural changes in the design process and testing is the way to go to have a truly usable UI, but that is not always possible in every environment. Just reading a book can allow a designer to avoid some of the most common snafus and provide them with a better framework for thinking about the design. Just following a set of rules, like Apples design guidelines, without even understanding them can provide consistency and take advantage of a lot of UI testing results that can be summarized into simple rules.

In my opinion, in a perfect world, users should be the first part of a design process. Ask them what they need to accomplish and then ask your developers what can be reasonably accomplished. Find the middle ground and then write the UI for doing it. Once this is accomplished, simultaneously test the UI and write the back end that supports it. Don't be afraid to expose limitations of your back-end software. It is often better to let users know what is really going on then to give them a perfect UI that does not reflect reality.

Hiring a UI guy is a good step, but if there is not a commitment to the UI from the beginning of the process, it will never have stellar results. Of course in the real world all of this varies greatly by user type, available resources, and how important the usability is to the project goals. Sometimes it is important to be able to say, "He runs security for all of a major ISP; he can figure it out already." rather than pressing for more money and time spent on polishing a UI.

Canceling actions

[DreadPiratePizz]

There needs to be a way to immediately cancel something if I want to bail out. Examples of this not working are in Safari. While a webpage is loading, I can click the cancel button, and it will not register until several seconds later. Sometimes when the button is depressed, it then takes 5 seconds to actually stop. Or in Final Cut Pro, canceling a render can take 10-15 seconds. My computer is by no means the fastest, but how hard is it to make a cancel button that actually works? How difficult is it to simply STOP?

User Interface Hall of Shame

[VGR]

I recommend The User Interface Hall of Shame. (Link is actually a mirror, and not my mirror. The original doesn't seem to exist anymore.)

Despite its age, it has plenty of valuable lessons. For instance, abuse of tabs is certainly as relevant today as it was eight years ago.

wow

[Anonymous Coward]

For most people, reading is an unpleasant expenditure of valuable energy and time that could instead be used getting something done.

For most people. . .

• abstract reasoning is a unrewarding activity that might call into question our comforting unexamined assumptions, limiting our ability to *make things happen.*
• physical exercise is an unappealing chore that does not immediately gratify our vanity; self-delusion is a much more effective strategy, offering immediate feedback.
• speech acts are an uncomfortable personal interaction requiring energy and time that could instead be spent playing UT.

End-user testing

[Anonymous Coward]

If you are developing the software yourself, spend time with the target audience to see how they behave in the UI that you've created.

If you are hiring programmers, video tape the session -- both the on-screen activity and the person using the computer.

The darndest thing is that most end-users won't read, and they are not patient. And when there's a bad design element that flusters them, it makes them read even less!

here are a couple: Blender, Gimp.

[Anonymous Coward]

"Just because a tool is powerful doesn't mean it has to be non-intuitive..."

Google's Sketchup could teach Wings a thing or two. UnrealED is a powerful tool.

This guy wanted wizards

[Jeff Molby]

Sure, those are three reasonable options that don't require an extraordinary amount of time. The poster, however, said he wanted "Easy import and export of data". I took that to mean that he wanted wizards. He probably even expected the data to output directly to the replacement software.

Re:This guy wanted wizards

[SanityInAnarchy]

Well, I'll admit there's software for which a single standard doesn't really exist, so yes, those can take a lot of work.

But, often you'll have software which, for instance, is image editing software, perfectly capable of saving as a PNG, say, but won't save AT ALL. Or, software intended for developing web pages, which saves in a proprietary format, and won't "export" to HTML until you pay more.

You know, software for which the non-premium version isn't just feature-limited, but actually unusable.

Simple picture task

[hackwrench]

How do you get a tally of what colors are used and how many pixels are set to them in any graphics editing program? It seems like it should be an easy task overall, but the only time I've seen it happen is programs I've written myself in QuickBasic!

Tog on Interface

[metamatic]

Haven't seen it mentioned yet, so:

Tog on Interface

Also, Computer Lib / Dream Machines by Ted Nelson has some valuable lessons in it.

But are SCMs themselves usable yet?

[tepples]

Users are NOT processes.

I was talking about a single user running multiple processes, such as (to given an example that would be familiar to many Slashdot users) running an editor and a compile job at once and modifying files while the compile job is half done. If it becomes easy to inadvertently put one of your apps in an inconsistent state by using another app modify a file behind its back, then your system is broken.

Besides, if the files were treated as being in an SCM

Have widely available SCMs become intelligent enough to handle images, audio, video, and other non-textual files with better semantics than just "one byte was inserted, so the entire file changed, and diffs can't be merged"? And has the usability of widely available SCMs advanced to the point where it's as easy to teach SCM use as it is to teach open/save use?

Maybe these ideals should be aimed only towards advanced programmers?

You said undo and redo should be "universal ... in the part of the system which the user uses always". So should non-advanced programmers be locked out of developing GUI applications? Then you turn PCs into game consoles.

Hard disk space is pretty cheap nowadays.

Not on handheld devices. Besides, "pretty cheap" != free, and people who have a paid-for machine that's old enough to justify an "insensitive clod" comment on Slashdot will likely complain if the ability to delete files is removed because it cannot be undone.

Besides video, maybe audio and maybe image processing

Which are promoted as the killer applications for any device that's larger than a handheld device.

If the files were stored as diffs (even the binary files), you probably wouldn't be using very much space...

Won't always help. A blur applied to a layer affects every pixel of that layer, and an equalization applied to an audio track affects every sample of that track.

Re:But are SCMs themselves usable yet?

[bensch128]

Besides video, maybe audio and maybe image processing
Which are promoted as the killer applications for any device that's larger than a handheld device.

I was thinking more about office (word, excel, access, powerpoint, frontpage, etc.) and it's open source siblings koffice and openOffice. Obviously not all video and image processing is possible. It is interesting to note though that applications like Adobe premire DO NOT modify video directly until it is exporting to a final file. Instead, it takes raw video clips and applies filters to the video so the user gets an idea of what the final product will look like. It's data files are (relatively) simple lists of which video clips to use and the list of filters to apply. (As well as the cut points and layer and insertation point information...) Adobe's formats are in binary but there's no reason why the files couldn't be in diffable text instead... I believe (but don't quote me) that photoshop works the same way.

Have widely available SCMs become intelligent enough to handle images, audio, video, and other non-textual files with better semantics than just "one byte was inserted, so the entire file changed, and diffs can't be merged"? And has the usability of widely available SCMs advanced to the point where it's as easy to teach SCM use as it is to teach open/save use?

Well, a lot of SCM notation can be translated into normal filemanager notation:
submit => save
sync to head => load
branch => copy
merge => override (but obviously not as powerful)
rename => move
I think it's more about how intutive the tools are then how the actual CLI SCM works.
And the benefit is the users won't have to save a million files with names like mydoc.1, mydoc.2, mydoc.0605012, etc....
once they learn that the system CAN track revisions for them. Binary files are different matter but I think there are diff algos out there which can handle binary data relatively efficiently. I mean, thats what textual diff'ing is doing.

You said undo and redo should be "universal ... in the part of the system which the user uses always". So should non-advanced programmers be locked out of developing GUI applications? Then you turn PCs into game consoles.

Maybe the underlying operating system should offer a easy to use SCM for application writers to use. Something with an API like "get a file handle to head", "submit new version(taginfo=0)", "Get a list of reversions", "Get a old reversion", "Branch", etc... basically integrate a SCM component into the development platform. This would make the programmer's life a bit easier.

Besides, "pretty cheap" != free, and people who have a paid-for machine that's old enough to justify an "insensitive clod" comment on Slashdot will likely complain if the ability to delete files is removed because it cannot be undone.

The nice thing about a SCM system is you can control how much space a revision list is supposed to take. So say you have 50 revisions of a file and you want to submit another one. The system will run out of space if another revision is submited. The system should detect this and:
A) automatically delete the first 2-3 revisions (for a novice user)
B) pop up a dialog (BAD!) and ask the user what set of revisions he doesn't need anymore to free up space.
I bet a combination of these two procedures should work.

Cheers,
Ben

Re:But are SCMs themselves usable yet?

[tepples]

It is interesting to note though that applications like Adobe premire DO NOT modify video directly until it is exporting to a final file. Instead, it takes raw video clips and applies filters

I'm familiar with "non-destructive editing" that uses an edit decision list. Avisynth and the multitrack editor of Adobe Audition work the same way. But can a non-destructive environment save e.g. a brush stroke in the film restoration process? And can the effects be rendered in real time for multitrack preview? (I use a predecessor to Audition, and it warns me that several of its effects do not work in real time.)

Binary files are different matter but I think there are diff algos out there which can handle binary data relatively efficiently.

True, but efficiently != consistently, especially when trying to apply two separate binary diffs to a single file where the desired result is the file with both of the changes made. This can happen in a layered image format (e.g. .xcf or .psd) when two users make changes to separate layers.

I think it's more about how intutive the tools are then how the actual CLI SCM works.

Then I'd like to see somebody implement a library that can be linked into any app that uses wxWidgets or the like.

Maybe the underlying operating system should offer a easy to use SCM for application writers to use.

When will Microsoft or Apple offer this? Or when will peripheral hardware manufacturers start working with other OS vendors?

Re:But are SCMs themselves usable yet?

[bensch128]

I'm familiar with "non-destructive editing" that uses an edit decision list. Avisynth and the multitrack editor of Adobe Audition work the same way. But can a non-destructive environment save e.g. a brush stroke in the film restoration process? And can the effects be rendered in real time for multitrack preview? (I use a predecessor to Audition, and it warns me that several of its effects do not work in real time.)

I thought that Premire/after effects "realtime" preview worked because of the reduced resolution and simplication of the filter effects. (of course you can't apply a guassian filter on DV in realtime. (I'll have to ask my friend about this though) And why can't brush strokes be stored in a vector format and just use the stencil as a uuencoded image in a text file. I don't see how this reflects on using a text format vs. binary format.

True, but efficiently != consistently, especially when trying to apply two separate binary diffs to a single file where the desired result is the file with both of the changes made. This can happen in a layered image format (e.g. .xcf or .psd) when two users make changes to separate layers.

If there was a SCM API, the programmer could give it a custom diff algorithm. Then the SCM would be able to track revisions of that file type in a sane manner. Otherwise, the SCM would fallback to the standard diff algo.

When will Microsoft or Apple offer this? Or when will peripheral hardware manufacturers start working with other OS vendors?

Maybe never. Thats why it would be interesting to implement it in KDE or gnome instead, just to see the possibilities. Then maybe the big players would adopt it too.

Re:here are a couple: GIMP?

[sysadmintech]

Many compaints about GIMP were that the interface did not exactly match Photoshop. They even made one that did, but most FOSS users revert to using the native skin in about 2 days. So, what do you think about GIMP?

an often untapped resource

[slorien]

Here's a good source of informal research that I almost never see mentioned. If you a developer for an existing product that is already in use at one or more companies, find out who the companies are (your sales department can provide) and contact their IT department. Helpdesk and desktop support people are on the front lines with users on a daily basis and know first hand what users struggle with. Talk to them. Pick their brains. Support professionals are often treated as the flunkies of an organization, and most I know would quite generously share their knowledge with anyone who treated them with an ounce of respect. Keep in mind that IT people often serve as usability experts in disquise, as they frequently must find ways to simplify and work with badly designed software and hardware that they have no power to change. So, some may even be able to offer some good suggestions as to how to correct the issues they've seen. Many IT organizations also keep detailed case records within their call tracking systems, and if you're real nice to them (ie.. feed them cookies), they might even get you some statistics on the number of calls related to a product or issue.

Though this method is not as effective as carefully designed user research, it is a good alternative when a company will not allocate any resources towards such a project. You may be able to gather a lot of information in a short amount of time, at no cost, and make a new IT friend in the process.

Re:here are a couple: GIMP?

[vanyel]

Well for starters, on Mac, it's picky about which X server it uses. It seems there are two, and they're incompatible (the nice thing about standards is that everyone can have one?). So I have one app I use frequently that requires on, and gimp requires the other. So it's been a while, but my recollection is that the photoshop version didn't work very well, and the regular interface was pretty weird (as it often seems Xt apps are). I'll try to fire it up and give some specific comments though later...

www.ok-cancel.com

[bhav2007]

http://www.ok-cancel.com/ is a great site for non-technical, insightful discussions of user interfaces; plus a great web comic on the subject.

Re:here are a couple: GIMP?

[vanyel]

I went and fetched the latest gimp, and it looks like it actually supports both X's now, that's an improvement, and there are things I like about it, like the markers on the edges showing where your pointer is.

The main thing I've always disliked about GIMP is that it's too busy and stuff is scattered all over. It's a bit overwhelming for someone starting with it, a bunch of icons that really don't mean much unless you already know what they mean or spend a lot of time mousing over. Since I've used lite versions of photoshop for a decade now, it wasn't worth the effort of jumping the hurdle.

On the other hand, it's really not much different than the little side menus photoshop puts up (which is another change I'm not sure I like in Elements, building them all into a frame around a hole where your image goes), so I'm not sure why they're more daunting.

Maybe it's just inertia... Now that I just spent the bucks on Elements a week or so ago, I guess I'll try using Gimp again ;-)