For the past few months I’ve been developing three different web-based tools. All three are things that I started as tools for me, and it was after talking to other folks that I learned they might ultimately be useful for them, too. When my user base shifted from just me to a whole lot of other folks, I made a small list of rules to help me make my web tools user-friendly instead of Frank-friendly. As one of those tools nears completion, I figured I’d share my lil’ list of rules for making good web tools.
I might be plagiarizing Donald Norman, Steve Krug, or Jakob Nielsen
It might have been in the third month of me working on these tools in my off-hours that I realized that I had been peculiarly strict in following rules for design and interactions. I don’t know where those rules came from, but I actually went so far as to make a small list that I’d use to check against my work. With no one forcing me to make these web tools this way, the only thing I can figure is that I’ve picked up these ideas from some of the usability books that I’ve read.
There are three books that are the origin of a lot of my thought on usability and I’d highly recommend that you spend about $45 and get them all on Kindle. I’m sure much of what I’ve written is plagiarized paraphrased from these books:
Performing Tasks with a Keyboard or Mouse in your Web tool
1. Tasks that create or add must have equally opposite tasks that remove or subtract
It’s a no-brainer to me as an end-user, but I’ve actually overlooked this a few times as a developer. If I give the user the ability to add an input field, I need to allow them to remove it. If they can add colors to a palette, they need to remove them. If they’re able to add a table row, they need to be able to delete it.
Everything must be undoable without forcing the user to refresh the page or hit a “clear” button somewhere.
2 Equally opposite tasks should be (somewhat) equal in how they’re performed
Think of accordions or expand/collapse sections for a second. If you click once in the header to open it, you should click once in the header to close it. If you double-click in a div to change its color, double-click should change it back. If you’re using the keyboard, your ‘do’ and ‘undo’ should involve the same ‘core keystrokes’.
e.g.: control + h highlights text, control + shift + h should unhighlight it.
My guiding rule is that you shouldn’t force the user to memorize more procedures than necessary; create a single key stroke and then use variations on a theme.
3 Every task should be able to work on at least two input devices
The two input devices we deal with most often are the keyboard and mouse. We shouldn’t do anything that can only work with only one of those. Accessibility issues aside, some folks use keyboards more than others. We shouldn’t assume that our preferences apply to our users, we shouldn’t show preference to one input device over an other.
If they can’t use the Tab key to get to a field, that’s a problem. If they can click it, they should be able to tab to it.
4. Every task that works on two devices should give you feedback on two devices
This one drives me absolutely insane. Someone develops an accordion on a page, and I can’t figure out if I’ve tabbed to it, because they’ve used :hover but not :focus in their CSS. It’s equally aggravating with links or navigation that I can’t see if I’ve tabbed into the menu because it’s only written for the mouse. If you’ve used :hover, you should use :focus.
The feedback you give for a mouse should be the same feedback you give for a keyboard.
5. Think long and hard about the keystrokes you’re creating
Remember that the user has other applications and tools. Don’t go reinventing the computing interface just for your web tool. Follow the conventions that the operating system and parent web browser have put in place for keystrokes.
5.1 Global Shortcut keys are off limits
Copy, Paste, Save, Print and Open are just a few commands that pretty much work the same in every application on every computer. Those corresponding shortcut keys are off limits without any possibility of negotiation.
5.2 Shortcut keys for web browsers are off-limits
You need to research shortcut keys heavily before you make one, because you could still trigger something in the browser. Even if it’s not your favorite browser, it could be another. I’ll spend a few minutes reading through Chrome’s shortcut keys, then FireFox‘s, and finally wrapping up with IE’s keys to make sure I’m making shortcut keys that won’t burn me later. I made the mistake at one point of using ctrl + h as a shortcut. I’ll let you experiment and tell me what happens with that.
Shift is off-limits to start with; pick from at least a two-stroke combo where you’re using ctrl or alt. You need to test the key stroke in all the major browsers before you code it. Your safest bet is to assume a three-stroke combo as they aren’t used as much.
5.3 Single-keystroke shortcuts are (mostly) off-limits
People type one character at a time. We use shift as a typing aid, so it’s similarly off limits. Any time there’s any sort of typing at all, a single keystroke shortcut should not be used. If you’re creating an interface that’s extremely customized and doesn’t give the user any opportunity for typing, you’re fine; games and graphic applications will be ok with a single-keystroke shortcut.
Want an a frustrating example? Go to CSSDesk.com in Chrome and try using the sibling selector ( div ~ div). Ask me how ecstatic that makes me.
5.4 Shortcut keys should work with one-hand (and probably the left-one)
If you’ve ever wondered how ctrl+alt+delete came to be the key-combination that could reboot a computer, it’s simple: at the time of its creation, it couldn’t be done with one hand. It was meant to be a combination that couldn’t be pressed by accident. David Bradley was thinking about ergonomics, and so should you.
If a two-handed combo is something reserved for dangerous tasks, then 1-handed combos should be for the easy ones. Think about the fact that you can cut, copy, and paste ( ctrl + x, ctrl + c, ctrl + v) with only your left hand, and without it even leaving the bottom row. Do your best to let the user perform the task without taking their hand off the mouse. Since most folks are right-handed, your best bet is to create left-handed keystrokes.
Be so thoughtful with your keystrokes that they are ergonomic and favor right-handedness, but don’t forget about the mouse. Because I’m a left-handed developer, I rely more on the mouse for cut, copy, and paste instead of shortcuts; a reinforcement of the idea that you shouldn’t force keyboard over mouse.
5.5 Shortcut keys should mentally map directly to the action
The OS and the browser itself have taken all of the good keystrokes, but try to create shortcut keys that make sense for the task. If you want the user to create a new table row, try using alt + r. Are we uploading pictures? Let’s shoot for something like ctrl + shift + u. Let’s do what we can to tie the keystrokes to the action the user is performing. When we can map our actions more directly to the keystrokes, the more likely the user is to remember them.
5.6 Tell the user about the keystrokes
I love JSFiddle for this. In the bottom left corner you have an option to see all of the keystrokes that you can use. You don’t necessarily have to provide a list (though I think you really should), you absolutely must tell a user that the keystroke exists. Ever notice in your menus that they give the shortcut key next to the action? You should do the same.
Get Your Forms and Inputs Right
1. Numbers are meaningless without context; tell people what the number is
We use number input fields for lots of different things. We might show the number of columns in a table, the percentage width of a div, or just a simple quantity-ordered. If you’re showing any sort of number that’s changed by the user, or generated by the tool, give a qualifying value to the number. If it’s a percentage, what is it a percentage of? If it’s an absolute size, show pixels. Just don’t leave a number there out of context.
2. Label your inputs
Just like you should give context to your numbers, you should do so with any inputs. Put a label above or to the right. And don’t just put it in a span, either; the <label> element is specifically for form inputs.
3. Make submit buttons a call-to-action
Be specific with what a submit button does. It doesn’t ‘submit’, but it updates a table, changes colors, or saves data. You don’t have to describe what the submit button does if you’ll just explain what it submits.
4. Limits before error messages
I hate dealing with errors in code. It’s probably because I like to focus on making things work, not when they don’t. So I might follow this rule because of laziness more than anything. If someone is adding colgroups to a table, I’d rather set a limit that didn’t allow the user to make more colgroups than there are columns. If someone is entering a number that’s going to be a range, I’d prefer to set a min and max so that the user can’t select out of range— instead of dealing with what happens when they do. If you make it so a user can’t make a mistake, that’s less work you have to do in dealing with the mistake.
5. Error messages should be big, bold, and specific
Let me say this with an ‘error message’: you should distinguish between mistakes the user made and things your tool can’t do. If the user has to fill out five fields to place an order, and they didn’t, you should show a message that makes it clear that it’s your fault. But if you’ve gotten some invalid data, you should show a message that explains that it’s the system’s fault. And more importantly, you should create restrictions so that users aren’t making mistakes that goof up your code.