{"id":314,"date":"2010-05-28T08:52:35","date_gmt":"2010-05-28T08:52:35","guid":{"rendered":"http:\/\/leirdal.net\/blog\/archives\/314-the-visibility-of-tools.html"},"modified":"2010-05-28T08:59:03","modified_gmt":"2010-05-28T08:59:03","slug":"the-visibility-of-tools","status":"publish","type":"post","link":"https:\/\/www.leirdal.net\/blog\/archives\/314-the-visibility-of-tools.html","title":{"rendered":"The visibility of tools"},"content":{"rendered":"

I recently discovered a link to this little gem on fundamental laws of software<\/a> from David S. Platt<\/a> who writes for MSDN Magazine<\/a>. (I want to give a shout-out to Alf K\u00e5re Lefdal<\/a> on twitter for finding the article in the first place.)<\/p>\n

David lists his three laws like this.<\/p>\n

1. Your software has zero value in and of itself. Nothing. Nada. Zero point zero zero. The only value it ever has or ever will have is the degree to which it enhances the happiness of your user in some way.<\/p>\n

2. Software can increase users\u2019 happiness in one of two ways. It can help a user accomplish a task that she wants done, such as paying her bills or writing this column. Microsoft Word is an example of this type of application. Or, it can place the user into a state he finds pleasurable. Games fall into this category, as does Skype, with which my daughters make video calls to their grandparents.<\/p>\n

3. In neither of these cases do users want to think about your computer program. At all. Ever. In the former case, she wants to think about the problem she\u2019s solving: the wording of the document she\u2019s writing; or whether she has enough money to pay all her bills, and which unpaid creditor would hurt her the most if she doesn\u2019t. Her only goal is to finish the task quickly and successfully, so she can get on with her life, or at least with her next task. In the latter case, the user wants to enter that pleasurable state as quickly as possible and stay there as long as possible. Anything that delays the start of his pleasure, or distracts him from it while he\u2019s enjoying it, is even less welcome than the interruption of a work task. My parents want to see and talk with and gush over their grandchildren. Any attention that the program diverts to itself is a negative in either case.<\/p><\/blockquote>\n

I guess that gives an excellent description of how most of us handle tools, and in the generic form he is right, but not always.<\/p>\n

I do agree with him on his fundamental laws, but there are cases where I think his \u201claws\u201d does not fully comply with the world. Welcome to Jon\u2019s corollary.<\/p>\n

There is always an exception.<\/p><\/blockquote>\n

I do believe there are tools that also give the users a feeling of brand, exclusivity or just excellence to know that they are among a select group that uses exactly this tool.<\/p>\n

I am a happy user of iPhone, but I am aware that this little device is not without faults, but there are user-groups out there that are quite vocal in their defense of everything Apple.<\/p>\n

In this case there is obviously a link between the usability\/functionality and the love of a brand, Apple probably would not have gotten their large number of fans without delivering reasonably well designed tools.<\/p>\n

But as a main rule I think David has it spot on. We as developers need to open our eyes to focusing on the users and their needs even more than we have been doing so far.<\/p>\n

I think that Apple<\/a>, Google<\/a>, WordPress<\/a> and other market leading companies have understood this and are using this to their benefit.<\/p>\n