Nice little writeup that skims the surface of "User Interface Designs".
Problem is that when you decouple interface design from system design, that's all you can do: skim the surface.
#10 provides the perfect example: how to label your dialog boxes.
Once you take a larger, more organic view, you reach a much simpler conclusion: don't have dialog boxes. Just do it and provide an Undo, and leave the user alone. Millions will thank you.
An outcome you can only reach by looking at the whole system, not just the way it looks.
But almost no one really follows this advice to its core. Imagine an operating system designed this way: you could quit Photoshop, then "undo" the quit, and all your windows would reopen without anything have to re-load from disk (because it wasn't really unloaded yet to begin with.) You could "rm -rf /" and then press Ctrl-Z in your shell. You could send an email, and then pull it back from the server (or all the way from the other person's inbox), as long as they both had the same system installed.
If the entire world worked this way, you could even wire $5000 to a Nigerian scammer, then pull it back out, undoing the purchase of anything they spent it on in the process. Of course, cash would have to be replaced with a reversible commodity (credit chips that really just referenced a row in a central, though distributed, table) so money could flow back into your pocket without anyone having to hand you anything.
Taken even further, to the point where you can take out a hit on someone and then press undo after the person is dead, this begins to sound like the start of a good Science Fiction. "The Reversible Society", perhaps.
it isnt about "to the core", there are obviously non associative things that should be warned as such, but seeing as you use photoshop as an example
edit a photoshop file, quit, it will warn you to save changes blah blah, it is annoying, but also stops you deleting stuff, load it again, history is lost
Use lightroom, another adobe product for editing photos, edit a photo, quit, no dialog, its already saved, open the file again, and the history is preserved
its a much nicer experience in a lot of situations
I often wish I had an undo button in the terminal. Obviously not everything can have an undo. But most things (anything you can undo in Windows) you should be able to undo on the Web.
This is what people will expect from web applications or they won't use them.
IIRC, this was one of the design principles for ErosOS. Everything was transparently persistable and undoable, so you could reverse closing that document, or editing it, and so on.
I found the single most effective thing to do in UI is this: iterate. The average number of iterations I take for a single view is about 10 before I'm really happy.
You see #1, and it doesn't feel too bad. Then you do #2, and it makes #1 look bad. You get an idea, so you experiment and try to tweak it a little. Before you know it, you've created something that just feels good at heart. It looks good, it's appealing, it's usable, and attractive.
Some companies go extreme on this, I know Apple can go through hundreds of designs for a single product.
I have a few rules of thumb with this:
1) Never delete an iteration, including #1 which probably will look the absolute worst.
2) Just do #1, yes it will probably suck. Do it and get it over with. Then make #2 and subsequent iterations incremental improvements.
3) Don't stop until you're absolutely proud of the iteration. Be honest, don't let fatigue be your reason for stopping or moving on. True UI design is difficult and requires endurance, just like anything else that's difficult (sports, programming, writing a novel, etc).
How do you mitigate the risk of local maxima? Is there good way to try (or justify trying) radically different approaches without undermining past work?
i hate number 7. as a user that navigates web pages by keyboard (and most of the time by vi keys), i hate it when sites focus a text box on a page that has enough other content to require scrolling.
it's one thing if it's on a solitary login page or google.com where the primary content on the page is the text input field, but when you focus a search box or some other field when i'm trying to scroll with the 'j' key, it's very frustrating.
i was actually using a site the other day that not only focused some search box way off to the corner, but actually re-focused the text box every time i hit a key. it took me a short while to figure out why i couldn't scroll down (the search box was by then filled with "jjjjjjjjjjjjjjjjjjjjj").
Tip #2 is nice in theory, but styling button spacing in a cross-browser manner is nearly impossible.
Tip #7 is awful. By the time the images load, the user could already be typing in another input box. If you must set focus, do it right after the <input>.
Tip #8 is pretty bad too. Users expect input boxes to look like input boxes. See Wufoo, which does this properly by highlighting the background.
Some of the ideas aren't bad, but a few "useful techniques" won't lead to a usable interface.
Agreed. I despise it when sites pull my focus to another field when I"m already halfway through data entry. Same goes for apps - if I launch an app and then switch to something else, for God's sake don't pull me back when you're done loading. I wanted you in the background dammit.
It's also a bad idea generally to break the UI the user is accustomed to.
Tip #7 works if you put in a bit of extra effort, and make sure that the text field you're taking the focus away from hasn't been altered from its default value.
Gmail does this wrong when you add an attachment. After it has been uploaded the textarea cursor is moved to the bottom and you end up typing after your sig.
Definitely agree on your assessment. I started questioning this guy's advice after his bit on button spacing. Having the words in a button "balanced" within the button does not make it any more of less useful.
Intuitive, functional, and pretty aren't always the same thing. Having a pretty interface doesn't make it inherently usable.
The button tip makes sense if you align the button to other text. Then, the baseline of the text in the button should be aligned to the baseline of the text outside it (if both texts are of the same font-size.) If buttons center their text vertically, and themselves are centered with respect to the half-height of the smaller characters, this can misalign the text within them; playing with vertical padding can help with this.
A good deal of these techniques are applicable in an intranet setting, but are there any design tips for non-designers working on internal backend web tools?
The emphasis, of course, is on usability for long-term users. I'm not really concerned about users being able to easily learn the interface or grabbing their attention one way or the other; they are going to be trained to do that. I am more interested in making it convenient and usable for long-term users who are going to be using this software almost 40 hours a week. The vast majority of the app is asking for a few variables of input, showing tables of output, and pages of links to the forms that provide this functionality. Really boring stuff, but there is probably room for improving the usability and readability of the forms/tables.
A good interface is intuitive, in the sense of both easily learnable and easily usable. I don't think you can really decouple the two. It sounds like you're mostly just displaying giant blocks of text, so I'd recommend this excellent slideshow on web typography:
It's a bit long, but very thorough and very helpful for content-heavy design -- and it gives you exactly the CSS you need. To summarize it very briefly: a little bit of white space goes a long way.
Obviously a contrived example, and you wouldn't want so many fancy colors in a professional setting. But the key point there is to align everything nicely, and go to the trouble of grouping related fields using fieldsets and legends.
Have a look at "Information Dashboard Design" by Stephen Few, I also found "The Non-designer's Design Book" by Robin Williams very good but it's more concerned with general design principle then the specific stuff you're interested in.
The #1 bit of advice I'd give you: avoid Tons Of Data Just Lying There Syndrome.
Data is FOR something. In and of itself it is not useful. This something may be actions the user will want to take. It may also be mean taking raw data and coming up with metrics or other useful indicators.
Too many info "dashboards" just sit there, tons of stuff slapped on without this sense of actionable purpose / context.
A great technique is to modify the UI based on context and allowed actions. As I started using Basecamp (37signals) on a daily basis I realized that there are hardly any error messages in the application. If you aren't allowed to do something they hide any UI elements associated with the invalid action. This results in a simpler interface that is more intuitive.
I don't know, isn't that confusing sometimes? I know that I hate those menus with greyed out items and no explanation why a certain option is not available at the moment. Not even seeing the option at all might be even more confusing, because then I might start looking everywhere for the option to show up.
I don't know why we still don't have interfaces where you can always access a precise, clear, context-sensitive explanation for why a control is grayed out and when it's enabled. The benefits to usability would be huge!
Hiding items will limit your users' ability to discover what they can do with your product. I would minimize hiding and instead de-emphasize unavailable features with explanations why they're not yet available.
It's educational and illuminating, but compared to most colour theory books it's more poetic than academic in tone, and more emotional than theoretical in its insights.
Everything is gravy except for the part of focus on the input. I cannot express how many times that has annoyed the hell outta me whenever I use a web app that employs that technique.
First of all, I don't have a 'cause' or agenda. I found some tips in this article useful and hence submitted it. That's all. Content quality is subjective, some hate it and some like it. I have no control over this and neither do I have a problem with negative comments ON the article itself. What I dislike are personal attacks like this.
I don't even know who you are so I'm not sure why you are targeting me. Had a bad day?
Are you suggesting that top ten lists are inherently flawed? Should all list posts NOT ever be submitted to Hacker News? Or are you suggesting that I shouldn't be allowed to participate in this community because everything I share is more or less rubbish?
I joined this community 602 days ago. That's 1 year and eight months ago. I'm not a fly-by-night spammer. Everyone can see the stories I submit to verify this.
Your obvious condescension is quite unnecessary. And frankly, I find it quite insulting. I don't have a devious plan to destroy Hacker News so maybe you should chill out a bit.
Sorry, I wasn't trying to be insulting. I just noticed that you've had other run ins submitting digg like stuff. But the other readers have spoken, you win; I lose.
I'm not looking to 'win'. It doesn't give me any satisfaction. Just trying to understand your antagonism towards me, a stranger who just happens to ALSO be a digg user (something you seem to consider as an inherently inferior sub-species of internet people).
Hacker News is not Digg and therein lies its appeal. I love the intelligent comments here and the stories are terrific. So don't think for a second that I'm trying to 'ruin' the community by submitting digg-like content (whatever that is).
In any case, its a SOCIAL news site. Let the community sort it out with editorial votes. Wisdom of the crowds, yes?
There's no way I'm going to make everyone happy with my submissions. It's impossible. As long as its really interesting to me, doesn't violate TOS, isn't spam and falls within the general topical focus/interest of Hacker News readers, I'm going to make use of my right to contribute to the community.
I wish something like this won't happen again. If you want to continue this off-topic discussion and thoroughly exhaust your frustration, feel free to rant at me in private. My email is in my profile. Cheers.
Anyways...no frustration on my part (what about you?). I was just too trigger happy from the recent spam HN has been getting. That's all. Apologies man.
But it's not a Top Ten list. It's a Ten list. Those are fine.
I think that proclaiming the "top anything" is pretty damn annoying, but this isn't that. It's more of a "Here! We thought of some neat ideas you might like!" And I liked a good four or five of the tips.
Problem is that when you decouple interface design from system design, that's all you can do: skim the surface.
#10 provides the perfect example: how to label your dialog boxes.
Once you take a larger, more organic view, you reach a much simpler conclusion: don't have dialog boxes. Just do it and provide an Undo, and leave the user alone. Millions will thank you.
An outcome you can only reach by looking at the whole system, not just the way it looks.