Silverback Exposed
Since my last post people have been clamouring for more details on "Silverback":http://silverbackapp.com/, so I thought I’d explain where the idea came from, then show you a few screenshots.
Since my last post people have been clamouring for more details on "Silverback":http://silverbackapp.com/, so I thought I’d explain where the idea came from, then show you a few screenshots.
A few months ago Clearleft accidentally leaked the fact we were working on our own application, known as Silverback. I say accidentally because we had just bought the domain name silverbackapp.com and thought we’d better post up a holding page. However the combination of a great logo from Jon Hicks and an amazingly inventive parallax technique from Paul meant the page got far more coverage than anticipated. Before the week was out we had over 5,000 people registered for updates and had started to receive comments like “I don’t know what Silverback is, but I know that I want it!? So no pressure there then!
If you’re redesigning an existing site, and especially if the site is a traditional content driven site, then one of the best ways to start is by performing a content audit. The process involves going through every page on the site and noting what the page is about and where it sits within the existing navigational structure. Looking at the content from a macro level allows you to generate a clear picture of how the site is currently structured and whether this structure makes sense.
The thing I like about Jason Fried and 37 Signals is their tight focus on what they do. They are at once their own clients, customers and dev team. This gives them a great deal of freedom when it comes to features, functionality and process. However companies like 37 Signals are definitely in the minority, and most of us have to deal with much wider range of issues and stakeholders.
I've been interested in how the lessons learned from game design can be used to improve online experiences for a while now. I guess this interest started when I started learning about the concept of a "flow states". Flow is the state of being where you lose all perception of time and you flow from one successful task to another with seeming ease. It's great if you can get into this state at work as you feel "in the zone" and can get a lot done in a short space of time. Sadly the number of distraction in the modern work place, combined with the fact that we're perpetual multi-taskers, makes entering into the flow state at work a rare occurrence.
Heuristic evaluation is a technique that involves analysing the usability of a website against a set of general usability precepts. One or more "experts" will analyse the target site, often following a series of pre-defined scenarios. Whenever they encounter an issue that breaks one of the precepts or "heuristics", they will note the issue and sometimes the severity. Heuristic evaluation is usually done either to augment usability testing, or where usability testing is impractical or cost prohibitive. Heuristic evaluation is considered slightly more objective than a simple "expert review" as the results are based upon generally agreed guidelines rather than personal opinion. There are a number of different usability heuristics around, but the most popular ones on the web are Jakob Nielsen's "10 usability heuristics":http://www.useit.com/papers/heuristic/heuristic_list.html and Bruce "Tog" Tognazzini's "basic principles for interface design":http://www.useit.com/papers/heuristic/heuristic_list.html As part of my consultancy work at Clearleft I run a lot of expert reviews and heuristic evaluations. While planning a recent evaluation, I started to feel that the existing heuristics didn't accurately describe the requirements of a modern web application. In particular I felt that Mr Nielsens heuristics were somewhat convoluted, contained a lot of overlap and varied widely in terms of scope and specificity. Since Mr Nielsen first created his heuristics back in 1990, the web has changed on a lot. Many of the underlying principals remain the same, but their relative weight has shifted. So using these heuristics as a starting point, I set out to create a set of web application heuristics that better reflected the current landscape. Usability heuristics are by their nature subjective, so I don't claim what follows is a definitive list. However I have tried hard to cover as many common usability issues as possible. There is still a lot of overlap, but I think this is because one problem can the result of multiple causes. Anyway, this is just a first draft so I'm really keen to hear your opinions.