This post cracked me up. The follow up post to this is just as good. When I first started developing software in the mid-late `90s I bought a book published by

This post cracked me up. The follow up post to this is just as good. When I first started developing software in the mid-late `90s I bought a book published by Apple called "Apple Human Interface Guidelines". I expected it to be a very technical book, but it felt more like an 5th grade level school book with lots of cartoonish illustrations and very simple language. At first I was very disappointed. I sped through it and felt I'd learned nothing. After a few days I picked it up and went through it again. It only took about 10 minutes to read it. It explained how the GUI widgets were based on UIs that people were familiar with, like the old Radios in cars with push buttons that changed the radio station and check boxes used on printed forms and then it began to dawn on me just how brilliant that design was, and how well that book was written. So well most any 5th grader could understand it. In my own software I've been tempted to use one of the many "Icon" galleries we have to choose from now but decided not too. I opted for simple links and buttons with short but descriptive words, like "Preferences" and "New Document" and "Reports". There are icons for all of those, but my users don't need to learn what those stand for, and really don't want to. It's silly for me to expect them to learn the purpose of an icon in my app when every other app they use might implement them for a different purpose. Sometimes "a picture is worth a thousand words" is not a good thing. Sometimes just a word or two is a lot better.