"Why Software sucks... and what you can do about it"

This happens to be the title of the book by David S. Platt that I have just finished reading. The book's web site is here.

David is an accomplished software developer and authors of many books. He has even been designated by Microsoft a Software Legend in 2002.

The book is written in a light-hearted manner with David wearing the hat of a user of software, who has no a care of the inner working of the software he is interacting with. He has provided several commonly used commercial software packages, including web applications, to illustrate his point that "you're being forced to think like a programmer, even though you're not one and you don't want to be one".

The first chapter sets out the many reasons why user interfaces are so bad and so many software are so hard to use. "Instead of the programmer adjusting her user interface to the user's thought process she forces the user to adjust to hers". He considers this lazy programming. He uses the too-frequently used confirmation dialog box to illustrate the point.

I fully agree with his assessment of the landscape. This sentence at the conclusion of chapter 1 pretty much sums up why:

They suck because they're designed by programmers, who don't realize that their users aren't like themselves.

On his attempt to explain why developer do not use tools/technique to address this problem, David has this to offer:

Unfortunately, usability testing often gets left until late in the development process, just before the product ships.... Usability testing needs to be done early, ideally before any programming takes place.
[...]
... Eating your own dog food before releasing it to users helps your dog food taste slightly better than it otherwise would. But it won't change it into cat food.

For those that scan this book rather than reading it, do not write to David to correct his spelling of Idoit. He has not made any spelling mistake throughout his book. The definition of Idoit is given on page 14 as

...idoit, pronounced ID-oyt (or eed-WAH if you're French), to designate someone so clueless that he doesn't even know how to spell idiot.

So now I have learned one new word!

He called this frequent usage of confirmation dialog box "crying wolf" and I tend to agree with him. It is a pity that he does not cite examples using firewall programs that frequently pop up this dialog box seeking users permission or denial of a transmission. I use the Comodo Firewall and it has this dialog box that pops up so frequently despise my instruction that certain software package is considered safe and trusted.

Just because a user clicks on the "allow" button does it ever make the action any safer or that the firewall is doing the job? If the user does not possess the necessary skill to work through all the highly technical information in the dialog, his action, whether allow or disallow is suspect. Even I have trouble understand the materials.

It is the duty of the program to work that out and advise! That would be a much better example of "Crying Wolf". What happen is that the user becoming so used to clicking the "allow" button just to get work done yet without much harm that he/she would do the same in the presence of a real harmful attack.

He also uses the Web to illustrate that "the web designers don't know their users, and thus they think that by extension, they must be like themselves". David throughout this book constantly reminds the developer that "Your User Is Not You". Another similar saying that I have come across is that "there are more users than developers".

On the web, he points out two very important points that are not in the desktop software packages:

"...viewing a Web site is a very casual interaction.... home page needs to visually explain this in the first two or three seconds they'll spend there before ... go to the next link in the search engine list.
[...]
... The site's navigation structure .... needs to be obvious to the user within a two- or three-second glance, and too few of them are"

I also share his objection to those distracting dancing advertisement or time wastage splash screen. Far too many web designers have been lost their way distracted by the colour & graphics!

The book also touches on issues that are not interacting with user directly but still required to serve a purpose. He examines the issue of developing secure software requiring highly specialised skill by people ill-trained for the job.

I initially thought giving a full chapter devoted to describing the Geek's habitats - the conference and in particular Tech Ed is a bit of a waste of space. I am wondering how that compares with PDC (Profession Developers' Conference). But later on I realise that he is contrasting the behaviour of Geek in groups (in conferences) with Geek as individual.

All in all, this is a very entertaining book from someone that has experiences on both side of the camp and David's knowledge as a developer is found in a number of example in offering counter-arguments that frequently are used to brush off user's complains.

I have also learned one thing unrelated to user interface design or why software sucks and that is that the backdoor to warn user of the presence of a mine in Mine Sweeper game is still alive and kicking.

If you are looking for a recipe on how to avoid making software sucks, you would be disappointed, not so much as the materials are not there but they are not organised in a recipe format!