Today’s question: Is bigger better? Well, the answer is: it depends.
No one likes that answer, but the point is this: your site or application needs to have a visual hierarchy. The most important parts of your site need to be the most prominent. Steve Krug talks about this at length in his book Don’t Make Me Think — you must buy this book!
This, of course, assumes that you know which should be most prominent. That’s why small focused web apps are sometimes easier to use than large scale corporate projects which often experience death by committee.
How do you make something more prominent? There are many ways, but four in particular I want to highlight: size, placement, color and contrast.
Size: This is where bigger is better. If you want to call attention to something, you can use size. Don’t make important text microscopic.
Placement: Consider where your users will be looking. Important information goes here. Also, don’t be afraid of conventions! People typically look at the top left of your page. Generally, login information or search fields go top right.
Color: Vibrant colors tend to attract the eye. Used well this can come in handy; abused and you’ll run your users limited supply of patience dry.
Not only does your site need visual hierarchy; it also needs visual organization. Like items should be placed together. People shouldn’t have to wonder what is what on your site. Headers, proportionate sizing and structured layouts help accomplish this.
Well-defined sections mean well-organized thoughts. Busy can be deadly. You must learn what can be moved to sub-pages. Come up with creative ways to clean up your pages while still making information readily available: use javascript to create dropdows and expanding text.
In short, don’t make your user do your thinking for you.
Due to several large, last-minute projects that sprung up, I haven’t been able to film any new PMTV episodes. To help slake your thirst for updates, I’ve recorded several hours of design work and boiled them down into this one minute, thirty second video to help you get a better idea what my design process looks like. Check out the final logo.
Ok, so the principle is simple. When you’ve got something that really needs to stand out, up the contrast from the bg element. But it’s not the extremes that people have a problem with, it’s the “gray” areas (literally).
Now the W3C has come up with a formula to determine the difference and brightness between your colors:
Color brightness is determined by the following formula:
((Red value X 299) + (Green value X 587) + (Blue value X 114)) / 1000
Color difference is determined by the following formula:
(max (Red 1, Red 2) - min (Red 1, Red 2)) + (max (Green 1, Green 2) - min (Green 1, Green 2)) + (max (Blue 1, Blue 2) - min (Blue 1, Blue 2))
And if you’re like me… that just went right over your head. Fortunately there are a lot of great tools out there to help:
GrayBit: Convert full-color web pages into grayscale to test the perceived contrast.
AND NOW ON TO THE CONTROVERSY: Body text, should it be dark on light or light on dark? I’d love your feedback on this… is light text on a dark background hard for you to read? Is dark text on a light background better?
Join us Monday as we consider the question: Is Bigger Better?
Believe it or not, one of the fundamental goals of interface design starts with the Golden Rule. Luke 6:31: “And as you wish that others would do to you, do so to them.” Treat others the way you’d want to be treated.
Think about some frustrating things in life: traffic jams, calling customer support, waiting up for your teenage daughter to come home, doing ANYTHING with the insurance companies, doing ANYTHING with the government. Each of these situations have their own unique set of frustrations, but they are ALL compounded because of a lack of information. If you knew the traffic jam would clear up in 20 minutes, you’d still be frustrated at the waste of time, but at least then you could make phone calls saying you’d be late, perhaps get off an exit and take a different route. If your teenage daughter called and said the movie went long, you may still be frustrated with the fact she broke curfew, but at least you know what’s going on.
We all want to know what’s going on, and your users are no exception. The crazy thing is that Jesus’ words were actually in the context of loving your ENEMIES. Now some of you TREAT your users like enemies, but these are the people you’re trying to help! How much more should you treat your users with respect and courtesy.
Now I’ve got to spell this out explicitly because I’m afraid there are some developers who agree with this in theory, but don’t get it in practice.
Let’s talk examples. I’ve already mentioned the Wii remote’s subtle rumble when you hover over a letter. Good example. How about Twitter? When you’re typing in a tweet, there’s that handy Javascript-powered character count that lets you know when you’ve gone over 140. It even changes color as you approach the limit. That actually reminds of an example how NOT to provide feedback: Twitterrific. Instead of telling me I’m over letting me pare it down, it won’t even let me have more than 140 characters in the field at any given time, making editing a real nightmare. I much prefer Twitter’s grownup approach: hey, you’re over, if you submit it’s gonna get truncated.
Anyhow, back to the issue at hand. If you’re about to do something that’s going to take a while, let them know. Better yet, do it in the background. That’s one of the great things about AJAX. Instead of forcing the user to wait for the computer to work, AJAX lets it happen in the background while the user keeps working—Google Maps is a great example of this. Drag and it loads the images in the background while you’re busy looking at the map.
And be aware of the limitations of your technology. If you’ve got a blog on a slow server, put in a script that disables the comment post button once you click it and puts up a message that the comment is being processed. That way your user doesn’t keep clicking and wondering what’s happening.
See, that really is the point. With computers, a LOT of things can go wrong. There’s just so many small frustrations that people deal with: accidentally dragged your file to the wrong folder, an application quit unexpectedly, the website you tried to load didn’t come up, you misspelled a domain name, your monitor has a dead pixel, your webcam has a green line through it. So while your discourteous app may not seem like a big deal, you ultimately have the potential to add to your user’s happiness or take away from your user’s happiness.
And you can start making them happy by letting your users know what’s going on.
Today we springboard from our discussion of metaphors from yesterday. Metaphors are important because they take complex concepts and present them in an approachable way. So in that light, it’s important for developers to think outside the box, literally.
When 111 Is Less Than 110
The 1-1-1 phenomenon as described by Bruce Tognazzini in his fantastic article on principles of interaction design.. Turns out 1:11 takes less time to punch in on your microwave oven than does 1:10; so the extra second you gain is actually offset by the time it takes take to think about and press that extra 0. Better still: the quick minute button!
An Easier Way To Mii
Creating a Mii on the Wii… start from scratch or choose a look alike? This option costs more hours of development and design, but certainly helps those who have trouble creating a caricature of themselves from scratch.
Keeping Your Options Open
While you can inundate your users with too many options, letting them take two paths can be really beneficial. Give them the choice between a quick simple solution and the more complex, customized solution. More on that in Episode 21.
If it’s a common function with a widely accepted metaphor, use it (or a variation of it). Some standard examples: Save (disk), Print (printer), Search (magnifying glass), Comment (speech bubble), Attach (Paperclip), Play (arrow/triangle). How do you find out what’s commonly used or accepted? Google Image Search for your action + “icon”. Some icons that aren’t quite as standard: junk mail, new document, download.
New metaphors:
When creating a new metaphor for a unique function in your app, find something from the real world to compare it to, a relevant metaphor and then use it consistently. Examples: iPhone scroll, OS X Coverflow.
Don’t be afraid to use all of the senses. Examples: iPod click on rotate, Wii remote rumble when hovering over letters.
Don’t forget the text:
Be concise. Eliminate unnecessary action words! e.g. Create Shape vs. Shapes. The more clutter that’s in there, the more they have to process.
Today we kick off a new two-week series that will focus on key design principles for developers. Today is just the overview; we’ll go through one of these each day for the next two weeks so make sure you join us for it!
10. Anticipate your user’s expectations. This means knowing your users. Testing, surveys and analytic software are good ways to discover who your users are. (Silverback) But there are some fairly common expectations that are good places to begin. Buttons should look like buttons, clickable links should be distinct from standard text. Part of this is using common metaphors in your icons (GUN = DELETE). The goal is for your interface to get out of the way and let the user succeed. There’s a place for being unique and original, but when it becomes a impediment that keeps your users from being able to use your tool well, it needs to go.
9. What’s easiest for a developer is not always what’s easiest for a user. This is often hard because one of the key jobs for a developer is efficiency within a program. But this means “thinking outside the box”, literally. Efficiency in phone software says you take the numbers a user inputs and dial them. But if you think outside the box, what about the frustrating repetition of entering the same number day after day? Reducing the act of remembering and pressing ten digits along with the send key down to a single, assignable “quick dial” button takes more development, but it enhances productivity.
8. Feedback, feedback, feedback. Tell your user what’s going on. If you’re going to make them wait, give them an hourglass, a throbber, a spinning beach ball—something to indicate that the application is working and that their input has been received. * And when a task is complete, let them know it was successful in a very obvious way (common metaphors: check, green, thumbs up). If it fails, let them know that as well (common metaphors: x, exclamation point, red or yellow, thumbs down).
7. When it comes to readability, contrast is your friend. Non-essential elements like form labels or toolbar headers where users could probably infer what data is there from the context can afford being less readable. Black text on a white background is especially important when your users will be reading lots of text or entering data.
6. If it’s more important, it should be bigger. This of course requires you to have an “interaction hierarchy” for your application. That’s a big fancy term that means you have a plan for how you want users to use your application. In fact, one of the reasons small, lightweight web apps have succeeded in this area while big, bloated suites have fallen by the wayside is because web apps are often put together by individuals or teams of small, focused, single-minded groups that share the same vision and purpose for an app. The larger suites often fall prey to bureaucracy (death by committee) and this ambivalence of purpose comes out in the design. For blogging software, creating a new post is the most common/important task, so it needs to be prominent: larger font, contrasting color, etc. (Don’t make me break into “I like big buttons and I cannot lie.”)
5. The most common tasks should be the easiest to accomplish. In fact, the default settings should be what 90% of your users will want and if you’re going to allow people to change them, make it easy to. Forms — tab index, default values. Install or upload paths — customizable defaults. Also make it easy to get back to the initial settings.
4. Help your users get oriented. Your users should know where they are at all times. There are several visual tools you can use to help users get oriented: tabs, breadcrumbs, “current state” menu items. If your application or website requires a login, remind people of the state. Are they logged in? How do they know? How do they log out? And a good way to test this is to have people not familiar with the software site down and try it out.
3. Be forgiving. Your users are not stupid, but they may be uninformed, confused or mistaken. You’ve done everything you can to eliminate this confusion, but you also need to protect them when they do make a mistake. This has a LOT of implications from an interaction design standpoint: undo, autosave, error checking, spell-checking; but this principle applies to visual design as well. Actions that have the potential to do more damage should be clearly marked (without slowing users down). Getting back to “the way things were” should also be clearly marked so users feel more comfortable to explore. Alienating users when they make a mistake is the quickest way to lose them.
2. Be consistent. Consistent placement of controls, consistent keyboard shortcuts, consistent branding. The only exception to this rule is when dealing with things that are different. Make sure that different functions are sufficiently inconsistent; the greater the difference between their function, the greater visual distinction you need between them.
1. What your application can do is not nearly as important as what users do with your application.
Jesse Gardner is the grand poobah of Plasticmind Design. This show is where he comes to talk about design and technology and to help you get better at sharing your ideas with the world. Be sure you sign up below to get notified when new shows are posted! read more...
![[+]](http://plasticmind.com/img/expand.png)
