In the latest episode of my Microsoft Conversations series I got together with Bill Buxton to talk about the design philosophy set forth in his new book Sketching User Experiences. Nowadays Bill is a principal researcher with Microsoft Research, and before that he was chief scientist at Alias/Wavefront, but his involvement in the design of software and hardware user interfaces goes all the way back to Xerox PARC. Along the way he’s accumulated a fund of wisdom about what he calls design thinking — a way of producing, illustrating, and winnowing ideas about how products could work.

I haven’t yet received my copy of his book, but my background for this conversation was a talk given last November at BostonCHI, the Boston chapter of the ACM’s special interest group on computer-human interaction. In that talk (which summarizes key themes from the book), and also in this conversation, Bill lays down core principles for designing effective user experiences.

He proceeds from the assumption that sketching is fundamental to all design activity, and explores what it means to sketch a variety of possible user experiences. His approach is aggressively low-tech and eclectic. He argues that although you can use software tools to create fully-realized interactive mockups, you generally shouldn’t. Those things aren’t sketches, they’re prototypes, and as such they eat up more time, effort, and money than is warranted in the early stages of design. What you want to do instead is produce sketches that are quick, cheap, and disposable.

How would you apply that strategy to the design of, say, the Office ribbon? When Bill talks about sketching, he means it literally:

You’d start with paper prototyping — quickly hand-rendered versions, and for the pulldown menus and other objects you’d have Post-It notes. So when somebody comes with a pencil and pretends it’s their stylus and they click on something, you’ve anticipated the things they’ll do, and you stick down a Post-It note.

What matters here isn’t the interaction between the test subject and the prototype, because it isn’t really a prototype, it’s a sketch. Rather, what matters is the interaction between the test subject and the designer. The sketch need do no more than facilitate that interaction.

Continuing with the same example, here’s how an eclectic strategy keeps things simple and cheap:

Now that will give you the flow and the sequence of actions, but it will not give you the dynamics in terms of response time. To show that, I’d use exactly the same things, photograph them, and then make a rough pencil-test video so I could play back what I think the timing has to be to show it in realtime. It’s a combination of techniques, where none is sufficient on its own.

Later in the conversation, he challenges some of my favorite themes. Bill’s skeptical about the notion (popularized by Eric von Hippel) that lead users can be co-designers of products. And he doesn’t think that logging interaction data is as useful as I think it is. But he agrees with me that a key weakness of paper prototypes is their inability to incorporate the actual data that animates our experiences of products and services. One of his examples: MP3 players think in terms of songs, not movements, so if you load one with classical music you’ll find a bunch of duplicate songs called Adagio. In such a case, Bill admits, you’d like to have used a more fully-realized prototype that could have absorbed real data and flushed out these kinds of problems. His point isn’t that you should never deploy heavier design artillery, but rather that you should reserve it for when it’s absolutely necessary. Much of the time, he believes, sketching is faster, cheaper, and more productive.

Several months ago my bank implemented an anti-phishing scheme called Site ID, and now my mortgage company has gone to a similar scheme called PassMark. Both required an enrollment procedure in which I had to choose private questions and give answers (e.g., mother’s maiden name) and then choose (and label) an image. The question-and-answer protocol mainly beefs up name/password security, and secondarily deters phishing — because I’d notice if a site I believed to be my bank or mortgage company suddenly didn’t use that protocol. The primary anti-phishing feature is the named image. The idea is that now I’ll be suspicious if one of these sites doesn’t show me the image and label that I chose.

When you’re talking about a single site, this idea arguably make sense. But it starts to break down when applied across sites. In my case, there’s dissonance created by different variants of the protocol: PassMark versus Site ID. Then there’s the fact that these aren’t my images, they’re generic clip art with no personal significance to me. Another variant of this approach, the Yahoo! Sign-In Seal, does allow me to choose a personally meaningful image — but only to verify Yahoo! sites.

These fragmentary approaches can’t provide the grounded and consistent experience that we so desperately need. One subtle aspect of that consistency, highlighted in Richard Turner’s CardSpace screencast, is the visual gestalt that’s created by the set of cards you hold. In the CardSpace identity selector, the images you see always appear together and form a pattern. Presumably the same will be true in the Higgins-based identity selector, though I haven’t seen that yet.

I can’t say for sure, because none of us is yet having this experience with our banks and mortgage companies, but the use of that pattern across interactions with many sites should provide that grounded and consistent experience. Note that the images forming that pattern can be personalized, as Kevin Hammond discusses in this item (via Kim Cameron) about adding a handmade image to a self-issued card. Can you do something similar with a managed card issued by an identity provider? I imagine it’s possible, but I’m not sure, maybe somebody on the CardSpace team can answer that.

In any event, the general problem isn’t just that PassMark or Site ID or Sign-In Seal are different schemes. Even if one of those were suddenly to become the standard used everywhere, the subjective feeling would still be that each site manages a piece of your identity but that nothing brings it all together under your control. We must have, and I’m increasingly hopeful that we will have, diverse and interoperable identity selectors, identity providers, relying parties, and trust protocols. But every participant in the identity metasystem must also have a set of core properties that are invariant. One of the key invariant properties is that it must bring your experience of online identity together and place it under your control.

Because of travel, last week’s ITConversations show was a rerun of my conversation with Lou Rosenfeld about a cluster of topics including information architecture, search analytics, print and online publishing, designing for usability, tagging, and microformats. This week’s show is a conversation with ITConversations founder Doug Kaye about his new project, PodCorps, which aims to connect producers of spoken-word events with stringers who can help get those events audio- or video-recorded and then published on the Web.

Here’s a fun fact I uncovered. Doug hadn’t heard of one of my favorite things lately, the LibriVox project. When I mentioned that Hugh McGuire cites AKMA’s collaborative recording of Larry Lessig’s Free Culture as a primary inspiration, Doug pointed out that he was the reader for the first chapter of that project. Small world!

RESTful Web Services, by Leonard Richardson and Sam Ruby, was published this month. I interviewed the authors yesterday for an upcoming ITConversations show, but I also want to spell out here why I think it’s such an important book.

In the realm of IT you could hardly pick a more controversial topic. Or, in a way, a more unlikely one, given that the REST (Representational State Transfer) architectural style has its roots in what would normally have been an obscure Ph.D. thesis. Roy Fielding, the author of that thesis, told me in an interview that he was surprised by its breakout popularity. But he probably shouldn’t have been. There are not many technologies as foundational as the Hypertext Transfer Protocol (HTTP), whose principles that thesis defines.

But Fielding’s thesis is a thesis, not a practical guide. The effort to bridge from theory to practice has produced a considerable amount of folklore. “We’re writing a book,” the authors say in their web introduction, “to codify the folklore, define what’s been left undefined, and try to move past the theological arguments.” The mission is clearly defined in the first chapter:

My goal in this book is not to make the programmable web bigger. That’s almost impossible: the programmable web already encompasses nearly everything with an HTTP interface. My goal is to help make the programmable web better: more uniform, better structured, and using the features of HTTP to greatest advantage.

The book opens by usefully distinguishing between a set of architectural styles (REST, RPC [remote procedure call], REST-RPC hybrid) and suite of technologies (HTTP, XML-RPC, WS-*, SOAP). We tend to conflate architectures with technologies because they usually go together, but that’s not necessarily the case. The authors cite Google’s SOAP API (and other “read-only SOAP and XML-RPC services” as being “technically REST architecture” but nevertheless “bad architectures for web services, because they “look nothing like the Web.”

This book asserts that most services can, and should, “look like the Web,” and it spells out what that means. Among the key principles:

• Data are organized as sets of resources
• Resources are addressable
• An application presents a broad surface area of addressable resources
• Representations of resources are densely interconnected

To illustrate these principles, the authors work through a series of examples from which they distill gems of practical advice. When designing URIs, for example, they recommend that you use forward slashes to encode hierarchy (/parent/child), commas to encode ordered siblings (/parent/child1,child2), and semicolons to encode unordered siblings (/parent/red;green). Pedantic? Yes. And bring it on. Lacking a Strunk and White Elements of Style for URI namespace, we’ve made a mess of it. It’s long past time to grow up and recognize the serious importance of principled design in this infinitely large namespace.

Here’s another key principle: “When in doubt, model it as a resource.” To illustrate that principle in a dramatic way, the authors apply it to a problem that RESTful web services are normally thought incapable of solving: transactions. By modeling the transaction itself as a resource, they arrive at the following:

First I create a transaction by sending a POST to a transaction factory resource:

POST /transactions/account-transfer HTTP/1.1
Host: example.com

The response gives me the URI of my newly created transaction resource:

201 Created
Location: /transactions/account-transfer/11a5

I PUT the first part of my transaction: the new, reduced balance of
the checking account.

PUT /transactions/account-transfer/11a5/accounts/checking/11 HTTP/1.1
Host: example.com

balance=150

I PUT the second part of my transaction: the new, increased balance of
the savings account.

PUT /transactions/account-transfer/11a5/accounts/savings/55 HTTP/1.1
Host: example.com

balance=250

At any point up to this I can DELETE the transaction resource to roll
back the transaction. Instead I’m going to commit the transaction:

PUT /transactions/account-transfer/11a5 HTTP/1.1
Host: example.com

committed=true

I don’t think my bank’s going to be adopting this technique any time soon, but it’s a fascinating thought experiment which suggests that what the authors call resource-oriented architecture (ROA) is a young and in many ways still relatively unexplored discipline.

On the question of ROA versus SOA (service-oriented architecture), the authors say that for certain kinds of enterprisey problems — including advanced security protocols and complex coordinated workflows — only SOA meets the need. They recommend it for these purposes, when the need arises. But in the many situations where the need does not arise, they recommend starting with ROA.

I’m inclined to agree, but I’d feel better about that recommendation if the glide path from ROA to SOA were smoother. It isn’t. Toward the end of our interview I asked Sam Ruby, who has been a long and forceful advocate for a smooth glide path, whether he thinks we’ll achieve it. He doesn’t. That worries me, but I haven’t given up hope. I’ve always seen ROA and SOA as points along what Frank Martinez calls a tolerance continuum. Among its other accomplishments, this excellent book advances that important point of view.

As an early supporter and ongoing fan of WebJay, I’m sorry to hear that the service will close in June and curious to know why.

Today my digital assets are spread out all over the place. Some are on various websites that I control, and a lot more that I don’t. Others are on various local hard disks that I control, and a lot more that I don’t. It’s become really clear to me that I’d be willing to pay for the service of consolidating all this stuff, syndicating it to wherever it’s needed, and guaranteeing its availability throughout — and indeed beyond — my lifetime.

The scenario, as I’ve been painting it in conversations with friends and associates, begins at childbirth. In addition to a social security number, everyone gets a handle to a chunk of managed storage. How that’s coordinated by public- and private-sector entities is an open question, but here’s how it plays out from the individual’s point of view.

Grade 3

Your teacher assigns a report that will be published in your e-portfolio, which is a website managed by the school. Your parents tell you to write the report, and publish it into your space. Then they release it to the school’s content management system. A couple of years later the school switches to a new system and breaks all the old URLs. But the original version remains accessible throughout your parents’ lives, and yours, and even your kids’.

Grade 8

On the class trip to Washington, DC, you take a batch of digital photos. You want to share them on MySpace, so you do, but not directly, because MySpace isn’t really your space. So you upload the photos to the place that really is your space, where they’ll be permanently and reliably available, then you syndicate them into MySpace for the social effects that happen there.

Grade 11

You’re applying to colleges. You publish your essay into your space, then syndicate it to the common application service. The essay points to supporting evidence — your e-portfolio, recommendations — which are also (to a reasonable degree of assurance) permanently recorded in your space.

College sophomore

You visit the clinic and are diagnosed with mononucleosis. You’ve authorized the clinic to store your medical records in your space. This comes in handy a couple of years later, when you’ve transferred to another school, and their clinic needs to refer to your health history.

Working professional

You use your blog to narrate the key events and accomplishments in your professional life, and to articulate your public agenda. All this is, of course, published in your space where you are confident (to the level of assurance you can reasonably afford) that it will be reliably available for your whole life, and even beyond.

Although this notion of a hosted lifebits service seems inevitable in the long run, it’s not at all clear how we’ll get there. The need is not yet apparent to most people, though it will increasingly become apparent. The technical aspects are somewhat challenging, but the social and business aspects are even more challenging.

In social terms, I think it’ll be hard to get people to decouple the idea of storage as a service from the idea of value-added services wrapped around storage.

On the business side, my conversations with Tony Hammond and Geoffrey Bilder have given me a glimpse of how these issues are being approached in the world of scholarly and professional publishing. But it’s not yet apparent that the specialized concerns driving these efforts will, in fact, generalize in important ways to almost everybody.

Parents nowadays face tough questions about whether to monitor or (try to) control their kids’ use of the Internet, and if so, how. Although my personal opinion is that trying to restrict access is a losing battle, I understand why the idea is appealing. You’d like your kids to have some maturity and some perspective under their belts before encountering some of what the Internet so readily brings to their attention. When my kids were younger, the Internet was younger too. I guess if they were still that young I’d be wishing I could create a sandbox for them, even though I don’t think you can. But they’re teenagers now, and they have their own computers. For two reasons, activating the parental controls on those computers isn’t the strategy I want to pursue.

The first reason is that I don’t think filtering the Internet is feasible. Even if we could agree on a definition of what may be harmful, which we never could, people will find ways to route around censorship. Meanwhile we’ll inevitably censor things we never meant to — like, for example, my InfoWorld blog.

The second reason is that I don’t want to incent my kids to route around controls I might try to impose. Nor do I want to force them to go elsewhere to experience an uncensored Internet. The reality of the Internet, like the reality of the world, is something they’ll be dealing with for the rest of their lives. I’d rather they engage with that reality at home where I can more easily keep track of their activities.

If you want to be able to monitor without imposing explicit controls — in other words, trust but verify — then it’s worth knowing about the feature of Windows Vista that supports that preference. It’s in Control Panel -> User Accounts and Family Safety -> Parental Controls. There are two On/Off choices. The first, Parental Controls, enforces any of the controls you elsewhere define. These include restrictions about which websites are accessible, when the computer may be used, and which games or other programs may be used.

My strategy is to leave Parental Controls off, but switch on the second On/Off choice: Activity Reporting. That produces a detailed report about which websites were visited, which applications were used when, which games were played, messages sent/received and contacts added (if the kids use Outlook and Windows Messager, which mine don’t), and more.

The crucial item here, for me, is websites visited. That’s recently become an issue that I want to keep an eye on. With this setup I can, in a way that’s browser-independent, persistent across flushes of the browser cache, and very unlikely to be disabled.

Windows XP and Mac OS X don’t offer the same capability out of the box, but there are of course lots of third-party add-ons. Not ever having tried them myself, I’d be interested to hear how effectively they can be used to implement a “trust but verify” policy. And more generally, I’d be interested to hear about how other parents of teenagers are dealing with the difficult tradeoffs involved in this thorny issue.