查看文章 |
来源：http://headrush.typepad.com/creating_passionate_users/2006/12/dont_make_the_d.html
When we show a work-in-progress (like an alpha release) to the public, press, a client, or boss... we're setting their expectations. And we can do it one of three ways: dazzle them with a polished mock-up, show them something that matches the reality of the project status, or stress them out by showing almost nothing and asking them to take it "on faith" that you're on track. The bottom line: Every software developer has experienced this many times in their career. But desktop publishing tools lead to the same headache for tech writers--if you show someone a rough draft that's perfectly fonted and formatted, they see it as more done than you'd like. We need a match between where we are and where others perceive we are. Joel Spolsky talked about this way back when in The Iceberg Secret, Revealed. The secret: "You know how an iceberg is 90% underwater? Well, most software is like that too -- there's a pretty user interface that takes about 10% of the work, and then 90% of the programming work is under the covers... That's not the secret. He goes on to add corollaries including:
"Later... I found out that all we really saw were Macromedia Director-based movies. They looked so cool...how good they made us feel... This actually was NOT a good thing for Microsoft...when you build up expectations and you aren't able to meet them you look pretty silly. But behind the scenes things were even worse. Why? Because executives bought into the Flash and Mirrors song and dance too. They thought what they were seeing was possible... it's very possible that what you are dreaming of is simply not possible." So, overpromising by delivering a flashy (or Photoshopy or Powerpointy or Visioy) demo is tempting, but it's short-term gain (you're a hero to your client, boss, the public) with long-term pain. But there's another problem with overdone demos that's just if not more damaging than wrong expectations: The more "done" something appears, the more narrow and incremental the feedback
We see this with books and software all the time. Show them something polished and pretty, and you'll get feedback on font sizes. The reviewers make incremental tweaks, blinded by what's in front of them. But show a napkin sketch, and they don't just see what's there, they see what's possible. Obviously you need to tell reviewers about the kind of feedback you DO want at this stage... you don't want big-picture-forest feedback when you've really moved on to the tree stage. My point is: all you'll get is tree-tweaks when you show something finished-looking, so if you want big picture, make it fuzzy! Finally, it's great to know that there are tools to help make the look match the state, with my favorite being the Napkin Look and Feel, a GUI "skin" for Java that makes the interface look--quite literally--like it was scrawled on a napkin. I think it's brilliant, and creator Ken Arnold (Java guru, fellow Sun refugee) paid astonishing attention to detail. For example, if the radio buttons were all exactly the same, no matter how sketched they look, their exact sameness would break the spell. So, there's more than one of nearly all of the GUI components from sliders to buttons to tabs to... Here's just one picture, but I urge you to go check out the snapshots on Sourceforge or even better, try the actual Java demo (you can get to the demo from the link above).
I realize that there are a million exceptions and caveats (like, for example, when you'll be fired if you don't show something jaw-dropping early on), but in general, the more closely what you SHOW matches what you HAVE, the more likely you are to have less pissed-off people down the road, and the more likely you are to get much better feedback, at the stage you need it. Bottom line: when it's an early demo, think fuzzy. Think sketchy. Think underpromise-and-overdeliver. [Related links:
|
