Phil Barrett recommends Occam’s Razor to help keep complexity under control.
“Two interfaces – choose the simpler one.” A no-brainer, right? Simple designs are easier to implement and maintain, and quicker for everyone to learn and use. But choosing a simple design when you see it is actually surprisingly hard. Organisations with lots of people, objectives and agendas will generate complexity faster than you can say “knife” (or indeed “razor”).
The article is well worth a read.
Commenting on a thread on the IxDA discussion list, Jared Spool points us in the direction of this fantastic low-fi example for communicating about a rich internet application.
I certainly like the power of the stop-motion video, but as with any form of interactive prototype if it means going away from your core skills it means unnecessary time learning the tool you’re using to create the prototype.
Apple introduce the Wheel:
I am equal parts amazed and skeptical. I can’t see it catching on in the typing pool!
Are Apple guilty of going the same way as the people that designed my washing machine (Universal buttons: Now my washing machine thinks its a DVD player)?
Excellent post at Cooper Journal discussing Better ways to login.
The article goes into great detail discussing the pros and cons of issues such as what to use for a username and password retrieval. Then gives case studies of the solutions used by many leading internet sites. Then gives recommendations for the ultimate login system. To quote:
Some users genuinely prefer to use a username, others prefer email. The system should allow users to create a username or use an email address as their login ID.
Allow users to add as many email addresses as they like to their account. It gives them flexibility in communications and verification.
I like the flexibility this suggests, but I have always been a big fan of email address – it just seems the simplest solution to me (and you know I like simple!).
I remember conducting numerous usability tests on ISPs back in the day. At the time each service (Freeserve, BT, etc) required the user to create a unique username. This simple requirement often created quite a significant barrier to users continuing the registration process:
- People would get very passionate about wanting a meaningful username and would spend a long time thinking about what it should be.
- People would get frustrated when the username they wanted wasn’t available.
- People wouldn’t know techniques for how to make a simple change to their preferred username to make it something unique.
- If people can’t use their preferred username, i.e. the one they use for every other system, then they are likely to forget the username and rely upon the forgetten password process.
The article offers good food for thought and I’ll certainly consider it in more detail the next time I have to give recommendations on a login process.
This was the subject of my slightly controversial presentation of this year’s OZ-IA conference. My talk wasn’t against iterative design, but definitely in favour of early stage contextual research to fully understand the user landscape in which you’re creating a solution for.
I am sure I’ll blog around many of the topics from the presentation in the coming weeks, but in the meantime my slides can be found at http://www.slideshare.net/iain.barker/context-is-everything-from-ozia-2008-presentation.
There is also a streaming video of the presentation. The visual quality isn’t the greatest (I’m the dot on the stage). But the mixture of slideshare and the video will make it like you were there yourself!
Video can be found at http://www.ustream.tv/channel/oz-ia2008 – you’ll have to dig around a bit, I can’t give a direct URL, but I’m far the right of the second row of videos.
I just installed Mozilla Firefox 3. Rather than all the excellent new features, the thing that really struck me was that the tabs were upside-down.
I wonder why they did it that way? I can see that the tabs have a relationship to the things above and below the tab area, but them being upside-down (and thus non-conventional) makes me stop and think about the tabs rather than doing what I was already doing.
Don’t get me wrong, I am not suggesting this is going to cause “real users” usability issues. Rather I think this is something that us in the usability design community will get deeply analytical about.
I found yet another entrant for the mouse gymnastics the other day. Before the animal rescue league gets on to me, I should clarify that by mouse gymnastics I mean interfaces that require a high degree of dexterity and mouse control. As you will see, mouse gymnastics is not a good thing.
I was working on a borrowed machine. One of the start-up applications threw up (I chose my words carefully) the following interface:
Where’s the problem? Well when you move towards the close button (X), if you do anything other than approach it from the top or right, the interface expands as follows:
It turns quiting the application into a test of mouse skills. By the time I finally hovered my mouse over the close button it was a good 100 pixels higher on the screen. If at any time I overshot or moved out of the hover zone, the expander shrunk back and I had to move my mouse 100 pixels down the page to start again.
Why oh why would anyone ever design an interface in such as way? I can only guess that they saw the Apple Dock and thought that this was a good idea. But there is one key difference between this and the Apple Dock. The Apple Dock is centred and thus when magnified and expands in two directions.
Oh just to prove I did eventually pass the gymnastic test, here’s proof!
All this is before I get started on the idiosyncratic icons – Bluetooth as a CD?
Leisa Reichelt’s post On documentation (or lack thereof) rang a lot of bells for me. Until my most recent engagement, it had been many years since I’d produced a specification collating together a range of information architecture deliverables into a single formal project deliverable that was then handed over to developers for implementation.
Like Leisa, I would categorise the documentation I have produced over the last 5 or so years as “just enough” followed up with lots of collaboration. By this I mean the antithesis of thorough documentation of every aspect of an interface. Instead I would produce a series of interim materials that are enough to get other members of a project team all working towards a shared goal, and support that through face-to-face communication. (By this I mean exemplar wireframes, templates, interface rules, etc).
I think this non-formal specification approach is more in the spirit of user-centred design as it demands collaboration and facilitates iteration without the requirement to continually go back and update the documentation (surely a bugbear of more than just this IA).
To summarise, I prefer a documentation light approach because:
- It encourages and enables you to keep on iterating far later in the project.
- It makes more parties (i.e. developers) creatively engaged in the project.
- It ensures that the designers (i.e. IAs) maintain involvement in the project while it is being coded.
- It removes the temptation of focussing on your deliverable rather than the user experience of the final product. You will not be able to point at the spec and say “they didn’t implement it right”.
- It requires communication and collaboration.
- It is the antithesis of the waterfall development approach!
I am not saying no documentation, but all too often documentation is something we hide behind. Try existing with less documentation and you will have a far more collaborative project.
Modal dialog boxes, i.e. windows/dialogs that once opened must be closed before the user can continue, have always been a bit of an usability no-no.
The biggest problems being that the user either doesn’t notice the modal dialog has appeared, or doesn’t realise that it requires their attention before they can continue.
As you can see from the above example on the BBC’s site, the Lightbox technique leaves the user in no doubt what they need to do before they can return to the main window.
I haven’t yet conducted any usability testing on this kind of Lightbox dialog, but my guess is that it will test far better than traditional modal dialogs.
I see that Jakob Nielsen named the Lightbox his “interaction design technique of the year” in his Year’s 10 Best Application UIs 2008. Nice to get there before the Dane.