Losing Control and Loving It

Over in Adaptive Path land, Todd Wilkins called out to User Experience (UEx) practitioners to reconsider the prevailing design model of tasks, goals, and situations. His assertion is that this framework falls short of delivering value since it doesn’t really mesh with how users experience the world. In its place, he offers an alternative perspective: one that would address meaning and culture via a focus on behaviors, motivations, and contexts. I won’t chance misrepresenting his words completely–you can read them for yourself over at the AP blog. G’head, I’ll wait.

While it may not have been Todd’s complete intent, his point about accommodating systems “…with multiple touchpoints…and the need for consistent and complementary interfaces…” leads to an interesting situation concerning XML-derived feeds, open APIs, and other technologies that blur the boundary of Our System versus Other Systems. We see this in the young, but growing popularity and approachability of mashup technology. Non-techies are increasingly adding Flickr streams, del.icio.us links, and YouTube videos into their weblogs, feed aggregators, and MySpace profiles.

What’s compelling about this in terms of UEx? For one thing, it means the experience we strive to maintain is expanding outside of our absolute zone of control. We can try to accommodate user goals within the sandbox of our own sites. As we publish content to other subscribers through raw XML, basic APIs, and the prefab widgets, we begin to lose control over how it is being integrated and used. Drawing a dividing line between us and them is one recourse, but one that is shortsighted. That stance presumes that the users’ experience with our systems ends when they leave our site. Should they decide to incorporate our data feeds, well then, caveat emptor. Well, that’s not the best approach to take since our responsibility migrates along with the content.

There is an alternative which permits us to extend our zone of influence and, perhaps, distinguish ourselves in the process. Actually, it’s already being used in a few choice places; YouTube is one. Many users experience this video sharing service not from being on YouTube.com, but through interacting with the video widgets it allows users to embed it on any other site. This allows users to repurpose the content, contextualizing it along the way. Embracing this behavior, YouTube created an affordance to readily share the video from within the embedded player. In a nutshell, it provides a complementary interface to their main site and allows YouTube to better manage the experience alongside the content.

The UEx practice should remember look outward and keep in mind how the published content plays with people’s lives. We need to proactively seek out how users employ our content away from our control zone. In doing so, there is an opportunity to differentiate our products. By emphasizing the experience at the touchpoints–our apis, feeds, and widgets–we can provide more value to the user and increase our chances of success.

Smallr Apps

It seems everyone is heralding the arrival of smaller, more focused applications–often ones that are available online. Jon Udell, in an InfoWorld post, makes a comparison to Unix and its history of lightweight apps that do one thing, and do it well.

I want to agree with that comparison but there’s one nagging issue. Unix provides an environment where it is fairly trivial to assemble the pieces into something useful. For relatively literate users, there is a shallow hurdle to creating a novel script by piping output from one app to the input of another.

XML-based formats are providing us the groundwork (namely a readily parseable) way of sharing data all around. What is lacking is a environment to tie these together. Content aggregators and “paste-in” code widgets only superficially provide us with useful integration–and that’s usually only at the presentation layer. Developer APIs and Greasemonkey get us a bit further, as evidenced by the flurry of mashups, but still impose a steep learning curve on the user. In addition, these tend to require a lot of footwork and don’t lend themselves to creating one-off, disposable interfaces.

The small and focused unix apps owe much of their success to having a readily accessible means to chain them together and produce something more useful. The unix world has the data pipe: how could this metaphor be extended to these small online apps? How could we wire things together easily, and in ways not directly afforded by the widget creators and API developers?

I’m bullish on YubNub, a “social command line” for the web. It provides a relatively disposable method of working with content in a lightweight manner by hacking GET query strings. YubNub’s still in its formative stages so I can’t knock it for being a bit arcane to the average person. However, Lazyweb, I’m still searching for something like Apple’s Automator, which provides a set of prebuilt data query and transformation services in a “drag-and-chain” environment.

Add Another Card? C’mon Paypal.

Every now and then, I encounter such bizarre interaction behavior that I feel compelled to write about it. So begins a tirade against Paypal. I’ve used Paypal as my payment broker once in the past without any issues. In fact, before was pretty smooth and I came away feeling shiny, happy even.

This second round should have gone easier right? After all, they had my payment information. I expected to probably spot check the account info I entered before, maybe entering the 3 digit number on the back of the card. That wasn’t the case, however.

After I picked Paypal as my service broker, I logged in expecting to review my order and select a credit card to pay with. Expectations are deceiving and I was immediately directed to “Add Another Funding Source.” Umm, ok, well maybe if I enter in my card info again, then Paypal will let me through.

Nope.

Paypal noticed that I tried to add an existing card and asked me again to enter a new card. What’s the problem? They didn’t provide me the ability to pay with that one. That “friendly” error message was hardly so. If they know I’m typing in an existing account, couldn’t they at least infer that I might want to use that one? Or at least give me the option? Hell, it’s in their best interest to, oh I don’t know, get me to route money through them. It’s how they make money. I bet Paypal’s sales and marketing wonks even have customer conversion as a performance metric.

So what happened? After thoroughly considering sidestepping Paypal, I gave up and added another card to Paypal and completed the transaction[1]. Oh did I mention that backtracking through the screens got me worried that I might be paying for this machine twice, three, four times even?

Why Paypal presumed that an existing account holder, hooked up to a valid card, would want to add another card as the default action is beyond me. Further, it’s beyond me that they couldn’t even offer up a “Pay with MasterCard ****-****-****-1234” option.

The cynical beast in me believes that this is some ploy to coax more credit card information from its users. Given that Paypal is predisposed to hijacking user expectations by placing whole page ads in many process flows[2], I wouldn’t be surprised.

[1] I wanted the espresso machine yesterday, which didn’t seem likely to happen by contacting the seller. Advantage Paypal.
[2] When trying to view my account information to see whether I had overpaid, I had to navigate through “speedbump” pages that advertised loans and the ilk.

*tap, tap, tap. Koff.*

Is this thing on? Good. I’ll keep this intro short and sweet - this blog is about all things user experience. That’s a broad term and can cover lots of things from design to development to psychology. That’s a good thing; cross-pollination is a good thing and I expect to sample heavily from other fields. There are many other excellent user experience sites out there that reserve a steely focus for their pure UX content. Oomblog is different–I want to revisit the discipline with an bias toward those connections that haven’t been made or haven’t been well socialized.