Archives For ui

Recently, and I can’t remember why, I came across Yahoo!’s Design Pattern Library. Just like a programming design pattern describes, in code, an accepted way of handling a specific task, this library has almost 60 (at this time) examples for how to layout and handle common visual elements.

The patterns are organized by category: layout, navigation, selection, rich interaction, and social. For example, there’s a pattern for showing the availability of a person (like you’d see in IM) and another for how breadcrumbs should be used. Mostly the patterns are descriptions of what you should do, based upon what’s best for the end user. Many of the patterns do have links to code examples, although those will often make use of the Yahoo! User Interface library.

Part of the design pattern library is a stencil kit, available for OmniGraffle (the program I use), Adobe Illustrator, Visio, and other applications. Using this kit you can quickly create a mock-up of the user interface. And being Yahoo!, all of this is available for free.

I StumbledUpon this article titled Making a Cool Login System with PHP, MySQL, and jQuery. It’s very slick, with a panel that slides down for the users to login or register. The article includes the complete code and a demo version. I like this approach—a separate login panel—because logging in is common to most sites but also something the user only does once per session at most, so it’s best not to take up screen space with a login form.

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 recently StumbledUpon BumpTop, a commercial product that greatly changes (dare I say “revolutionizes”?) how you use your computer’s desktop. It runs on both Windows and Mac OS X and is quite reasonably priced. The best way to get a sense of BumpTop is to watch the videos available at their site. It’s just cool.

Validation Suggestions

March 13, 2010

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:

  1. Prevent, Don’t Scold
  2. Give Immediate Feedback
  3. Let the User Work
  4. 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.