User Interface (UI) and User Experience (UX) are two important topics for web developers. There are plenty of recommended books on these subjects, such as Steve Krug’s “Don’t Make Me Think”, and very thoughtful work being done by the good people at A List Apart and User Interface Engineering, among many others. But even if you don’t have the time and inclination to spend hours mastering these subjects (and, sometimes, the underlying psychology involved), a decent amount of UI/UX should come down to common sense. I’ve grabbed a couple of snapshots of recent issues I’ve seen at a couple of different web sites.
Continue Reading...Archives For user interface
In this edition…
- About This Newsletter
- What Are You Thinking? => Using JavaScript
- On the Web => Amazon Silk: A New Mobile Browser
- On the Web => Steve Jobs and Dennis Ritchie, in Memoriam
- On the Blog => Why There Are Few (No?) Good JavaScript Books
- Q&A => Could You Explain File Permissions?
- What is Larry Thinking => Sexism and Bad User Interface
- Book Giveaway => “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” (4th Edition)
- Larry Ullman’s Book News => “Modern JavaScript: Develop and Design”
Some months ago, I wrote a post titled [intlink id=”946″ type=”post”]The First Rule of User Interface[/intlink]. The rule is simple: A proper user interface sets the user up to succeed. By this I mean that if the site requires certain information, or information in a specific format, that should be clearly indicated in the user interface. A site, or any application, should make it clear up front what is expected, as opposed to indicating what the user should have done only upon a failure to do so. Tightly coupled with this is my “Second Rule of User Interface”: Don’t fight the user’s habits. If the first rule could be paraphrased as “Tell the user what you expect”, then second rule could be said “Don’t deny what the user expects.”
This rule comes into play in many ways, from where navigation elements should be located, to how buttons and links behave. It also means that you shouldn’t “break the browser” by attempting to disable JavaScript features (such as Control+Clicking or Right+Clicking on an element), preventing use of the back button, and so forth. This last issue—wanting the user not to use the back button—is a big mistake. (And keep in mind that most attempts to circumvent common browser behavior can be easily circumvented by disabling JavaScript.)
Fortunately, you can have your proverbial cake and eat it, too. This is to say, there are ways to accomplish your goals without undermining standard user or browser behavior. For example, if it might be a problem if the user clicks the back button, write the site’s code to address that possibility (sessions can be used towards that end). As another example, if you don’t want the user to copy images, well, that’s a tougher one. You can use JavaScript to prevent that, but JavaScript can be disabled. You can embed the image in Flash so that it’s not directly copy-able, but the user could still take a screen shot. The fix is simple: add a watermark to the images, when necessary. With any possible example, the main idea is this: when something a user, or the browser, might commonly do could be a problem for your site, program the site to handle that possibility. Whatever you do, don’t try to prevent the user from doing something their accustomed to doing on every other site they visit. If you take that approach, all you’ll succeed in is driving away your visitors.
I was reading some articles about validation routines in Flex (as part of a book I’m writing on Flex + PHP), when I came across a particular article that’s part of the Adobe Developer Connection. The specifics of the article revolve around validation in Flex, of course, but I thought that the section on “Best Practices for Client-Side Validation” would be good reading for any one doing user interface. There are four suggestions there, all on how an application should treat the user. Those suggestions are:
- Prevent, Don’t Scold
- Give Immediate Feedback
- Let the User Work
- Innocent Until Proven Guilty
The first rule ties in nicely to a post I just wrote on putting the user in a place where they can succeed. I don’t want to waste time here re-iterating what’s said there, but give it a read—at least that part about best practices—and keep that perspective in mind the next time you go to design a user interface.
The other day I was registering to use a state government Web site. I think government sites often tend to be among the worst offenders when it comes to usability. In part this is because they’re always outdated and, I suspect, because the financing for the site was based upon meeting the government organization’s specific needs, not giving the end users what they want (generally speaking, there are exceptions, of course). This particular site had the added deficit of being developed using aspects of ASP.NET that make the site only usable for Internet Explorer (that’s acceptable? really?). So I have to dust off off my Windows setup (I primarily use Macs), just to run Internet Explorer (really?), and I go to register…
I fill out the form properly, I thought, then click submit. At that point I see a message about my chosen password being invalid because it didn’t contain both upper- and lowercase letters, plus at least one number. That’s a fine requirement, of course, but why didn’t the registration form indicate those requirements? It’s obvious that an email field needs a valid email address, but if you’re developing a site and you know that you’re going to validate a field to confirm that it includes both upper- and lowercase letters, plus at least one number, how about telling the end user that, too? So here’s the first, most important rule of a good user interface:
A proper user-interface sets the user up to succeed.
Whether you’re designing a Web site, managing a group of people, or being a parent, you have to put your users, employees, and children in a place where they can do things well. And by “well”, I mean: they can do things they way you think they should!
Conversely, I just finished doing my United States taxes, which I always do online using TurboTax. I use TurboTax primarily because the user interface is extraordinarily well done. For example, it’ll ask you a seemingly random, strange question, like “Did you roll over the proceeds from a farming operation into a non-work-related 403b?” I might look at that and go “huh?” but one great thing TurboTax does is add parenthetical notes like “This is not common.” Simple and brilliant. And TurboTax has other nice features, like indicating where you are in the process, reviewing the data you’ve entered, and so forth, but the clear messages—right where I’m focusing at that moment—make it easy for me to use the system properly.
It can be tricky for developers, who are theoretically quite knowledgeable about computers, to put themselves in the mindset of an end user, but there here is one simple way to create a successful user-interface: look at what you’re doing on the server side of things. If you’re going to check a password field for a number, put a message on the form saying a number is required. The same goes for a length requirement. If a date will be validated against a given format (like four digits for the year), have the form indicate the proper format, too. The same goes for phone numbers. If a username can’t contain a space, say as much. Set the user up to succeed instead of making them feel stupid for not doing something they weren’t told to do in the first place!
