From the category archives:

usability

Interfaces first

by Andrew on September 30, 2008

Don’t write spec documents, throw away any you have near you, they’re next to useless anyway. It might seem like a hearsay to some but it’s true and deep down even the most most anal planner in all of us knows it. Two of the biggest reasons for this are:

  • size and scope: In order to address every aspect of your project a full specification document has to, well address every aspect of your project and it’s going to be huge as a result.
  • lack of vision: For most people relating what’s written on paper to a vision of a design in their heads is difficult if not impossible.

Loose documents don’t work well either, because leaving the obvious unsaid just leads to problems, chiefly not everything is obvious to everyone. The devil is in the details and avoiding them until the end of a project is just going to cause trouble.

“Why haven’t we implemented x, that should have been obvious!”

create the interfaces

Prototype the interfaces and use them as your spec. Working this way has so many benefits, try it once and I promise you’ll be converted. Before you write a single line of backend code, sit down and work out your interfaces. Build each screen, put all the buttons, fields and elements on the page

I normally start with index cards and write a few simple requirements for each screen or page - just a few simple sentences listing what the page is expected to achieve.

My next step is to turn those requirements into interfaces.

in HTML, not photoshop

Photoshop is great, but let’s face it it’s no better for trying to work out a functional interface prototype than some paper and a pencil. It’s very easy to focus on making things look pretty over making them functional and you risk missing something important out.

The best way to avoid both of these traps is to write your interfaces in HTML, mark them up semantically as they will be marked up in the release and use them as your working spec.

I know good design but I’m no designer

Another benefit of coding up your interfaces in HTML before you start writing code is you can hand them off to designers so they can make them look pretty as you’re working on making them work. I have a pretty basic idea of design principals and the tools - but I find it hard work. So with interface first development I don’t have to think about it.

let the testing begin

Another thing which is made infinitely easier with interface first development is functional testing, because your testers don’t have to wait for a release before they can start developing a test suite. You are using an automated test suite aren’t you? By generating interfaces as developers add functionality testers can already have been through the interfaces and written a whole series of failing tests.

updating later

The great thing about using HTML as your design and communication tool is that when it comes to making a change to a page you have the most up to date working copy there ready to modify in the form of your site. Just save the page, add the change to the HTML and you’ve got your interfaces ready for discussion and later implementation. What could be easier, faster or more clear for everyone?

it’s not a panacea

There have been times when I’ve been working with notoriously difficult individuals where nothing was going to satisfy. An exmaple that springs to mind is a multi month project where we produced an interface design early in the project. The design was a set of PDF images not HTML (see above), but the delivered product was a pixel perfect implementation of it. Only once the project was delivered was there any input on the design or functioning of the project - I’m not just talking things that a PDF can’t show you like what clicking a link looks like. I’m taking basic things like colours, layout and the size of elements!

Would a HTML mock up have made any difference, I actually doubt it. I take blame for miscommunication and resulting mistakes when it’s my fault but in this case even after the site was fully developed and deployed to a staging area for testing none of these issues were highlighted. It was only after the site was put into production that these “critical issues” were discovered.

{ Comments }

Location services - must try harder

by Andrew on September 26, 2008

Location based services, another area where there is certainly a case to be made for someone to make it suck less and probably a number of successful application to build on it.

Why it sucks

Location services suck because it’s inherently hard to map the collection of information on the Internet to physical locations.

Most of it just wont map because it’s not about something physical.
It’s obvious, but true - most of the Internet isn’t about a place, or a thing that is likely to stay in one place. This post for example, or this blog’s homepage - neither are about anything specific. My house isn’t

It’s hard to map because language is imprecise, physical location isn’t.
When you’re looking for a nearby restaurant a blog post with a review of a restaurant in London probably won’t give you an address and probably won’t even link to a site that will. It’s become the job of search to try and link the post, a very difficult job - was the post about London, England; London in Ontario or one of the dozens of other Londons around the world. At best the search engine might be able to link the name with another URL that contains an address - but there are no guarantees the name is unique or the address is right.

Sending letters for physical addresses with an activation code is one approach Google has tried, I’m not sure how successful it’s been though - I haven’t noticed locations search has stopped sucking, so I assume it’s not the silver bullet.

Sucking less

How to go about fixing it? If I knew the answer I’d be coding the solution right now and wouldn’t be sitting her writing and thinking about it.

The rise of location aware internet devices
It’s inevitable, the rise of the iPhone, Andriod phones and other location away devices with Internet connections mean people are going to want to consume location based resources. Though they’re not the first phones on the market to do any of this, they’re game changing because they’re the first platforms that make it easy to consume and more importantly produce location based content.

The other key ingredient these platforms offer is a browser, not just a cut down browser - a real browser, with tabs and javascript and all the trimmings!

Like any good problem, this one can be solved with metadata!
We’ve got the consumers with their million plus iPhones, we’ve got the producers who all want to start geo tagging. The problem is how do we link the two and how do we make it easy? We’ve got a few standards for location tagging document, but no clear forerunner.

Suddenly it doesn’t suck anymore

Services for producers and users to announce and tie information to physical locations is going to be the catalyst that really makes local search and local information portals of all kinds take off. It won’t be long until someone comes along with a killer solution.

{ Comments }

What I’m reading: 37 Signals, Defensive Design for the Web

by Andrew on September 25, 2008

I’ve read the excellent Getting Real by 37 signals online and haven’t been disappointed by their Defensive Design for the Web. In the real world things go wrong and you can’t prevent every error, but you can handle them properly. It’s not just a book for coders or webdesginers either, I’d recommend it to anyone making decisions about site design, layout or functionality. The book covers topics from usability to copy writing using easy to follow, real world examples of websites getting it right, and other getting it wrong.

Defensive Design for the Web from amazon.com
Defensive Design for the Web from amazon.co.uk

{ Comments }

Why are bookmarks so useless?

by Andrew on September 24, 2008

I have a real problem with bookmarks. Actually I have a few problems with bookmarks: There are too many, they’re a mess, they don’t make any sense and I can’t search them. Basically they’re a good idea, really badly implemented.

I have a list of bookmarks, I try to keep them organised but there are hundreds every few months I have to go through and throw some away. The clutter in my bookmarks also leads to bad habits. If it’s something I want to read later, I drag a link to my desktop or I put it in a read later folder. These quickly grow out of hand. Then I start getting protective and avoid saving links, dooming myself to searching for them again.

Lately, using Google Reader I’ve come up against another problem - I’m building a whole new set of bookmarks in the form of starred items, except these are completely separate from the rest of my browsing but I keep doing it because it’s easy and I can search them.

When it comes down to it my problem is basically simple, I can’t ever find anything again! It’s even worse if it’s something I’ve found via searches because it might be weeks or months later I try to find the page again and it’s likely that the Google’s index will have changed in that time. So my searching for something I’ve seen gets harder.

Bookmarking the page doesn’t usually make it easier, there is no frame of reference. Unless I’ve set the title to something useful a lot of the time I find it hard to find things again because lot of the time with hundreds to go through, or I’ve cleaned it out and it doesn’t exist anymore anyway.

I’ve tried delicious and other similar tools, and I like them, tagging my links makes them infinitely more searchable. But it doesn’t go quite far enough - it still has a feeling of permanence and exclusivity to it when I tag something and I don’t always want to share everything I tag.

The other problem with social bookmarking and tagging sites is they provide a tag for me, but no context. So days, weeks or months later unless I’ve tagged the site well I may or may not be able to find it. I thought I saw a site that indexed the links from delicious, but I seem to have lost it and can’t find it again(You see what I mean!).

What I really want to see is a site that lets me star or bookmark a page or RSS feed and I want it to index my little corner of the web.

{ Comments }

There is no excuse for… back buttons that don’t work

by Andrew on July 18, 2008

The back button is one of the strongest and most pervasive conventions available to developers, yet some fail to use it correctly and see it as a burden rather than a resource. The fact of the matter is all users great and small know it’s there. From novice to expert they quickly learn to know and use the back button and taking that away from them in your application, well there is no excuse for it.

The back button has become a usability must by convention; no matter how obvious your navigation is if the user clicks and link on your homepage then wants to go back they are more likely to use the back button than to click a navigation element labelled home, your logo or any of the other ways to get to your home page.

Security, or something

A big offender here is online banking, my back button is always throwing me errors - or worse I don’t even get the address bar and navigation stuff. I’m stuck in their little application and have to use it as they dictate. I’ve heard arguments that this is to make applications more secure. Unfortunately the rhetoric is just that, hot air Not letting me do something useful doesn’t make an application more secure, it just means I’m inconvenienced. Most of the time these applications let me right click and use the context menus to go back anyway- so what’s the point?

If your security model depends on hiding or not letting me do something useful, you have more serious problems than a back button.

But back doesn’t make sense, the process has completed

The back button shouldn’t always just show you the previous page. For example if the process is an order, of course it doesn’t make sense to allow a user to step back into the ordering process and change details. Show them a page that tells them the order is completed, the details and provide useful links to modify the order - chances are if they’ve clicked back they want to change something. If not they’ll just keep clicking back till they get where they want to be.

Which brings us to our next problem…

Why do I have to hammer the back button to get back and skip some redirect page?

I really hate sites that make me do this and the worst thing is, the back button is normally completely functional otherwise. Make sure if you’re using redirects that they’re not chained so that back button use is forcing users to click it a few times to get over a hump in the process.

I give my users a link to use

Not nearly good enough. You’re in fact acknowledging a problem exists and providing a workaround, but your work around flies in the face of convention and forces users to think - usually after they’ve tried the back button on autopilot and things didn’t work out.

That’s just lazy

It all comes down to developer laziness I’m afraid. There is no reason to break the back button it’s a navigation convention all sites should encourage by default and it should always just work.

{ Comments }

There is no excuse for… bad URLs

by Andrew on July 11, 2008

The address bar is at the top of every user’s browser and it’s often totally overlooked by developers. We all know we should think a little when choosing a domain name, well mostly, but after we’ve done that normally let the our toolkit or internal organisation work against the user and clutter up the address bar with crap.

it should make sense to the user

All developers primary motivation, for the address bar as with the rest of the ui, should be something that’s useful to a user. It’s there on every browser, on top of every page of every visitor to your site. Make them short and simple, easy to see where you are, easy to remember and easy to type.

http://mysite.com/products

http://mysite.com/services

http://mysite.com/services/urls

http://mysite.com/contactus
These are all good URLs, easy to see where you are and easy to remember.

I’ve seen a number of applications or frameworks that want URLs in the form http://somesite.com/site/PAGES/EN/index.php. It irritates me just seeing it. None of that cruft has anything to do with anything a user cares about. It’s inattention to detail, it’s endemic on the Internet and there is no excuse for it.

case sensitivity

A URL should not under normal circumstances be case sensitive. Storing something at the same place with the same name only differing in case is very confusing and counter intuitive to users. Don’t do it.

http://mysite.com/HOME

http://mysite.com/Home

http://mysite.com/home

These are all the same to most users and you wouldn’t actually put different pages at each of them would you? So why not do the sensible thing for the user and make sure that no matter what case they use it just works?

The case to use depends on a variety of factors. For most uses all lowercase is probably the best default choice, however using CamelCase in a wiki, casing for adherence to brand standards or common conventions are all reasonable situations where preserving case may be the prefered option. Preserve the case yes, but don’t make the URL case sensitive.

In the 37 signals book Defensive Design for the Web [amazon.co.uk] they point out a classic from a usability best:

I typed “www.apple.com/iTunes” in my browser’s address bar but instead of information on the MP3 application, I received a “Page Not Found” error. Even though the application is called “iTunes” apple’s site only accepts “www.apple.com/itunes” (all lowercase).

This is an unfortunate branding situation for Apple. Customers are actually punished for adhering to the brand’s naming conventions

At the time of this post on Apple has fixed it, both URLs will now give you the correct page but I think it’s a great example. As well as a great excuse to link to the excellent 37 signals book. It’s worth pointing out that the apple page currently redirects to the lowercase www.apple.com/itunes url so it’s not case preserving or using the correct case to adhere to the brand’s naming conventions, but at least it works.

file extentions

Why do so many websites have pages that end in html, asp, php, jsp, .do? Users don’t care about what language you’re using, telling them is pointless and worse makes it hard for them to figure out URLs from memory or by making an educated guess. Take the time to configure your server to at the very least drop the extensions.

The exception to the rule

There are times when a file extention is important, and developers should know when to apply the above rules and when for everyone’s sake not to- when a file extention dictates the mime type, or when you’re providing a file for a user to download you obviously want to maintain the extention. There is nothing wrong with having .pdf, .exe, .dmg, .gif, .jpg, .avi, .mov etc. Most of those files are embedded, or downloaded and should maintain their extensions.

Querystrings

I hate them. I really hate them. What the is index.php?ID=123 anyway, what does that mean to me? Keep your database IDs in the database and give me something useful. Blogs get this right a lot of the time, or close anyway. Forums are notorious for getting this wrong.

A querystring is alright, if you’re running a query, a search or something similar where various parameters are going to affect the outcome. It’s not alright if you’re pulling one element out of a database. It’s alright if you’re using an API. If you’re pulling a single item and the only identifier is a numeric id you can still do better than a query string. How about: http://mysite/items/12345/

why should we care?

It seems like a small thing to worry about when you’ve got a whole application to build. The URL is like a lot of little things, it shows attention to detail. It’s easy to make them sensible if you choose to and it will make some users lives easier. The short term pain of making all your URLs sensible will in the long run improve usability- you might even retain a few more users here and there and eventually that will add up.

Take for example something like a property sales application. Let’s give it two URLs for the sake of argument.

  1. http://joespropertysite.com/PAGES/EN/SITE/property.php?ID=233223
  2. http://joespropertysite.com/property/spain/malaga/2Bed/StunningTownHouse

I hammed it up a bit on the last one to prove a point- they’re both a similar number of characters but the second is so much better even though it’s longer!

  • The second is much more user friendly.
  • The second URL is much more information rich than the fist. You’re looking at a property, on a page, on a site written in php in english - or - You’re looking at a property, in Malaga, Spain with 2 bedrooms and it’s a ‘Stunning town house’.
  • To quickly broaden a search for related two bedroom properties in malaga it’s obvious you can just remove the last part of the URL on the second. The first you’ll have to use the search function.

No excuse for… regular features on blogs

This might turn into a regular feature, I’ve got a growing list of things and there is no excuse for them. I think what I’ll do is queue them up as I write them then post them for a Friday afternoon read.

{ Comments }