Thunderclap, the Newsletter of Rolling Thunder Computing

Volume 5, Number 1 Fall 2002

In this issue:

Feature Article: Know Thy User

Blatant Self-Promotion: Public Class on ACORD XML in NYC, Boston and San Francisco, Public Class on .NET for the Insurance Industry,  In-House Training Classes on ACORD XML and .NET

New Book: Second Edition of Introducing Microsoft .NET

The Internet Chuckle: Tuesday Morning Quarterback

Annabelle's Latest

Subscription Information

Feature Article: Know Thy User

In this issue, I want to depart a little from my practice of writing hard-code programming articles and do a little ranting about the absolutely TERRIBLE user interfaces I've been seeing lately. Is it only me, or have they gotten worse, by an order of magnitude?  With .NET, programmers have all kinds of tools with which to write user interfaces, on the Web or with rich clients on the desktop.  And most of them SCREW IT UP ROYALLY!! The UIs are cumbersome. They're cryptic. They require a user to think like a computer, not the other way around. They're just plain stupid.  

How do they get this way? Programmers have to have a certain level of intelligence in order to program, and most of them are at least somewhat smart when dealing with code. How can they be such lobotomized morons when designing a user interface? One simple reason: they don't know their users. And it never occurs to them that they don't know their users. Every programmer thinks he knows exactly what users want. After all, he uses a computer all day, he OUGHT to know.  He says to himself,  "If I design a user interface that I like, the users will love it," 

WRONG, TURKEY! You don't know what the users want, because you're not one of them. Your user is not you. Write that down. Engrave it on your heart, along with F = MA (any physics majors in the audience?) and "always cut the cards". Your user is not you. Your user is not you. Unless you are writing programs for the use of burned-out computer geeks, your user is not you.  Here is Platt's first, last, and only law of user interface design. Get it right, and you can't screw up too badly. Get it wrong, and your product is guaranteed to bomb:

Know Thy User

For He Is Not Thee

Here's an example. Every time I teach a class at a company (How about yours? Call me at 978-356-6377.), I ask the class how many of the students drive cars with a manual, stick-shift transmission (as I do). I usually get about half the hands. I then ask how many more WOULD drive stick shifts if their wives would let them, or if they came on the minivans (like my next car, probably) that they need to drive because they're turning into old farts, curmudgeons like me. I usually get about half the remaining hands. (Try this test around your company and tell me what results you get.) "Now would you not agree," I ask, "that driving a stick shift takes more work than an automatic to learn and to use, but gives somewhat better performance, flexibility, and efficiency ?" They know they're being led somewhere they don't want to go, but they can't usually wriggle out at this point, so they agree suspiciously. "Now, what percentage of cars do you think are sold with stick shifts in the US?" They wriggle uncomfortably and say something like, "I bet it's low. Thirty percent?" You wish. Sales estimates vary, but automotive correspondent Tom Whitehurst, says roughly 10% at this link here, and Edmunds comes in with 13.5 percent at this link here. Let's call it 12.5 percent, or 1 out of 8, for the purpose of comparison. 

This means that 6 out of 8 programmer geeks value a slight increase in performance and flexibility so highly that when they spend $25,000 or more on Motor City iron, they're willing to do more work (they'll say not much more) continuously over the life of the product to get it. But only 1 out of 8 of the general population makes the same decision when confronted with the same choice. And it's actually even lower than that, because all 6 of those geeks are in that 1 out of 8. The percentage of normal people willing to tolerate the extra effort is probably half that, maybe one out of 15. You value power and performance and configurability. Your user values ease of use, by a factor of 10 to 1 or more. Your user is not you.

For another example, I keep putting these pictures of my daughter into this newsletter (see her with a baby puffin in Iceland at the bottom of this page). Why am I laboring under the misconception that you actually enjoy looking at them? Because I enjoy looking at them, so I know what you would enjoy them as well (What the hell do you mean, you don't? You'll have to agree that she's far better looking than me. And will probably be smarter, too [don't touch that line]. Let me tell you about the cool stuff she just did ...) And because it's my newsletter, so if you don't like it, tough. That attitude doesn't usually translate into sales of commercial products, though. If this newsletter didn't carry content of such scintillating brilliance, you wouldn't put up with that nonsense. And the fact that it's free doesn't hurt either. 

So who is your user? That's the first question in any work of communication. And the second and the third. And arguably the fourth, fifth, and sixth.  I've met enough of you and taught enough of you that I think I have a handle on who you are, in the aggregate, anyway. But again, it's not enough to actually THINK you know who your users are. You have to KNOW, and that's much harder to do than you think it is. Finding real users is harder than you think. Letting a marketing guy represent them, as often happens, is like playing Russian Roulette with an automatic: quick suicide. Find some real ones. A client of mine, a Canadian company who will probably recognize themselves, is designing a major Web application without talking to any real users. I told them that they are committing malpractice. I haven't heard anything about changes.  

Once you've found real users, interviewing them isn't enough. Sure, ask them what they want, ask them about their background, ask them where they're coming from and where they're trying to get to. But this gets you only so far. They often don't know exactly what they want. Or they'll politely tell you what they think you want to hear (this problem is particularly bad in Canada), guided by clues in your questions. You'll say, "Wouldn't it be cool if [some UI feature you like]?", and what can they say? Especially because if they do say, "No, that would suck, and you're an idiot" the interviewer often starts arguing: "but haven't you always wanted to ..."  The act of observation changes the result. A physicist would call it "getting Heisenberged", after the author of the famous Uncertainty Principle. 

And once you're finished with your user design, you need to test it on real users. You'd never ship a product without testing its internal algorithms (OK, you SHOULDN'T), so why would you think that you can get away without testing a user interface? A computer that your users can't figure out how to use is a very expensive paperweight. You could give them the application to try and ask them afterwards how they liked it. But they often won't be able to remember what they did, or won't want to tell you about problems because they feel stupid that they couldn't figure it out, or won't want to insult you by telling you what a complete pile of crap the product of your last two years of professional life has turned out to be (this is a problem that I do not have.)  So you can get some idea by talking to them, but you really have to observe what they do in the act of dealing with your user interface. And you have to do that in a manner that doesn't affect their behavior. This means that you have to put them in front of the application in an isolated room, having access to only whatever support materials (e.g. online documentation) they will have in real life. You have to watch them through one-way glass, videotaping their reactions, and have logging software so you can see exactly which keystrokes and mouse clicks they used to try to deal with your application. 

When you do this, the light bulb goes on. As Alan Cooper wrote in his classic book About Face: The Essentials of User Interface Design (IDG Books, 1995): "Programmers fight desperately against the insistence that their creations can't be valid until they are tested by users, and usability professionals seem to have retreated to the empirical as their only way to convince the logical, rational, engineering mind that there is another, better approach to designing the user interface. They drag programmers into dark rooms, where they watch through one-way mirrors as hapless users struggle with their software. At first, the programmers suspect that the test subject has brain damage. Finally, after much painful observation, the programmers are forced to bow to empirical evidence. They admit that their user interface design needs work, and they vow to fix it." 

Here's an example of doing it right. I once taught Windows at an insurance company that was writing a Windows terminal emulator application to replace some expensive IBM terminals. Unusually for an insurance company's internal applications, they actually did the usability testing that I just told you about. And they did it well, too, with video tape and one-way glass, programmers watching, the whole thing. They found that the users basically liked the application and found it usable. But the users had the habit of pressing the "Enter" key to move from one input control to the next, as their terminals did, rather than the Tab key as Windows applications do, and had to keep going back to redo things when it didn't work. Couldn't the developers change that, they asked? After hashing it over, the developers decided that, while it was quite easy technically , it wouldn't be a good idea from a user standpoint. Sure, they could make this application work the old way. But all the new Windows applications that the users were going to have to use wouldn't work like that, and the users would soon go schizoid switching back and forth many times per day. So they developers convinced the users to bite the bullet and make the change. And after a period of squawking, the users calmed down, helped by the abysmal job market in that area at that time. My point is not that you should cram down users throats the features you think would be good for them. You usually can't get away with that; this was a special case. I'm relating the story to show you how a client of mine did a good job of usability testing. They did the testing they needed to do. They found what there was to find. And then they made the right decision based on what they found. I wish more companies would do that. 

So remember: Your user is not you. They care about ease of use first, and everything else fifth or worse. Observe them as I've told you, and you'll quickly see that. Now go write your programs for your users and not for yourself. 

We'll continue our discussion of  .NET in the next issue. I hope you enjoyed my UI rant. Give me a call if I can help you out. Until next time,  as Red Green  would say, "Keep your stick on the ice." 

Blatant Self Promotion

Public class on ACORD XML for Insurance in New York September 23 - 27 (and Boston Jan 27-31, 2003, and San Francisco April 1-5, 2003).  SAME CLASS AVAILABLE IN-HOUSE AT YOUR COMPANY. 

Two instructors combine to bring you the best of ACORD XML training. Tana Sabatino, former head of standards for ACORD teaches her 1-day XMLife data model class on Monday Sep 23. Then David Platt, long-time instructor in ACORD XML (author of this newsletter, in case you hadn't figured that out by now, and all-around great guy) teaches his 4-day class ACORD XML in Depth. Full syllabus and registration information are online at http://www.rollthunder.com/xmlpublicframe.htm. We're offering a 10% early bird discount for registrations received before August 15. 

Public Class on .NET for the Insurance Industry in Boston Dec 9-13, 2002. SAME CLASS AVAILABLE IN-HOUSE AT YOUR COMPANY. 

.NET is here, and it's hot. It changes everything in the software business, and you can't afford to be without it. Rolling Thunder Computing now offers in-house training classes on .NET, using my book as the text. I've split it up into customized offerings, such as .NET for Existing 3-tier Microsoft Programmers, .NET Framework Serious Geekery, .NET Web Programming, and .NET for the Insurance Industry. See the syllabi at http://www.rollthunder.com/DotNetNewPublicClassFrame.htm

Public Class on Programming .NET at Harvard Extension this fall

I'll be back teaching at Harvard Extension this fall, after a two-year hiatus. The course will be a broad survey of all of .NET, with lots of programming homework. It will meet on Monday nights at 7:30, starting September 23. I don't know the room yet,  and I haven't worked out the full syllabus yet. Announcements will be made on my web site,  http://www.rollthunder.com. Anyone interested in being a teaching assistant for the class, send me e-mail at dplatt@rollthunder.com.

5-day In-House Training Class on .NET or .NET for Insurance

.NET is here, and it's hot. It changes everything in the software business, and you can't afford to be without it. Rolling Thunder Computing now offers in-house training classes on .NET, using my book as the text. I've split it up into customized offerings, such as .NET for Existing 3-tier Microsoft Programmers, .NET Framework Serious Geekery, .NET Web Programming, and .NET for the Insurance Industry. See the syllabi at http://www.rollthunder.com/DotNetNewClassFrame.htm

New Book: Introducing Microsoft .NET, Second Edition

Updated to V1.0 Release, with 5 New Chapters Added

Sample code now in both VB and C#

by David S. Platt, President of Rolling Thunder Computing

Published by Microsoft Press

ISBN 0-7356-1571-3

Microsoft finally shipped .NET, so I decided to update my book on it, and add lots of new material that I didn't have time to cover before. I've brought all the material up to date with the final RTM version of the product. I've added enhanced material so several of the previous chapters, a sample of which forms this newsletter's feature article. And I've added 6 new chapters, as you can see in the table of contents below. And as many readers asked for, I've written all the sample code in both VB and C#. If you liked the first edition, you'll probably like the second one as well. I tried really hard to make it worth making your boss pay for again. We'll see what the sales numbers are. 

If you haven't seen it before, this book  is meant to be accessible to managers, while still providing enough information to be useful to programmers, both lightweight VB types and heavyweight C++ types.  The book is meant to be non-threatening, using a lot of pictures and diagrams, a small amount of simple VB code, and no C++ at all, which would scare off 80% of the potential readers. I write each chapter in a pyramidal structure, so managers can read the first three sections (Introduction, Problem Background, Solution Architecture). Ambitious managers and VB programmers can continue through the next section (Simplest Example). Heavier-duty developers can read the ends of the chapters, where I discuss more advanced elements of the topic.  The book's Web site is, naturally,  www.introducingmicrosoft.net. There you will find a free chapter on .NET My Services, as well as the code for all the book's samples, and a list of errata as soon as we find some. You'll also find a glowing review of the first edition here (well, what other kind did you expect me to link to? I may be crazy, but I'm not stupid.) written by Manohar Kamath. Here's the table of contents: 

The second edition should be on shelves by May 10.  You can pre-order it through amazon.com by following this link . It should be popular. The first edition was, and this one's better. On June 11, 2001, the first edition's sales rank on amazon.com was #762, thumping Tom Clancy's latest hardcover and paperback, hopelessly mired around #1400. That tells you something about Amazon's customers -- they're all geeks.

Internet Chuckle: Tuesday Morning Quarterback

This issue's Internet Chuckle features the column Tuesday Morning Quarterback, written by Gregg Easterbrook. It ran in Microsoft's slate.com for the last 2 years, but this year he's moved to ESPN.com. He's an editor at New Republic magazine, at Beliefnet.com,  and a visiting fellow at the Brookings Institution. Members of such outfits often take themselves far too seriously. let's face it, no one gives a flying fish what a think tank thinks, that's why they have to live in a tank. But Easterbrook brings a sardonic, mocking tone to his weekly review of pigskin activity which I love. For example, in his column on the annual NFL draft, entitled "Lies, Damned Lies, and Hundredths," he wrote:

"We couldn't believe he was still there!" Well, Tuesday Morning Quarterback could believe it. Of all the draft clichés -- and they abound -- "we couldn't believe he was still there!" is most grating. He was there because 31 other teams passed, and usually there's a reason. When TMQ was dating, he'd call some chick in desperation at 4 p.m. Saturday afternoon and think happily, "I couldn't believe she didn't already have a date!" Later that night, straggling back to the apartment, I could believe it.

For his annual prediction column, Haiku me? No, haiku you! ("All predictions guaranteed wrong or your money back!")  he wrote a haiku for each team. For example:

Even Microsoft
won't buy their stadium name.
Seattle Seahawks.

If you like football, or like satire, you'll like this column. It gets updated every Tuesday morning, in case you couldn't figure it out. You'll find his articles listed on this page. 

Annabelle's Latest

Seeing all the compliments I get from the pictures of my daughter, I'll shamelessly run another in this sport. Here she is on the island of Heimaey, off the coast of Iceland, breeding ground for millions of puffins. The adults abandon their chicks around the end of August and leave for their winter at sea. The chicks fly from their cliffside burrows to the water to fend for themselves. But many of them get confused by the lights of the village and  land in the town instead. They can't take off from the flat ground, so they run around helplessly until they get run over by vehicles or caught by the local dogs and cats. To help them, the children of the village go out with flashlights and capture the baby puffins, keeping them overnight in boxes before releasing them at sea the next morning. You can read about this in Bruce McMillan's book, Nights of the Pufflings, or online here.  We took her out to help, and she loved it. Here Annabelle says good-bye to a puffin just before I release it. 

Subscription Information

Thunderclap is free, and is distributed via e-mail only. We never rent, sell or give away our mailing list, though occasionally we use it for our own promotions. To subscribe or unsubscribe, jump to the Rolling Thunder Web site and fill in the subscription form.

Legal Notices

Thunderclap does not accept advertising; nor do we sell, rent, or give away our subscriber list. We will make every effort to keep the names of subscribers private; however, if served with a court order, we will sing like a whole flock of canaries. If this bothers you, don't subscribe.

Source code and binaries supplied via this newsletter are provided "as-is", with no warranty of functionality, reliability or suitability for any purpose.

This newsletter is Copyright © 2001 by Rolling Thunder Computing, Inc., Ipswich MA. It may be freely redistributed provided that it is redistributed in its entirety, and that absolutely no changes are made in any way, including the removal of these legal notices.

Thunderclap is a registered trademark ® of Rolling Thunder Computing, Inc., Ipswich MA. All other trademarks are owned by their respective companies.