The Design of Everyday...
I brushed off my copy, it actually was dirty, thanks to my recent move, of The Design of Everyday Things and reread it over the weekend. I have the 1990 edition (white cover).
For those who have not read this wonderful usability tome, it discusses how difficult it is to use things that used to be simpler to use, before they became sophisticated. One of Donald's favorites is the telephone, to whit he devotes about 10 percent of the book's pages to. The reason for the frequency? We use telephones everyday and its uses are well known, however the usability among different designs varies wildly. Some examples reveal the book's age; this may have changed in the 2002 version, but I do not know for sure. For example, one reference is to computer passwords that must be at least six characters long and contain no words. Now, passwords must be at least eight characters containing a mix of lower and upper case letters, numbers, and some special or non-printable characters!
After reading this book the first time, I was a usability "guru," or so I thought. I walked around for the next two or three weeks pointing out bad usability design (in manufactured objects, not software) to myself or to anyone else unlucky enough to be nearby. I felt like starting my own usability company and making some serious dough pointing out such deficiencies! Of course, these were only things that were unusable to me, not necessarily everyone else.
This time is different, however, probably due to significant experience in a career as a software developer. I am struck that pointing out the usability issue is not the important part. The important part, especially as it applies to me as a software developer (WIIFM), is the asking of "why?" Asking why works really well in improving my understanding of such immense class libraries and hierarchies as the .NET Framework. Why did the designer choose to do this? Why was the API structured like it is? Are there advantages to doing things this way? How does it make developing easier on me? If it makes certain things harder to do, are there other parts of the Framework that make it easier to do those things another way? And with the ever-increasing size of .NET, I need all the help I can get!
So, unlike the slogan for the [now defunct] Bud Dry product, "why ask why?", actually ask why!
Bud Dry and its slogan are probably trademarks of Anheiser-Busch corporation.