January 25, 2012

Web Development Best Practices: Interface and User Exprience

Since I'm working on web applications, I've decided to read up on some best practices.  Likewise, since I have a blog, I'll simply post the culmination of my knowledge here.  I'll start by working through "What should every programmer know about web development?"

Part 1: Interface and User Experience

I've recently purchased two books: About Face and Code Complete.  The first is about user interface and program design, and the second is about the process of developing an application.  While a bit dry, the book is a good read as it thoroughly describes the user experience and the do's and dont's of application design.  And while on the subject of design, let's cover the first bullet point listed in Programmer's StackExchange:

Be aware that browsers implement standards inconsistently and make sure your site works reasonably well across all major browsers. At a minimum test against a recent Gecko engine (Firefox), a Webkit engine (SafariChrome, and some mobile browsers), your supported IE browsers (take advantage of the Application Compatibility VPC Images), and Opera. Also consider how browsers render your site in different operating systems.

As anyone who has worked with web applications can tell you, getting your website to look exactly the same on all major browsers (Firefox, Internet Explorer, Google Chrome, Safari, and Opera) is nearly an impossible task.  They simply implement things differently.  It's best not to kick yourself over this, but rather just make sure your site has a consistent feel. Even if certain things look different across browsers, it should work and be consistent within that browser.

Another thing to realize is that only are users not using the same browser as you, but they may be on a completely different OS.  It's important to understand your web demographic and what features the browsers that are used to visit your site support.  You don't want to waste days of your time working on a feature that 80% of your clients can't even use.  A good tool to find out what browser support what features, as well as the market share for those browsers is CanIUse.

Now that we've covered browsers, let's move on.  People will use your web application in ways you never intended.  People will view it on their mobile phone, they'll view it screen readers and search engines.  They'll use bastardized web browsers that were shoved into a client side application.  You need to be ready for this.  If anything, simply have your web application fail or degrade gracefully.  If you aren't able to degrade, tell the user their device isn't supported.  Be careful though, you should only be displaying those types of messages when it is truly warranted -- you shouldn't tell Internet Explorer users to get a better browser just because you were too lazy to make a workaround.

The third bullet point from that StackExchange post I quoted early has another great suggestion:'

Don't display unfriendly errors directly to the user.

If you do have to degrade, or something fails on your server, don't display the error to the user.  Give them a general error message.  But here's the thing:

DON'T MAKE THE USER FEEL LIKE THEY DID SOMETHING WRONG.

It is your fault as the developer for the failure, not the user.  In the book About Face, Alan Cooper makes the case that the user should never get error messages that make them feel as though the error is their fault.  The error messages should specifically blame the program itself for the error.  Google and a few other web applications get this right: they will display a "Oops, how embarrassing! We couldn't find the specified page!" instead of the daunting "404 Error."

0 comments:

Post a Comment