Blinded by experience

Don Norman knows more about design than I ever will. He even "knows" a few things that aren't even true. That's some powerful knowing! Specifically:

You cannot successfully introduce a non-qwerty keyboard today, or reverse the window scroll bar convention, or suddenly require double-clicking on web links.

I think Don has spent too much time lately with experienced web users, and not watching people like Lou, my father-in-law. Lou is a retired printing production manager, who trained as a graphic artist and worked for several ad agencies. He got one of the first Macs so he could use PageMaker, and used Photoshop when it was still owned by Aldus.

Lou "knows" that you have to double-click things with the mouse. He has known that for over 20 years. I've tried to point out that you don't have to do that on the web. He does it anyway. His current computer runs Windows 95, so if I wanted to I could set the option to use single-click select globally. I would never set that prefernce on his system, though. It would drive him insane.

But Microsoft did introduce the new behavior. There is a generation that has grown up using it. Could someone do the same thing with web links? They'd have to have market penetration comparable to what Microsoft had with Windows 95, but yes, they could do it.

Here's where it gets interesting. You could reasonably support either side of this decision: There are people who "know" that you double-click everything, and people who "know" that you single-click everything. Either one will be frustrated by a system that does the opposite. But knowing that both kinds of people exist, what should we do? In the Hippocratic tradition, first do no harm.

I can't count the number of sites I've seen that instruct users to "Only click the Submit button once." Or "Please wait for the page to load." As soon as we start warning users what they should or shouldn't do, two things should be apparent:

1. Users, for some reason, think that they should do the very thing we're telling them not to do.
2. Some of them are going to do it despite our warnings.

If we can't prevent users from doing the "wrong" thing with our applications, we owe it to them to at least make sure that they don't break anything when they do.

Negotiation starts from confidence

It seems obvious when you think about it, but I don't hear it said very often: The first step toward getting what you want is knowing what you want. You have to do more than recognize what you want, you have to be confident in it.

Here's an example from my college days: I worked at a bar for a couple of years. On weekends, we'd have someone at the door checking ID. There were plenty of people who tried to talk their way in without any.

One night the regular doorman was late, and I covered for him. The first girl who showed up without ID smiled, batted her eyelashes and asked "pretty please?" I said something like, "Gee, I really wish I could, but rules are rules, etc." She argued, I refused, she got mad ... I'd like to chalk my behavior up to my youth and her smile, but the bottom line is I didn't project confidence in what I wanted.

The next girl who showed up without ID (for some reason guys never tried this with me, I don't know why) I just told her I needed ID or she couldn't get in, sorry. She threw a quick pout, then left to find someplace else she could get into.

As I thought about this later I realized the first girl wasn't mad because she wasn't allowed in. She was mad because I gave the impression I might be open to negotiation but I wasn't.

Moral of the story: Know which of your goals are negotiable and which ones aren't. Never give the impression that one of the former might be one of the latter. Reasonable people can respect an honest difference of opinion, but will read indecisiveness as an opportunity to negotiate.


Update: I found another way of putting this, on Scott Berkun's site where he explains why things suck:

It's the things that tease us, making us think they'll satisfy us but then failing, that hurt the most.

He was pointing out that people don't complain about things they don't care about, but it works really well to explain what happened to me when I was working at the bar.

Here's a crazy thought

Corel should sue people who use Photoshop without paying.

Huh?

Think about it. Graphics professionals pay for Photoshop. Lots more people do some graphics, but not enough to be worth $650. But many of those people possibly would agree that their use is worth $80.

So there are probably people using cracked copies of Photoshop who, if they didn't have the crack, would instead have bought Paint Shop Pro.

It seems reasonable that if we're going to report losses to "piracy" in terms of lost sales, we should be counting the potential sales that are really lost.

Writing a test approach

If this is the first time someone has asked you to produce one, it's kind of an odd exercise.

First, recognize that you have some pretty significant prerequisites, and second that you have to consider multiple audiences. But what it all comes down to is making sure that the application does what it's supposed to do.

The prerequisite comes from needing a good definition of "what it's supposed to do." I wish this were as easy as it sounds. Look at how much is written about whether/how to write specifications to see what you're up against.

Once you have a good spec, you have two questions to answer. It's really the same question answered for two audiences, but the answers can be pretty different: How do you ensure that it does the right thing; and how do you demonstrate to your client that it does the right thing?

Answering the first question will involve unit testing, regression testing (for upgrades), creation and execution of test scripts, etc. It's possible a large part of the execution will actually be done by the developers.

Answering the second question -- satisfying the client -- requires that you talk in terms of: user interaction, use cases, end-to-end scenarios, scalability/performance/load testing, support and training needs, etc.

Imagine you are presenting a sales pitch to a client, and you need to describe how you will demonstrate the value and correctness of your application. Write a narrative proposal, eg:

Working with end users and subject matter experts (name names if possible), we will define use cases that describe the expected functionality of the application. This process should take X hours of the users' time over the course of Y days.

These use cases will be executed and verified by someone, using volume of data extracted from source. Developers will also create automated scripts to be executed on toolname, simulating how_many concurrent users executing how_many transactions per second for how_long.

You're not trying to actually write the test scripts yet. Start out with the higher-level description of what types of testing you expect to do, and who is responsible for writing and executing each type. Theoretically you may not know the performance figures in that second paragraph, but I find it's better to put some numbers in front of the stakeholders and let them disagree.

Can someone give me the name of a good buggy whip maker?

No really, I want to talk to one. There should be several in every large town, just like there used to be. Because it would be immoral to deprive them of their "right" to make money in the way that they want to.

"But that's absurd," you say, if you've never heard the argument before. "You'd have to outlaw cars to protect the buggy whip manufacturing business." Yes, and that's exactly what the buggy whip makers tried to do: ban the car.

Copyright does the exact same thing buggy whip makers tried to do: it protects a specific business model. The "right to control copying" exists to encourage people to go into the business of creating new works.

We, as a society, benefit from having new works. We have agreed to grant creators of those works a temporary monopoly on reproducing and selling those works. If the specific method that we're using to encourage creation actually serves to restrict creation, our method needs to change.

Everyone who thinks the RIAA is responsible for increasing the net creative output of the world, raise your hand ... Everyone who thinks the MPAA is the creative force behind independent film, raise your hand ...

Copyright law was a specific solution to a specific problem. It doesn't codify some inherent human right. If the "solution" has been pushed too far in one direction, which I believe it has, it's time to re-think the balance. Or maybe come up with some new way to encourage creation of easily-copied works.

Apples and Oranges ...

... are actually pretty damn similar.

How did "like comparing apples and oranges" get to be our standard phrase for indicating that two things are so different as to resist comparison? They're both fruit, typically about the size of a baseball, have a skin and seeds, are mostly water. There are more similarities than differences.

I assumed there was some history to this phrase, some context where it made sense. The only thing I can find is one reference suggesting, "that the phrase appeared as apples and oysters in John Ray's proverb collection of 1670." Okay, that makes a bit more sense. Or at least it works better for what people mean when they say it.

But I suspect it's more like the phrase, "You can't judge a book by its cover." Really? Put a Unix textbook next to a Harlequin romance and I'll bet I can tell you a whole lot about it. That phrase originated in a time when all books were printed with blank bindings, and covers could be applied by the seller or the customer. So back then no, you really couldn't tell a book by its cover.