The Amazon Kindle app for iPad changes its background depending on the hour of the day. It even has some very nice effects, for instance, when switching to the night view, a falling star flies by.

Small details and nice polish shows your users that you care. Don’t be happy when it works, go the extra mile.

Arrow towards door: fails, arrow pointing away from door: door opens (click for full size)

Whoever made these things needs to re-read his usability 101 book.

Except it doesn’t work…

Communication error! Try again later!

More often than not, you get a nice error dialog informing you that there was a communication error.

After much cursing today, I discovered that it turns out there’s nothing wrong with the communication. Whoever built this things was simply too lazy to add decent error warnings [1]. In my case the recording couldn’t be scheduled because there were too much overlapping recordings.

Building decent error reporting isn’t fun, but it is crucial to make a usable product. Whenever you’re writing software, ask yourself the following question: “Am I helping the user to solve the problem when things go wrong?”. Just don’t be a lazy bum and blame it on the communication.

[1] Or more plausible: Had to skip it because his superiors wanted to ship the thing before it was ready.

Visions and goals
A couple of weeks ago I inherited the maintainership of F-Spot. One of the first things I wanted to do was to set out a new direction for F-Spot, to get the development momentum going again and to reconsider our assumptions. F-Spot has a lot of nice and not-so-nice aspects, it’s time for us to set the goals high, be ambitious and go from good to awesome.

While speaking about this with Peter Sikking (interaction architect and over here probably most known for his Gimp UI design work), he correctly noticed that we should have a clear vision first before redesigning things. We sat down and started working on this.

Maybe working isn’t the right term here: working with Peter means having an enjoyable chat where he asks you a couple of questions, which gradually help you crystalize the vision. At the end he grabs his laptop, spends fifteen minutes alone typing and out comes a great vision statement, which neatly sums up what I had in mind:

F-Spot is a cross platform application for organizing thousands of photos. It shuns ‘organizing in folders.’ instead, metadata is the basis for viewing and drilling down the collection. Adding and maintaining metadata is easy and enjoyable in F-Spot.

Individual photos can be retouched and globally corrected (e.g. dynamic range, color), for sharing via the net, printing and viewing by consumers. The number and sophistication of the correction scales to the the ambition of users. An advanced form of corrections is that of batches of photos.

Beginners in the digital photo field can easily start using F-Spot. These and more advanced users are encouraged by F-Spot to grow their skills, to the point where they integrate more specialized photo manipulation software into their F-Spot workflow.

The key ideas here are usable for nearly anyone, yet powerful for those who want it, with a gradual path to grow from beginner to advanced photographer. This vision will serve as a test for all new features: what doesn’t fit in won’t get in.

Spend some time doing this for your project, it will greatly help your project. I highly recommend Peter to anyone that considers working with him.

Interaction architect Peter Sikking

Design, user interface and maintainters
The next day I sat together with some of the great designer heroes of our GNOME community: Garrett LeSage, Jakub Steiner, Hylke Bons and Andy Fitzsimon. Together we started thinking about how we could redesign the user experience of F-Spot. There are no showable results yet (aside from some paper sketches), but I am very impressed with what came out of this session: a clean and powerful experience for organizing photos. Best of all: it’s not the obvious programmer solution. Having designers in the conversation (in this case a lot of them) allows you to think beyond the obvious. It brings in a lot of design creativity which we developers sometimes lack.

Hylke made a very correct observation: every project should ideally have a code maintainer and a design maintainer. I’ve come to agree with this.

Jakub Steiner (jimmac) working on awesome designs.

Take-away points
What to take away from this:

• Get the goals and vision of your project straight. This greatly helps the focus and makes it so much easier to make decisions.
• As a developer maintainer, talk to designers, they will make it so much better. This is often a problem, where maintainers see their projects as their pets. Letting someone else co-decide on the design won’t diminish your merit but it will often greatly improve your project.
• Credit in open-source projects is usually given based on code contributions / documentation / translations. We need to value design more and show them love too.

Fortunately, most of these points are already common practice in parts of the GNOME community.

As for the changes to F-Spot: these are coming, along with massive improvements (in terms of performance, code quality, stability, etc). That’s the subject of another blog post in the near future though.

Could we please have a GNOME usability hackfest every year or so? The magic that comes out of those is awesome.

That will be all.