Wednesday, April 19, 2006

Good news, everyone

Jeff and I are working on a minor update to Vocabulicious, to be released when he's finished digging out from finals-related work. In the meantime, though, we're looking for any and all suggestions for words to be added or removed. If you've been making a list – and I know some of you have have – either leave it in the comments or send it to vocabulicious@gmail.com. Thanks!

Tuesday, April 18, 2006

"My Fast Makes It Hard to Have a Relationship."

True to their word, VW sent me my Fast yesterday – complete with four interchangeable tails. I am surprised to report that people by and large recognize him from the TV ads without any explanation. Seems like, between the "Fast" ads, the "Unpimp ze auto" ads, and the new "Safety Happens" campaign, VW's pushing hard to recapture their image. Remember this one?

Monday, April 17, 2006

Coke Blak.

Many months ago, deep within the top-secret Flavoropolis labs at Coca-Cola, a solitary, pale-skinned lab nerd wondered what would result if Coke was carefully hinted with black coffee.

Well, now we know.

It's not bad, but it certainly isn't wonderful. It fits somewhere between Vanilla Coke (bleh) and Cherry Coke (mmmm). I'd buy it again, but probably only that one more time. It fails to upset Mountain Dew Pitch Black II as the best soft-drink introduction of the last twelve months.

Monday, April 10, 2006

Let's See Some Fundamentals Out There.

There's been a lot of Nelson directed at Microsoft for its latest Vista and Office delays. Although I do not purposely keep up with its every move, it's tough not to think about Microsoft frequently when its actions are so universally scrutinized. So, with that as an excuse, I was perusing the Slashdot comments last week and came across this:

"(...) All these years we've been giving MS monopoly rent for OS software in the belief that we were paying for an exciting future, and now the company that's been taking our money is going to give us another 'ticking time-bomb of unstable code'. After five years and more than a hundred billion dollars revenue from computer users, Microsoft will revamp Vista at the 11th hour to turn it into a little more than a skin on XP, which was little more than a skin on 2K. Almost all recent innovations in computing have come from organisations with orders of magnitude less revenue than MS. We are simply not getting value for money." – ozmanjusri

Although certainly more than just a skin on XP, publicly available information leads me to agree that nothing in Vista really raises the bar. The list of new end-user features reads like a Cliff's Notes of the last three years in popular computing (tabbed browsing, desktop search, widgets) along with long-awaited solutions to ridiculously dumb problems (default users are administrators, Windows Update runs through Internet Explorer) that aren't features so much as they are corrections.

The real problem, though, is that almost every one of the features customers are anticipating is already available for Windows XP, for free. Yahoo! has a widget engine. Google, Copernic, and even Microsoft itself has a desktop search tool. Firefox eats IE alive. And there's a wide assortment of free antivirus / antispyware apps, which Vista won't even include.

But that's not the point. It's easy to kick Microsoft for not creating innovative features at the same rate as competitors "with orders of magnitude less revenue." As has been said many times, innovation is not its goal. Microsoft's first goal is to keep Windows a stable platform – which is to say, it does everything in its power to maintain backwards compatibility. It's a noble goal, certainly, and it's the one thing it will always have as an advantage over its smaller competitors, who have neither the people nor the money to cover the enormous cost and complexity of all the testing required to ensure a program written to Windows 95 will still run in Vista. But it's reached the point where I have to question the validity of this goal, and it is in that sense that I agree with the Slashdot commenter.

Backwards compatibility simply isn't sustainable, and in the long run it hurts the platform. It's pretty clear that the tradeoff Vista is making for compatibility is to throw out a lot of new features; to claim a refreshed GUI as a great new feature is to ignore the fact that every new Windows release since 95 has had a new GUI, and it hasn't once been of value. In fact, it's been a huge detriment to backwards compatibility, because every single user needs to re-learn Windows in order to do work they were already able to do in the previous version. It's a huge waste of time and money, and now it's being done to Office simultaneously.

I don't mean to say that familiarity with an interface should preclude attempts to redesign it, but it seems to me (from my very limited vantage point) that Microsoft is wrong to revamp the UI if the Windows+Office combo's focus, and advantage, is compatibility. A UI designer for the new version of Office, Jensen Harris, vaguely cites increasing complexity and difficulty with navigation as reasons to combat the perception of a bloated Office UI, but he then later admits, "we didn't end up making the suitcase any bigger (...) we just added more pockets." Although that's well and good (who doesn't love increased efficiency?), I have trouble believing that Office and Windows customers want an upgrade that breaks all their current knowledge but brings little new to the table.

To be blunt: I don't think Microsoft knows who its customers are. Mr. Harris even says as much when he discusses the long tail of Office commands people use: "(...) Beyond the top 10 commands there are a lot of different ways of using the product." When you have no example user, you can't design effectively. But instead of taking that as a sign, they looked at aggregate click data and focused on increasing GUI efficiency. Who wanted increased GUI efficiency? Home users? Commercial users? Anybody? I don't think so.
  • Expert home users have already figured out how to do what they want, and novice home users have memorized or written down a set of steps to follow in order to do what they want. Changing the UI fouls everything up.

  • Commercial users have an expensive infrastructure built around their existing installed software. They have training plans, manuals, support staff, and deadlines. Changing the UI breaks every piece of documentation they have, and causes a huge up-front drop in efficiency which isn't necessarily going to be counterbalanced down the road. Changing the UI fouls everything up.

Okay, so, if not a new GUI, then what do Vista customers want? I couldn't tell you. That's what properly conducted user research is for. Since Mr. Harris seems to think traditional methods are hard (thought: maybe letting users self-select at the end of the post is a bad idea), I would suggest starting the research with tech support call centers for Windows-based apps. I imagine front-line support personnel for AOL, Activision, and, well, Microsoft Office have a pretty good idea of what current trouble spots are – and I bet they wouldn't suggest changing button labels. It would probably also be enlightening to take a tour of public libraries around the US, taking screenshots of the Windows-based public computers to see what's happened to them. And finally, sit in on a few "learning to use computers" night classes to see what metaphors are in vogue for teaching novice users.

...

..

.. Okay, yeah, UI-centric posts tend to peter out disappointingly, because they end up advocating proper research instead of suggesting concrete ideas. So with immediate gratification in mind, here's a stab at what might work. First, split up different versions of Office by functionality as well as by bundle. For example, Office 2007 Student + Teacher Edition doesn't need to be able to import pivot tables or Access databases, so remove those features. By doing this, the designers can reduce complexity by reducing functionality, and at the same time tailor the presentation of specific sets of features to specific audiences.

As far as making Vista a compelling proposition, home users would probably find it valuable if Windows Update were able to acquire and update drivers for all of their hardware. Commercial users probably want a universal mute button that works even during boot, so they don't annoy the whole plane or classroom with their start-up sound. And I bet everyone would like it if the GUI stood pat, or maybe even devolved a bit, if it meant their apps would launch faster and battery life would improve.

Oh, and include a free virus scanner. That one's a gimme.

Saturday, April 08, 2006

Just a quick thought.

You've already heard about Boot Camp, the Apple-sponsored application that lets Intel Macs boot Windows. There's been a lot of speculation about why Apple would ever support this, and what's in it for them. I think I have a good answer, that I haven't seen anyone else give yet.

  1. Apple makes their money from hardware sales.
  2. Mac users desperately want to play games, to the point where they'd be willing to boot Windows to do it.
  3. Apple released drivers along with Boot Camp, so Intel Macs can play games.

You see? Apple has just introduced a new reason for Mac users to frequently upgrade: to play the latest Windows games. And since Apple's hardware is generally nonupgradeable, you have more people than ever before buying new hardware regularly in order to play the latest Windows games.

They've coupled the upgrade cycle of their power users to the Windows gaming world. Sneaky.

Friday, April 07, 2006

How to Apply User Data to a Redesign.

"We believe implicitly that the scientist is one type, the artist a radically different one. In fact, the scientific and artistic personalities overlap more than they differ." – David Gelernter

I've been meaning to review both Spolsky's book Joel on Software and 37signals' e-book Getting Real for a little while now. They cover many of the same topics – software development, software-centric project management, and design techniques, among others – and agree philosophically on many points. I found, in particular, that their shared support for prototyping GUI elements early on appealed to my personal approach, as well as my educational background.

They certainly don't agree on everything, though, and I had some trouble reconciling their opposing arguments. Their most obvious point of contention, and the biggest hang-up for me after reading both sides, was with regards to the amount of design and architectural work that should be done up-front. In short, whether or not to have a functional specification before work on the program begins.

(What's a functional specification?)

Spolsky argues that a functional spec is necessary for three major reasons. First, its creation forces the developers and customers to define the scope of the software up-front, thereby theoretically eliminating feature creep and allowing everyone involved – including the customer – to approve the final product before any development effort is expended. In this way, there are no surprises and no time wasted writing software that ends up doing either too much, or too little. Also, he argues that a functional spec's presence from the get-go should reduce time spent communicating changes later on, which results in less total time spent and fewer errors made. And finally, a functional spec would facilitate the up-front creation of an accurate schedule.

37signals largely argues the opposite, in the aptly-titled chapter "There's Nothing Functional About A Functional Spec." Briefly, they believe that functional specifications "force you to make the most important decisions when you have the least information." The spec often ends up being altered later on anyhow, so there's little reason to spend all the time drafting and agreeing up-front when prototyping could already have begun. Furthermore, specifying in detail how the application should work before it exists disallows the inevitable changes which must be made when the customers actually get to use it. 37signals believes that instead of writing a spec, one should "write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, it's too complex."

To be fair, the companies create different types of software -- Spolsky's Fog Creek creates feature-rich web and desktop software, whereas 37signals' apps are entirely web-based and purposely minimal. Both companies have had their share of success, although one could argue the latter company has become more of an overall phenomenon. But regardless of the type and size of software under development, the arguments hold water. Both methods have clearly been proven to work, and in similar situations.

Where's this going? Well, I found this disagreement interesting because it implies a much more fundamental argument: whether or not to listen to user input during the design phase. More nicely phrased:

"I think the most important reason for having a spec is that it puts the decision-making authority in the hands of the correct people - the users. Without a spec, the developers will either have to pester the users every time they try to develop a new feature, or (more likely) they will make decisions and assumptions on their own about what the users would prefer." – Jesse Smith


37signals is pretty against involving users up-front, arguing that they, the developers, know what users want just as much as the users themselves do; this argument is of course a rephrasing of the old saw, "Users don't know what they want." (Which is, incidentally, true.) This argument starts to lose potency when the users are dissimilar to the developers, though, and when developers create software for people different from themselves (say, zookeepers), they really need to stop reading books and get a professional HCI / UCD guy.

As a theoretically professional HCI / UCD guy, I believe I have lately figured out how to reconcile the functional-spec disagreement in my own work. It's a pretty hard problem, and not one I propose a solution to lightly.

A traditional HCI / UCD approach to user-centered redesign is thus:

  1. Gather data about the users, via contextualized interview techniques.
  2. Model the users' mental states, processes, and flow, in order to understand the users.
  3. ???
  4. Redesign.

At school we often found ourselves hitting a wall at step 3. How does my understanding of individual users allow me to actually create a better design? I know that people can't find the Print command, but that doesn't tell me what to do. With a corpus of user-centric data, the leap to a new approach is usually painful and sometimes magical. We often ended up using affinity diagrams, which are something of a cop-out. In my humble opinion, affinity diagrams substitute groupthink for process and inspiration.

The Spolsky / 37signals disagreement over the value of functional specs provided me a solution: write a minimal, one-sentence functional spec from the user's point of view. As either a developer, customer, or UCD researcher, your understanding of the user's wants, needs, and beliefs come out in that one sentence, and you end up making any incorrect beliefs or assumptions explicit. Ask your mental model of the user, "What is this application supposed to do?", and write down the answer. If you're working in a group, have everyone write down their own answer. Then, compare. Any misgivings, misunderstandings, or false assumptions will surface immediately.

Since a one-sentence functional spec is focused in intent but blurry on the details, it doesn't force features to be decided upon immediately. Instead, the overall purpose of the application reveals itself. And, once a one-sentence spec is created, it can be written on post-its and taped to monitors. I've found that once the one-sentence spec exists, it becomes something of an oracle, shooting down most feature-creep ideas pretty easily and guiding the overall direction of development.

It works for me, anyway. Here's an example: "Vocabulicious is a new, free word game for Windows and Mac OS X."