Cooper explains why a lot of modern software (and the devices it runs on) is hard to use. He lays the blame largely at the feet of software developers and their perverse mindset and habits. He mentions Po Bronson’s funny-because-true characterisation of software developers, which includes;

• They’ll keep fixing what’s not broken until it’s broken
• “I didn’t answer incorrectly, you just asked the wrong question”

I heard Jared Spool talk about this book recently. Apart from calling it a classic, he said that he was uneasy about its “us versus them” undercurrent. I agree — Cooper presents caricatures of software developers and says that the interaction designers need to ride in on a white horse and rescue the project from these strange deluded people. But developers generally are not that bad! Maybe things were worse 12 years ago when he was writing the book, though I was a developer then and I didn’t encounter such extreme people. Maybe I’ve just been lucky.

I do like Cooper’s focus on goal-directed design. Don’t focus on people’s tasks — instead look at their goals. You may be able to come up with a different set of tasks that allow people to achieve their goals more easily. And don’t think that giving people more choice makes things easier! “Choices are not all that desirable, and being offered them is not a benefit, but an ordeal.” Barry Schwartz has explored this idea more fully in his excellent book The Paradox of Choice.

I also liked the subtle analysis of Microsoft Explorapedia — a product that shipped on-time and made money, but still should be considered a failure. It failed because it was much less usable than the paper encyclopedia it was meant to replace. I think it’s useful to draw this distinction between a product that succeeds in making money, and a product that succeeds in actually being good.

He gave some insights into what went well and what didn’t about the campaign. In a sharing campaign like this, it’s important to clarify exactly what is being shared. Is it the beer token? Is it the beer itself? Or is it the get-together with friends to go to the bar to get the beer? He said a bit more thought in this area would have improved the participation level. He referred to Social Object Theory and posited that FaceBook’s Live Stream is its social “Supersoul”. This may fit in with the theory’s concepts, but the thought that FaceBook has a supersoul just makes me want to throw my computer out the window.

On the technical side, they put their app in an iframe instead of using FBML, FaceBook’s markup language, because FBML was not quite flexible enough. But he recommended using FBML if possible because it is continually improving and it’s a lot easier than reimplementing all that functionality.

There was so much in the talk that he was only half done when his 45 minutes was up. I would have stayed for more but I had another session to rush to.

In another room there was a session on workflow automation. Judging by the tweets, this looked brilliant. Glen Barnes talked about this topic which is very close to my heart — I have long thought that this is what computers are for, dammit! I’m very happy to see that his presentation is on his blog now: Doing Less. Using SaaS and APIs to automate your workflow.

At work, are you relaxed? Creative? Fulfilled? Finding time within work hours to pursue creative endeavours or self-development with the idea that it will feed back into your work and make you better at what you do.

Carol Green led this discussion at Barcamp Auckland 4 about using work time to do essential but non-billable experimentation and research. I was impressed at the way she shrugged off the computer failure that stopped her using her slideshow. Instead she just talked us through it and inspired the whole audience to share their experiences. Very Barcamp. Fortunately her presentation is available on her website. It looks great, and bonus points for using Gill Sans. (Or maybe not, if Eric Gill got it wrong.)

The idea or inspiration came from Illustration Friday and The Sketchbook Project, two attempts to give structure to these sorts of personal/non-billable projects. I thought this was most relevant to freelancers such as self-employed designers. I am none of these things, but I still got a lot out of the session. The main point I took away was that I now want to be a freelancer.

If I hadn’t gone to this session I would have gone to Vinyl Flashbacks: the glories of LP cover art, and how Steve Jobs nearly destroyed it presented by Peter McLennan. I saw his collection of LP sleeves later and they looked just stunning.

Twitter is awesome for conferences. I tweeted interesting points from the sessions I attended, but I also regularly checked the #bcak4 hashtag to see what was going on in the other sessions. In some cases I missed bits of what the presenters said, but caught them a minute later as the person sitting next to me tweeted them. And I wasn’t the only one who noticed the rain on Twitter before I saw it outside the window.

The tweets really added a lot to the sessions. There were a handful of Twittering heroes there. A few times I heard a presenter mention some project or document, and within 60 seconds @vickytnz would tweet the reference along with the URL. Awesome.

There is a great web-design-media-etc. community in Auckland. I mean, of course there is — Auckland is big and hip enough — but I haven’t been exposed much to it before. I’m starting to recognise a few names and faces too. Now I want to get more involved.

The sessions I saw were a good mix of tech, design and social issues. This reflected the mix of geek, design, and strategy people I’ve encountered at Auckland Web Meetup, Auckland UX meetup and other groups. I’ll write more about the individual sessions in separate posts under the Barcamp tag. I was hoping to do them all today but given my usual blogging speed I will be lucky to write them all up within the week.

The book includes good discussions of personas, user-centered design, user testing, wireframes, prototyping and more. There’s also a strange chapter on search engine optimisation (SEO). Why? SEO has nothing to do with the user experience, even though there are certain techniques that enhance both (such as descriptive link titles). The chapter feels as if it has been bolted on, probably because it has: it’s the only chapter in the book not written by the authors. From a UX point of view, you only need to read one line from the summary: “Thoughtful search engine optimisation starts with quality UX.”

For its size, I can’t imagine a more thorough summary of UX practice.

Here’s my interpretation of the laws:

Thoughtful reduction yields simplicity.
Organisation makes complex systems appear simple.
Savings in time feel like simplicity.
Knowledge makes everything simpler.
Simplicity and complexity need each other.
Simplicity needs a sympathetic context.
More emotions are better than less.
In simplicity we trust.
But some things cannot be made simple.

Regarding the law of Trust, Maeda points out that shopping is simpler when you know you can return your purchases, since you can spend less time choosing. But that doesn’t avoid the choosing, it simply moves it. When you get home you have to decide whether you’re going to return the purchase, whether you perhaps should have gotten a larger size, or a different colour. Barry Schwartz, in The Paradox of Choice, argues that things are simpler overall when your choices are irreversible.

The tenth law of simplicity (which Maeda calls “The One”) is beautiful:

Simplicity is all about subtracting the obvious, and adding the meaningful.

This reminds me of the artist Hans Hofmann:

The ability to simplify means to eliminate the unnecessary so that the necessary may speak.

There are some interesting anecdotes and worthwhile points, but they didn’t seem especially coherent to me; the book rambles a bit. Maeda closes with some final musings, loosely organised into three more laws (called “keys”). In the last one, about the power of constraints, he confesses that he is typing with only 14 minutes of power left on his laptop. Maybe if he had a bit more time he would have written a simpler book.

The Cult of Next Manifesto

1. There are three states of being. Not knowing, action and next.
2. Accept that everything is a draft. It helps to get to the next thing.
3. Done is not enough.
4. Pretending you know what you’re doing is almost the same as knowing what you are doing, so just pretend you know what you’re doing and go to the next thing.
5. Banish procrastination. If you wait more than a week to get an idea done, go to the next thing.
6. The point of being done is not to finish but to get to the next thing.
7. Once you’re done you can go to the next thing.
8. Laugh at perfection. It’s boring and keeps you from the next thing.
9. People without dirty hands are wrong. Getting to the next thing makes you right.
10. Failure means you can go to the next thing. So do mistakes.
11. Destruction means you can go to the next thing.
12. If you have an idea and publish it on the internet, you can go to the next thing.
13. Next!

This was prompted by The Cult of Done Manifesto.

1. There are three states of being. Not knowing, action and completion.
2. Accept that everything is a draft. It helps to get it done.
3. There is no editing stage.
4. Pretending you know what you’re doing is almost the same as knowing what you are doing, so just accept that you know what you’re doing even if you don’t and do it.
5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.
6. The point of being done is not to finish but to get other things done.
7. Once you’re done you can throw it away.
8. Laugh at perfection. It’s boring and keeps you from being done.
9. People without dirty hands are wrong. Doing something makes you right.
10. Failure counts as done. So do mistakes.
11. Destruction is a variant of done.
12. If you have an idea and publish it on the internet, that counts as a ghost of done.
13. Done is the engine of more.

Lots of people got excited by this manifesto’s dynamism and go-getting attitude, but I was disturbed by visions of these dynamic go-getters blazing ahead and leaving a trail of half-”done” projects in their wake for people like me to fix.

I can see the appeal — the manifesto has an air of Futurism about it. “The Futurists loved speed, noise, machines, pollution, and cities; they embraced the exciting new world that was then upon them…”

That’s the problem with the Cult of Done. It’s really about doing, not about getting things done. A real Cult of Done would emphasise finishing things properly so they really are done. The point of being done should be to finish, not “to get other things done”. If you really just want to get other things done, you’re not actually interested in “done” at all: you’re interested in “next”. Hence the Cult of Next.

RJ Owen is also uneasy about it: Don’t Join the “Cult of Done” – Stop Overcommitting.

While there’s a lot to like about the manifesto, it’s not something to base your work habits on. I certainly don’t — it took me almost a year to get around to writing this.

• Duplicated recent searches are shown only once in the Recent Searches plugin
• You can now specify a list of filter words. Any searches containing these words will not show up in the recent and popular search widgets, even if the searches were successful
• Search links in the widgets will work correctly whether or not fancy permalinks are enabled
• The blog administrator can decide who is allowed to see full statistics: all logged-in users, authors and administrators, or administrators only

This version of Search Meter requires WordPress 2.3 or later. If you are still using an older version you should probably upgrade anyway, otherwise you can always use an older version of Search Meter.

Let me know how the new features work for you. If you have any comments or questions, just add a comment to this page.

The operation that the SVN manual refers to as “tagging” is actually implemented by copying the “tagged” tree to a “tags” directory. But this isn’t really a tag. The original tree is unaffected: looking it it there is no way to tell that a tag was made.

That’s because a Subversion tag isn’t really a tag. It’s a snapshot: a copy of a tree at a particular point in time. This fulfils one of the main use cases for tags (reverting to or comparing with a specific release), but there are some problems.

First, you can’t easily find all the tags that have been applied to a tree or a file. You have to look at all the tags and determine what tree and revision they were copied from.

Second, a tag is just like any other directory tree; in particular, it can easily be modified, even accidentally. But a tag that can be modified is worthless.

I find it helpful to think of SVN “tags” as snapshots. It leads to a better intuition about how and how not to use them. This is especially useful when also working with other revision control system that implement real tagging.

I wish Subversion had implemented tagging more like Git, where a tag is simply a reference to a particular commit. Subversion could have implemented tags as, say, a path (like “/trunk” or “/branches/release-1″) and a revision number. These could be stored as metadata at the repository level, making it simple to manage them and match them up to revisions. And with tags tied to revisions there would be no way of accidentally changing a tagged tree.

I don’t suppose this feature will ever make it into SVN. Part of the reason is that they would have to come up with another name, since “tagging” is already taken by their non-tagging snapshot feature. So now SVN users think they know what tagging is, and people coming to Subversion from other version control systems end up being confused. If only the SVN team has had thought more about tags and snapshots then Subversion could have been a better system.

Ensure each page has a clear title. Almost everything else follows from that simple rule.

Focus each page on a single task. A screen is focused on one purpose if the designer can express that purpose with a concise, meaningful, and natural-sounding screen title.

Title each screen with a concise and explicit statement of its primary task. This can be a direct instruction (”Select the account you want to balance”) or a question you want the user to answer (”Which account do you want to balance?”). To write a page title, designers imagine a friend asking, “What is this screen for?” and then come up with a clear, helpful response that completes the sentence “This is the screen where you…” The words that complete the sentence become the screen title.

Optionally include a brief descriptive paragraph at the top of the screen. Even when a title is carefully chosen, the title region may be too small to adequately explain a complex task. To alleviate this problem, you can include a brief descriptive paragraph at the top of the screen’s content area that elaborates on the task.

If the screen title is clear and simple, designing the screen is usually straightforward.

Provide a clear exit from the page.

I remember back when I first saw Microsoft Money 2000, I was struck by how much it looked like a web site — screens looked like web pages, and UI controls looked like web controls. They had simplified the interface so it felt like a website. At the time I thought this was the way of the future: desktop apps would start to look like web apps. Actually I wasn’t exactly right: what’s happened is that desktop apps have been replaced by web apps.