Archives For user interface

If you haven’t yet read it, this article called The $300 Million Button is well worth your five minutes. It’s by Jared M. Spool and posted on the User Interface Engineering Web site. I don’t want to give away the secret of the article, but it discusses a very common practice on e-commerce sites, and how it tests with end users.

Better HTML Forms

December 14, 2008

One of the sessions I attended at the 2008 Adobe MAX conference in San Francisco was Creating Attractive, Usable, and Accessible Forms, presented by Rob Huddleston. I went to this session as part of my current drive to improve my user interface (UI) and Web accessibility skills. In this post I’ve collected a few do’s and dont’s that I jotted down during Huddleston’s presentation. As was the case for me, you’ll likely already know some of these, some might serve as reminders of something you already knew, and hopefully a couple will make you think about rewriting some of your HTML forms today. Continue Reading…

Are you down with Poka-yoke?

December 9, 2008

One of the sessions I attended at the 2008 Adobe MAX conference in San Francisco was Web Application Development: The Error of Our Ways, presented by Robert Hoekman, Jr.. I went to this session in particular as part of my current drive to improve my user interface (UI) and Web accessibility skills. In the session, Hoekman mentioned the concept of poka-yoke, a Japanese term that means fool-proofing or mistake-proofing (see the Wikipedia entry). Continue Reading…

A reader named Max posted a suggestion in my book forums that I include a checklist of final steps to take before a Web site goes live (read his post). I don’t know if it’ll make it into a book but it’s a good idea so I thought I’d give it its due here. In this first post I’ll discuss general steps to take, regardless of the technologies being used. In a separate post, I’ll discuss PHP and MySQL specific steps; later, I’ll post for a Ruby on a Rails site.

Once you’ve finalized all the functionality and appearance of a site (or thought you have, at least), you should… Continue Reading…

User Interface

December 6, 2008

The start of my current so-called sabbatical has ended up focusing on user interface. While at the 2008 Adobe MAX conference in San Francisco I attended a couple of sessions on the topic, or on related ones. I’ll post some thoughts and notes from those sessions soon. I also took with me to San Francisco the book Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points, by 37signals. If you’re not familiar with 37signals, you ought to check them out. They’re a Web development company based in Chicago and they’re best known for creating the Ruby on Rails framework. 37signals also wrote a book called Getting Real, which discusses best practices for developing software (which applies to Web sites as well). You can buy the book through their Web site or read it online at their site for free.

Anyway, as a person that develops Web sites for a living (or part of my living, at least), I’m sometimes terribly annoyed when I find a site that doesn’t work or make sense. As a person that likes to think he knows what he’s doing when it comes to Web sites, if I can’t figure out something, I can’t imagine that the less knowledgeable person could. I think getting UI right is hard for people as it can be difficult imagining how others might use the software or site you’ve developed. I’ll provide more specific recommendations on this subject soon, but I wanted to mention this as a recent area of interest now just so you know what to expect in the next couple of weeks in this blog.

One particular idea I’ll throw out here was presented at one of the Adobe MAX sessions I attended. That speaker talked about how you should be “an ambassador for the end user”, which is a nice phrase and a good reminder. He also pointed out that while you’re developing software or a Web site for a client, they often won’t be the ones interfacing with your creation. So as a Web developer, you need to hit the mark between giving the client what they think they want and giving the end user what they really need.