Also take a look at the rest of my mockups (view as a slideshow) or visited the project overview.

. . .

When was the last time you created a new username and password so that you could make use of some website? Do you remember what username you picked, or which email address you used to sign up? Probably. But what about that support forum that you signed up for a couple weeks ago while you were home for the holidays? Did you write it down somewhere? Or worse: did you just use the same username and password that you use everywhere else?

Spreadsheets, text files, sticky notes, cheat-sheets, software and browser extensions — you name it, people have probably found some way to recruit every kind of notational tool there is to help them remember the countless passwords, PINs, IDs, usernames, and secrets needed to access the apps, websites, and services that they use on a regular basis. But we can do better.

Step 1: Activate

The social agent is designed to unify your online social experience. With that in mind, a social agent must become an extension of you in order to mediate your online interactions.

This is achieved by activating your browser against your preferred account provider when you first begin your online session, just as you activate your mobile phone before being able to make or receive calls. This is how the browser is turned into a social agent.

By activating your browser, you are effectively telling your browser who you are and where to store and access your data online.

Fortunately, you can activate using any account that you already have that supports a Connect API, like Twitter Connect or Facebook Connect (or soon, OpenID Connect). It is also conceivable to use the browser in an anonymous or “incognito mode”.

Step 2: Connect

Once activated, you can visit any site that supports Connect and with the click of a button, sign up and bring your profile, relationships, content, activities, and any other portable data with you. This process is identical to Facebook Connect or Twitter Connect, except that the interaction occurs between your social agent and the site you’re visiting.

What is a Connect API? Writing for the O’Reilly Radar blog in February last year, David Recordon defined the anatomy of “connect” as meeting four criteria:

• Profile: Everything having to do with identity, account management and profile information ranging from sign in to sign out on the site I’m connecting with.
• Relationships: Think social graph. Answers the questions of who do I know, who do I know who’s already here, and how I can invite others.
• Content: Stuff. All of my posts, photos, bookmarks, video, links, etc that I’ve created on the site I’ve connected with.
• Activity: Poked, bought, shared, posted, watched, loved, etc. All of the actions that things like the Activity Streams project are starting to take on.

This is what the verb “connect” means for the social agent. The “connect” button communicates that your browser is going to share some amount of your profile data with the site that you’re connecting with. You’re not just signing in. You’re connecting — and creating a relationship with the site. You can of course change the data that the website gets — even after you’ve signed in — and the benefit of this model is that you have transparency into what data you’re sharing with whom.

Far from making it impossible for you to share your data, your social agent should help you mediate such decisions, guiding you about which sites to connect with, and providing context to help inform you actions.

For this model to work, your connections are actually made between your preferred account provider and the third parties to which you’ve connected. Your account provider, then, acts as a hub for all of your online doings — collecting, maintaining, and mediating your browsing history, relationships and contacts, activities, transactions, content and media, and online profile. This provider should let you selectively configure how much, how little, or how long such your data is made available to third parties — much in the same way that you manage access on Twitter or Facebook today.

For you, this means that you get to pick an account provider of your choice — without needing to worry about remembering or managing passwords or usernames. Instead, you can have any number of accounts that are available to you wherever the web goes.

As a core feature of the social agent, connecting is the action you take whenever you want to establish an enduring an ongoing relationship with a site, service, or individual.

And this disaster still unfolds, with scores pitching in — many turning to the social web and social media to facilitate or amplify their efforts.

One such effort is being lead by Project EPIC, a collection of information scientists, computer scientists and computational linguists at the University of Colorado at Boulder and the University of California, Irvine.

Their initiative, called Tweak the Tweet, provides a dictionary of hashtags for reporting on issues on the ground in Haiti and calling for aid. Here are templates for using their syntax:

I applaud their efforts and desire to help people communicate their status in a way that facilitates machine-processing. I worry, however, that this approach may limit its success.

Hashtags are metadata for humans first, machines second

The original need for hashtags came from the lack of any formal or public grouping mechanism in Twitter.

For example, when half of Silicon Valley went to SXSW and tweeted for days on end about this speaker or that panel, those who weren’t at the conference desperately wanted some way to filter out such noise. I proposed the hashmark (#) as a way of adding context to a tweet, so that people could choose for themselves to filter out or follow tweets tagged with certain keywords. In July last year, Twitter decided to hyperlink hashtags to their respective search results, and the format became widely adopted — more often than not used to game the trending topics on Twitter’s homepage.

Initially, most people thought hashtags were ugly and useless; even the folks at Twitter thought that they were unnecessary because they’d eventually develop natural language processing algorithms that would supersede the need manual tagging. Contrary to initial complaints about their complexity, hashtags become easier to understand and use with repeated exposure and practice because they are so transparent: if you see someone use a hashtag, you know how to use a hashtag.

And so three years later, hashtags still serve a role in helping people express themselves to each other.

Keep it simple, make it memorable

Language is inherently mutable; mathematics (the language of machines) is not. Verbal language can be adapted by a speaker, and what is heard (or read) is itself interpreted; the conversion is never digital, and invariably bears some loss of meaning.

But using hashtags to clarify meaning prioritizes the needs of the machine over the capabilities of the individual.

Such imposed order in a networked environment can succeed, but only if it achieves instant, widespread adoption, and is itself superficial (that is, it doesn’t require deep knowledge to understand or use the new order). In contrast, simpler, smaller and emergent structures tend to fare better over time, but developing them is not easy (see also: slashtags).

Successful structures should also aim for minimal cognitive burden — by being easy to remember and recall in practice. I’ve frequently seen people tweet about how they “forget to use hashtags” in posts — which is not surprising, since most people don’t think about the metadata of what they say. Hashtags and slashtags are most useful, therefore, when you want to provide additional context that is harder to express otherwise.

Learning from previous efforts

The Tweak the Tweet project introduces a “new order” for using Twitter. Though the words it calls out are mostly common, the use of the hashmark seems gratuitous, given the limited length of the medium (something that Stowe Boyd points out) and that the hashed words comprise the meat of the message, rather than the meta. To give you an example, this is Tweak-the-Tweet formatted post (77 characters):

#haiti #offering #volunteers #translators #loc Florida #contact @FranceGlobal

The same message could be reformatted to be human-readable without any loss of meaning (72 characters):

Offering volunteer translators in Florida. Contact @FranceGlobal. #haiti

While the message may not be as machine-friendly, it may reach a wider (human) audience available to respond to this offer.

Now, I don’t want to dismiss this effort, but instead provide a word of caution on focus. Tweak the Tweet is not the first hashtag pidgin language I’ve seen — and previous efforts struggled to gain adoption and awareness. Perhaps by minimizing the metadata and maximizing the meat, the effort poured into this might achieve a greater effect.

Paving the cowpaths and bulldozing fields

#sandiegofire

Hashtags may never have taken off if it weren’t for Nate Ritter tweeting about the San Diego forest fire in 2007. In fact, his use of the hashtag was the first dedicated use of a hashtag to help coordinate a response to a natural disaster:

What’s important about his use of hashtags in this case was that he was using them to communicate critical information to people in natural language. His use of the hashtag provided additional context to his followers who weren’t in San Diego, and also modeled a behavior that others could easily emulate when reporting their own news.

When I proposed using #sandiegofire as the hashtag for Nate to use, I first looked at what people were already using the tag their photos of the event on Flickr. At the time, the sandiegofire was one of the trending tags, and that’s how I chose it:

Had I tried to come up with my own new phrase for the event, Nate’s use of the tag may not have been picked up. #sandiegofire was also better than the alternatives, which were more localized and therefore more obscure to the broader audience. Using “SanDiego” in the tag itself helped bring clarity and context to Nate’s tweets.

Using hashtags effectively means considering the audience and their familiarity with the issue being tweeted about. While tagging lets you be as esoteric as you want, it may limit the reach of your effort, whereas paving the cowpaths means that you build on the familiar and connect with what people already know, reducing friction and inviting contribution.

iList with #ihave and #iwant

iList is an interesting service that originally aimed to take on eBay and Craigslist by leveraging social media. More recently they decided to narrow their efforts to focus on hashtag-based listings and Twitter search. Nonetheless, what I think is interesting about their approach is that it is, on the surface, quite simple.

To use the service, you just tag your tweet with #ihave or #iwant. If you want to get more detailed, you can add your zip code or categories like #forsale or #electronics. But the core service relies on using just two tags which seem to be have moderate usage — proving that getting adoption is always the hard part of any metadata-based communication strategy.

Twitter Vote Report#votereport

The last example is very similar to Tweak the Tweet and was launched by some friends of mine. The Twitter Vote Report project was designed to enable citizens to report on their local voting situation by using a series of hashtags:

• #[zip code] to indicate the zip code where you’re voting; ex., “#12345?
• L:[address or city] to drill down to your exact location; ex. “L:1600 Pennsylvania Avenue DC”
• #machine for machine problems; ex., “#machine broken, using prov. ballot”
• #reg for registration troubles; ex., “#reg I wasn’t on the rolls”
• #wait:[minutes] for long lines; ex., “#wait:120 and I’m coming back later”
• #early if you’re voting before November 4th
• #good or #bad to give a quick sense of your overall experience
• #EP[your state] if you have a serious problem and need help from the Election Protection coalition; ex., #EPOH

All tags were optional except the #votereport tag.

They also went through painstaking effort to mobilize people and provide alternative means to participate. They also did a good deal of work to report back their findings in real time (most visualizations appear to be offline) and open sourced their codebase.

They also made sure to make it possible to participate without using Twitter — the hashtags were just a mechanism for getting data into the system.

Design for adoption, stay focused

Around the time it launched, Ethan Zuckerman expressed skepticism about whether Twitter was the appropriate tool for the vote report project, in much the same way I’m wondering whether Tweak the Tweet could take a more focused approach in exchange for wider participation to achieve its goals.

My greatest concern is that there won’t be enough people who can “speak” the “tweaked” syntax, leading to a lot of effort spent building parsers that will be data-starved. While trained volunteers might be able to use this syntax effectively, I wonder if there aren’t alternative approaches that could use the existing corpus of text messages and tweets coming out of Haiti (which probably aren’t geo-coded, unfortunately) to discern the typing patterns that people use naturally in order to facilitate adoption? Perhaps by focusing on fewer tags that are self-evident in their meaning and use, it is possible that this effort could be used to model the proper usage of the tags, making a more direct difference while there’s still time? Unless the audience of this effort is expert users, I’d suggest steering towards simplicity and ease of adoption — and being mindful that typing out a complicated machine-friendly syntax might be the last thing on someone’s mind who’s trying to find or offer help in such a disaster.

While you could chalk up the effect of the video to clever editing, I’ve seen similar videos that suggest that the attitudes expressed are probably a pretty accurate portrayal of how some people think (and, for the purposes of this essay, I’m less interested in what they think).

It seems to me that the people in the video largely think with their guts, and not their brains. I’m not making a judgment about their intelligence, only recognizing that they seem to evaluate the world from a different perspective than I do: with less curiosity and apparent skepticism. This approach would explain George W Bush’s appeal as someone who “lead from the gut“. It’s probably also what Al Gore was talking about in his book, Assault on Reason.

Many in my discipline (design) tend to think of the consumers of their products as being rational, thinking beings &emdash; Not unlike themselves. This seems worse when it comes to engineers and developers, who spend all of their thinking time being mathematically circumspect in their heads. They exhibit a kind of pattern blindness to the notion that some people act completely from gut instinct alone, rarely invoking their higher faculties.

How, then, does this dichotomy impact the utility or usability of products and services, especially those borne of technological innovation, given that designers and engineers tend to work with “information in the mind” while many of the users of their products operate purely on the visceral plane?

In writing about the death of the URL, I wanted to expose some consequences of this division. While the intellectually adventuresome are happy to embrace or create technology to expand and challenge their minds (the popularity and vastness of the web a testament to that fact), anti-intellectuals seem to encounter technology as though it were a form of mysticism. In contrast to the technocratic class, anti-intellectuals on the whole seem less curious about how the technology works, so long as it does. Moreover, for technology to work “well” (or be perceived to work well) it needs to be responsive, quick, and for the most part, completely invisible. A common sentiment I hear is that the less technology intrudes on their lives, the better and happier they believe themselves to be.

So, back to the death of the URL. As has been argued, the URL is ugly, confusing, and opaque. It feels technical and dangerous. And people just don’t get them. This is a sharp edge of the web that seems to demand being sanded off — because the less the inner workings of a technology are exposed in one’s interactions with it, the easier and more pleasurable it will be to operate, within certain limitations, of course. Thus to naively enjoy the web, one needn’t understand servers, DNS, ports, or hypertext — one should just “connect”, pick from a list of known, popular, “destinations”, and then point, click — point, click.

And what’s so wrong with that?

What I find interesting about the social web is not the technology that enables it, but that it bypasses our “central processor” and engages the gut. The single greatest thing about the social web is how it has forced people to overcome their technophobias in order to connect with other humans. I mean, prior to the rise of AOL, being online was something that only nerds did. Few innovations in the past have spread so quickly and irreversibly, and it’s because the benefits of the social web extend beyond the rational mind, and activate our common ancestors’ legacy brain. This widens the potential number of people who can benefit from the technology because rationality is not a requirement for use.

Insomuch as humans have cultivated a sophisticated sociality over millennia, the act of socializing itself largely takes place in the “gut”. That’s not to say that there aren’t higher order cognitive faculties involved in “being social”, but when you interact with someone, especially for the first time, no matter what your brain says, you still rely a great deal on what your gut “tells you” — and that’s not a bad thing. However, when it comes to socializing on sites like Twitter and Facebook, we’re necessarily engaging more of our prefrontal cortex to interpret our experience because digital environments lack the circumstantial information that our senses use to inform our behavior. To make up for the lack of sensory information, we tend to scan pages all at once, rather than read every word from top to bottom, looking for cues or familiar handholds that will guide us forward. Facebook (by name and design) uses the familiarity of our friends’ faces to help us navigate and cope with what is otherwise typically an information-poor environment that we are ill-equipped to evaluate on our own (hence the success of social engineering schemes and phishing).

As we redesign more of our technologies to provide social functionality, we should not proceed with mistaken assumption that users of social technologies are rational, thinking, deliberative actors. Nor should we be under the illusion that those who use these features will care more about neat tricks that add social functionality than the socialization experience itself. That is, technology that shrinks the perceived distance between one person’s gut and another’s and simply gets out of the way, wins. If critical thinking or evaluation is required in order to take advantage of social functionality, the experience will feel, and thus be perceived, as being frustrating and obtuse, leading to avoidance or disuse.

Given this, no where is the recognition of the gut more important than in the design and execution of identity technologies. And this, ultimately, is why I’m writing this essay.

It might seems strange (or somewhat obsessive), but as I watched the Sarah Palin video above, I thought about how I would talk to these people about OpenID. No doubt we would use very different words to describe the same things — and I bet their mental model of the web, Facebook, Yahoo, and Google would differ greatly from mine — but we would find common goals or use cases that would unite us. For example, I’m sure that they keep in touch with their friends and family online. Or they discover or share information — again, even if they do it differently than me or my friends do. Though we may engage with the world very differently — at root we both begin with some kind of conception of our “self” that we “extend” into the network when we go online and connect with other people.

The foundation of those connections is what I’m interested in, and why I think designing for the gut is something that technocrats must consider carefully. Specifically, when I read posts like Jesse Stay’s concept of a future without a login button, or evaluate the mockups for an “active identity client” based on information cards or consider Aza and Alex’s sketches for what identity in the browser could look like, I try to involve my gut in that “thought” process.

Now, I’m not just talking about intuition (though that’s a part of it). I’m talking about why some people feel “safer” experiencing the web with companies like Google or Facebook or Yahoo! at their side, or how frightening the web must seem when everyone seems to need you to keep a secret with them in order to do business (i.e. create a password).

I think the web must seem incredibly scary if you’re also one of those people that’s had a virus destroy your files, or use a computer that’s still infected and runs really slow. For people with that kind of experience as the norm, computers must seem untrustworthy or suspicious. Rationally you could try to explain to them what happened, or how the social web can be safe, but their “gut has already been made up.” It’s not a rational perception that they have of computers, it’s an instinctual one — and one that is not soon overcome.

Thus, when it comes to designing identity technologies, it’s very important that we involve the gut as a constituent of our work. Overloading the log in or registration experience with choice is an engineer’s solution that I’ve come to accept is bound to fail. Instead, the act of selecting an identity to “perform as” must happen early in one’s online session — at a point in time equivalent to waking up in the morning and deciding whether to wear sweatpants or a suit and tie depending on whatever is planned for the rest of the day.

Such an approach is a closer approximation to how people conduct themselves today — in the real world and from the gut — and must inform the next generation of social technologies.

I’ve probably said it before, and will say it again, and I’m also sure that I’m not the first, or the last to make this point, but I have yet to see an example of an open source design process that has worked.

Indeed, I’d go so far as to wager that “open source design” is an oxymoron. Design is far too personal, and too subjective, to be given over to the whims and outrageous fancies of anyone with eyeballs in their head.

Lately, I’m feeling the acute reality of this sentiment.

In 2005, I wrote about how I wanted to take an “open source” approach to the design of Flock by posting my mockups to Flickr and soliciting feedback. But that’s more about transparency than “open source”. And I think there’s a big difference between the two that’s often missed, forgotten or ignored altogether: one refers to process, the other refers to governance.

Design can be executed using secretive or transparent processes; it really can’t be “open” because it can’t be evaluated in same way “open source” projects evaluate contributions, where solutions compete on the basis of meritocratic and objective measures. Design is sublime, primal, and intuitive and needs consistency to succeed. Open source code, in contrast, can have many authors and be improved incrementally. Design — visual, interactive or conceptual — requires unity; piecemeal solutions feel disjointed, uncomfortable and obvious when end up in shipping product.

Luke Wroblewski is an interaction designer. He recently made an observation about “openness” that really resonated with me:

I read this quote last week and realized it is symptomatic of a common assertion that in technology (and especially the Web) “completely open” is better than “controlled”.

“But we’ll all know exactly where Apple stands – jealously guarding control of their users [...] And that’s not what Apple should be about.” -TechCrunch

Sorry but Apple makes their entire living by tightly controlling the experience of their customers. It’s why everyone praises their designs. From top to bottom, hardware to software -you get an integrated experience. Without this control, Apple could not be what it is today.

He followed up with a post on Facebook’s design process today that I also found exceedingly compelling.

I worry about Mozilla in this respect — and all open source projects that cater to the visible and vocal, ignoring the silent or unengaged majority.

I worry about OpenID similarly — an initiative that will be essential for the future of the social web and yet is hampered by user experience issues because of an attachment to fleeting principles like “freedom” and “individual choice”. Sigh.

I’m not alone in these concerns.

When it comes to open source and design, design — and human factors, more generally — cannot play second fiddle to engineering. But far too often it seems that that’s the case.

And it shouldn’t be.

More often there should be a design dictator that enters into a situation, takes stock of the set of problems that people (read: end users) are facing, and then addresses them through observation, skill, intuition, and drive. You can evaluate their output with surveys, heuristics, and user studies, but without their vision, execution, and insane devotion to see through making it happen, you’ll never see shit get done right.

As Luke says, Most people out there prefer a great experience over complete openness.

I concur. And I think it’s critical that “open source” advocates (myself included) keep that at top of mind.

. . .

I will say this: I’m an advocate for open source and open standards because I believe that open ecosystems — i.e. those with low barriers to entry (low startup costs; low friction to launch; public infrastructure for sustaining productivity) — are essential for competition at the level of user experience.

It may seem paradoxical, but open systems in which secretive design processes are used can result in better solutions, overall.

Thus when I talk about openness, I really mean openness from an economic/competitive perspective.

. . .

Early today I needed access to a client’s internal wiki. Having gone without access for a week, I decided to toss up a project on Basecamp to get things started.

When I presented my solution to the team, I was told that we needed to use something open source that could be hosted on their servers. Somewhat taken aback, I suggested Basecamp was the best tool for the job given our approaching deadline..

“No, no, that won’t do,” was the message I got. “Has to be open source. Self-hosted.”

I asked them for alternatives. “PHProjekt“. Double Choco Latte. I proposed Open Atrium.

Once again, as seems all too common lately, more time was devoted to picking a tool rather than producing solutions. More meta than meat. Worst of all, religion was in the driver’s seat, rather than reality. Where was that open source pragmatism I’d heard so much about?

Anyway, not how I want to begin a design process.

Ultimately, I got the access I needed — to MediaWiki. So, warts and all, we’ll be using that to collaborate. On a closed intranet.

In the back of my head, I can’t help but fear that the tools used for design collaboration bleed into the output. To my eyes, MediaWiki isn’t a flavor that I want stirred into the pot. And it begs the question once and for all: what good can “open source” bring to design if the only result is the product of committee dictate?

But, pray tell, how do you learn about or solicit such information over the course of your first interaction? Moreover, how do you go about learning as much as you can, as quickly as you can, without making the request itself burdensome and off-putting?

Well, as obvious as it seems, the answer is to let her tell you.

The less obvious thing is how.

And that’s where user-centric (or citizen-centric) technologies offer the most promise.

It’s like this:

• If you let someone use an account or ID that they already use regularly elsewhere, you will save them the hassle of having to create yet another account that works solely with your service;
• following on that, an account that is reusable is more valuable, and its value can be further increased by attaching certain types of profile attributes to it that are commonly requested;
• the more common it becomes to reuse an account, the more people will expect this convenience during new sign up experiences, ideally to the point of knowing how to ask for support for their preferred sign-in mechanism from the services that they use;
• presuming that service providers’ desire for profile information and preferences will not decrease, it will become an added byproduct of user-centric authentication to be able to import such data from identity providers as it is available;
• as customers realize the convenience of portable profile and preference data, savvy identity providers will make it easier to store and express a wider array of this data, and will subsequently work with relying parties to develop interoperable sign up flows and on ramps (see Google and Plaxo).

For this to work, the individual must be motivated to manage her profile information and preferences, which shouldn’t be hard as her data becomes increasingly reusable (sort once, reuse everywhere). Additionally, organizing, maintaining, and accruing this information becomes less onerous when it’s all in one place (or conveniently accessible through one central customer-picked source), as opposed to sharded across many accounts and unaffiliated services.

You can get similar functionality with form-filling software like 1Password except in the model I’m describing, the data travels with you — beyond the browser and off the desktop — to wherever you need it — because it is stored in the cloud.

As it becomes easier to store and share this information, I think more people will do this as a happenstance of using more social software — and will become acclimated to providing their friends and service providers with varying degrees of access to increasing amounts of personally describing data.

Companies that jump on this and make it easier for people to manage their profile and preference data will benefit — having access to more accurate, timely, and better-maintained information, leading to more personalized user experiences and accelerating the path to satisfaction.

Companies that do get this right will benefit from what is emerging as a new social contract. As a citizen of the web, if you let me manage my relationship with you, and make it easy for me to do so, giving me the choice of how and where I store my profile and preference data, I’ll be more likely, more willing, and more able to share it with you, in an ongoing fashion, increasingly as you use it to improve my experiences with you.

Arrington has a post that claims that Facebook is getting wise to something MySpace has known from the start – users love vanity URLs.

I don’t buy it. In fact, I’m pretty sure that the omission of vanity URLs on Facebook is an intentional design decision from the beginning, and one that I’ve learned to appreciate over time.

From what I’ve gathered, it was co-founder Dustin Moskovitz’s stubbornness that kept Facebook from allowing the use of pseudonymic usernames common on previous-generation social networks like AOL. Considering that Mark Zuckerberg’s plan is to build an online version of the relationships we have in real life, it only makes sense that we should, therefore, call our friends by their IRL names — not the ones left over or suggested by a computer.

But there’s actually something deeper going on here — something that I talked about at DrupalCon — because there are at least two good uses for letting people set their own vanity URLs — three if your service somehow surfaces usernames as an interface handle:

1. Uniqueness and remembering
2. Search engine optimization
3. Facilitating member-to-member communication (as in the case of Twitter’s @replies)

For my own sake, I’ve lately begun decreasing the distance between my real identity and my online persona, switching from @factoryjoe to @chrismessina on Twitter. While there are plenty of folks who know me by my digital moniker, there are far more who don’t and shouldn’t need to in order to interact with me.

When considering SEO, it’s quite obvious that Google has already picked up on the correlation:

Ironically, in Dustin’s case (intentionally or not) he is not an authority for his own name on Google (despite the uniqueness of his name). Instead, semi-nefarious sites like Spock use SEO to get prominent placement for Dustin’s name (whether he likes it or not):

Finally, in cases like Twitter, IM or IRC, nicknames or handles are used explicitly to refer to other people on the system, even if (or especially if!) real identities are never revealed. While this separation can afford a number of perceived benefits, long-term it’s hard to quantify the net value of pseudonymity when it most assholes on the web seem to act out most aggressively when shrouding their real names.

By shunning vanity URLs for its members, Facebook has achieved three things:

1. Establishes a new baseline for transparent online identity
2. Avoids the naming collision problem by scoping relationships within a person’s [reciprocal] social graph
3. Upgrades expectations for human interaction on social websites

That everyone on Facebook has to use their real name (and Facebook will root out and disable accounts with pseudonyms), there’s a higher degree of accountability because legitimate users are forced to reveal who they are offline. No more “funnybunny345″ or “daveman692″ creeping around and leaving harassing wall posts on your profile; you know exactly who left the comment because their name is attached to their account.

Go through the comments on TechCrunch and compare those left by Facebook users with those left by everyone else. In my brief analysis, Facebook commenters tend to take their commenting more seriously. It’s not a guarantee, but there is definitely a correlation between durable identity and higher quality participation.

Now, one might point out that, without unique usernames, you’d end up with a bunch of name collisions — and you’d be right. However, combining search-by-email with profile photos largely eliminates this problem, and since Facebook requires bidirectional friendship confirmation, it’s going to be hard to get the wrong “Mike Smith” showing up in your social graph. So instead of futzing with (and probably forgetting) what strange username your friend uses, you can just search by (concept!) their real name using Facebook’s type-ahead find. And with autocompletion, you’ll never spell it wrong (of course Gmail has had this for ages as well).

Let me make a logical leap here and point out here that this is the new namespace — the human-friendly namespace — that Tim O’Reilly observed emerging when he defined Web 2.0, pointing out that a future source of lock-in would be “owning a namespace”. This is why location-based services are so hot. This is also why it matters who gets out in front first by developing a database of places named by humans — rather than by their official names. When it comes to search, search will get better when you can bound it — to the confluence of your known world and the known/colloquial world of your social graph.

When I was San Diego a couple weeks back, it dawned on me that if I searched for “Joe’s Crab Shack”, no search engine on earth would be able to give me a satisfying result… unless it knew where I was. Or where I had been. Or, where my friends had been. This is where social search and computer-augmented social search becomes powerful (see Aardvark). Not just that, but this is where owning a database of given names tied to real things becomes hugely powerful (see Foursquare). This is where social objects with human-given names become the spimatic web.

So, as this plays out, success will find the designer who most nearly replicates the world offline online. Consider:

vs:

and:

vs.

Ignoring content, it seems to me that the latter examples are much easier to grok without knowing anything about Facebook or Twitter — and are much closer approximations of real life.

Moreover, in EventBox, there is evidence that we truly are in a transitional period, where a large number of people still identity themselves or know their friends by usernames, but an increasing number of newcomers are more comfortable using real names (click to enlarge):

We’re only going to see more of this kind of thing, where the data-driven design approach will give way to a more overall humane aesthetic. It begins by calling people by the names we humans prefer to — and will always — use. And I think Facebook got it right by leaving out the vanity URLs.

That PayPal has joined is certainly good news, and helps to diversify the types of companies sitting on the OpenID Foundation board (PayPal joins Google, IBM, Microsoft, VeriSign and Yahoo!). It also provides a useful opportunity to think about how OpenID could be useful (if not essential) for financial transactions on the web.

For one thing, PayPal already relies on email addresses for identification, and one of the things that I’m strongly advocating for in OpenID 2.1 is the use of email-style identifiers in OpenID flows.

Given that PayPal already assumes that you are your email address, things become more interesting when a company like PayPal starts to assume that you are your OpenID (regardless of the format). With discovery, your OpenID could be useful not just as an indicator of your data resources across the web (essential in cloud computing), but could also be useful for pointing to your financial resources. Compare these two XRDS-Simple entries (the latter is fictional):
[sourcecode language='xml']


http://portablecontacts.net/spec/1.0
http://pulse.plaxo.com/pulse/pdata/contacts

http://portablepayments.net/spec/1.0
http://paypal.com/payment/

[/sourcecode]
From this simple addition to your discovery profile, third parties would be able to request authorization to payment, without necessarily having to ask you every time who your provider is. And of course no payment would be disbursed without your explicit authorization, but the point is — sellers would be able to offer a much more seamless payment experience by supporting OpenID and discovery.

The pieces are more or less in place here, and with PayPal on board, I think that we’re starting to see how OpenID can be used to smooth the on-boarding process for any number of routine tasks — from specifying where you store your photos to pointing to the service(s) that you use for payment.

I commonly use the metaphor of credit cards for OpenID. One thing that makes credit cards convenient is that the 16-digit unique ID on each card is embedded in the magnetic strip, meaning that it’s trivial for consumers to just swipe their cards rather than typing in their account number. OpenID and discovery, combined, provides a similar kind of experience for the web. I think we need to keep this in mind as we move the state of the art forward, and think about what can be accomplished once people not only have durable identity on the web — but can use those identifiers to access other forms of real-world value (and can secure them however they see fit).

I’ve written about the password anti-pattern before, and have, with regards to Twitter, advocated for the adoption of some form of delegated authentication solution for some while.

It’s not as if Twitter or lead developer Alex Payne aren’t aware of the need for such a solution (in fact, it’s not only been publicly recognized (and is Issue #2 in their API issue queue), but the solution will be available as part of a “beta” program shortly). The problem is that it’s taken so long for Twitter’s “password anti-pattern” problem to get the proper attention that it deserves (Twitter acknowledged that they were moving to OAuth last August) that unsuspecting Twitter users have now exposed themselves (i.e. Twitter credentials) to the kind of threat we knew was there all along.

This isn’t the first time either, and it probably won’t be the last, at least until Twitter changes the way third party services access user accounts.

Rather than focus on Twply (which others have done, and whose evidence still lingers), I thought I’d talk about why this is an important problem, what solutions are available, why Twitter hasn’t adopted them and then look at what should happen here.

Why the password anti-pattern matters

I can’t link directly to it, but comment #8 on Fred Oliveira’s post captures one clear reason why the password anti-pattern increasingly matters more:

Regardless of the perceived value of the service, when it comes to reputation online, little else matters than one’s accumulated social and data capital. Some people store their data capital (essentially original content coupled with residue from their social capital) with LinkedIn; others, Facebook or MySpace. Still others use their own blogs or rely on a medly of services like Twitter, FriendFeed, or Flickr.

To some degree, experimentation with third party services can elevate one’s status, drive commerce, or provide a recommendation filter for friends. So handing over the keys to the vault that stores your data capital should be a big deal.

The more frequently we do this, the more routine it becomes, the more we become desensitized to the inherent risks in this behavior. And so we take it for granted that we must cough up a username and password in order to try out that new shiny service, given the countless times previously where nothing bad happened. And then you get Twply. Or Quechup.

Now, phishing works in a similar way, but is distinctive in an important respect:

In the case of phishing, it’s kind of like a faux valet that stands outside a well-regarded restaurant waiting for unsuspecting victims to hand over the keys to their Benz (where that restaurant is your email account). Once a phisher gets a nibble, they position themselves as a known authority (i.e. your bank), preying on the naivete and disorientation of their victim. No where better is there than the web for such schemes, where the true value of account credentials are abstract and technical.

The difference between run-of-the-mill phishing and password anti-pattern cases is intent. Most third parties implement the anti-pattern out of necessity, in order to provide an enhanced service. The vast majority don’t do it to be malicious or because they intend to abuse their customers — quite the contrary! However, by accepting and storing customer credentials, these third parties are putting themselves in a potentially untenable situation: servers get hacked, data leaks and sometimes companies — along with their assets — are sold off with untold consequences for the integrity — or safety — of the original customer data.

Given the ends (providing cross-site functionality (importing address books, posting to blogs or Twitter, etc)), you could argue that the means are incidental or justified. But we can — and have an obligation to — do better.

Solutions for the password anti-pattern

Given the prevalence of this problem, several solutions have emerged, most notably OAuth.

OAuth is actually an extraction of a number of protocols that came before. In the place of a username and password, it substitutes a consumer key (like a username for an application) and a token, and adds a cryptographic signature to make sure that no one tampers with the “request envelope” while in transit.

Interestingly, OAuth emerged from a shortcoming with OpenID. Since OpenID authentication works without passwords, we needed a way for OpenID to be used with APIs and in desktop applications. Therefore, we needed a way to delegate authentication back to an original source, and then receive authorization to act on behalf of the user, all without ever needing their user credentials. Of course this problem wasn’t unique to OpenID, and so we developed it to be agnostic about how authentication is performed (that is, with or without OpenID).

Since its release just over a year ago, OAuth has replaced both Yahoo and Google’s custom delegated authentication protocols, and has become a central component of OpenSocial. More recently, Eran Hammer, the specification’s editor and lead author, brought OAuth to the IETF in order to advance the community-driven protocol to the next level of internet infrastructure. But it’s not the only solution to this problem.

FriendFeed implements what they call a Remote Key in place of a user’s password:

What’s a remote key?

A remote key is a kind of password that you can give to third-party applications and websites to let them interact with FriendFeed on your behalf. There are limits to what can be done using a remote key, which means it’s a lot safer than giving a site your FriendFeed password.

This idea was suggested to Twitter in November.

While there are benefits to this model — especially in terms of simplicity — it requires a user to remember two secrets: their password and their remote key. It also means that all third-party applications act at the same level of authority, since services can’t distinguish one application from another. For a service like FriendFeed, where most of the interactions seem to happen on-site, this model makes sense. For a service like Twitter, whose primary traffic comes from external sites and applications, it does not.

And then there’s the “security through obscurity” solution that provides access to data with single or limited use URLs that are usually so long and cryptic as to be virtually unguessable. This is the solution that Basecamp offers its OpenID users and that Flickr uses for its guest pass service.

Twitter and OAuth

Anything besides the standard username and password combo will arguably add complexity and confusion to the user experience of web apps and mashups (both for users and developers). Alex Payne made this point loud and clear:

Still, sooner than later, something is going to need to be done. And Twply is only the tip of the iceberg. As people continue to accrue social and data capital, we’re going to need to offer them better options for securing their accounts while providing them flexible and usable access. The sooner we start training people on the new model, the better off we’ll all be.

But Alex has additional gripes about OAuth:

The downside is that OAuth suffers from many of the frustrating user experience issues and phishing scenarios that OpenID does. The workflow of opening an application, being bounced to your browser, having to login to twitter.com, approving the application, and then bouncing back is going to be lost on many novice users, or used as a means to phish them. Hopefully in time users will be educated, particularly as OAuth becomes the standard way to do API authentication.

Another downside is that OAuth is a hassle for developers. BasicAuth couldn’t be simpler (heck, it’s got “basic” in the name). OAuth requires a new set of tools. Those tools are currently semi-mature, but again, with time I’m confident they’ll improve. In the meantime, OAuth will greatly increase the barrier to entry for the Twitter API, something I’m not thrilled about.

These are actually very good points.

At the same time, there’s a balance to be found between accepting the status quo (thereby promoting it) versus creating the solution. Alex has repeatedly referred to the work of the Twitter User Experience team as slowing down their adoption of OAuth, but it seems to me that there’s been an open opportunity to engage with the OAuth and OpenID communities to address these issues, especially as they are at the core of why Google has yet to become an OpenID relying party. These problems are not unique to Twitter and are issues that the entire community needs to address. As much as I’m a pain in the ass about OAuth support in Twitter, I am also willing to jump in and help develop solutions — but thus far, Twitter has been absent from the channels where solutions are being generated.

Everyone’s got their priorities and Twitter has come a long way in the past several months in terms of performance and stability. But in 2009, I want to defeat the password anti-pattern once and for all! Starting with Twitter would be a significant strategic achievement and I know that Twitter is game, it’s just matter of getting it done and making it happen.

So, Alex, where do we begin? What can we do to help?

Eric Sachs (Google Security Team) writes:

One other question that a lot of people asked yesterday is when a large provider like Google will become a relying party. There is one big problem that stands in the way of doing that, but fortunately it is more of a technology problem than a usability issue. That problem is that rich-client apps (desktop apps and mobile apps) are hard-coded to ask a user for their username and password. As an example, all Google rich-client apps would break if we supported federated login for our consumer users, and in fact they do break for the large number of our enterprise E-mail outsourcing customers who run their own identity provider, and for which Google is a relying party today. This problem with rich-client apps also affects other sites like Plaxo who are already relying parties.

Fortunately there is a solution, and it was developed specifically because Ma.gnolia ran into this problem when it became an OpenID relying party. The result, nine months in the making, was OAuth. Eric even recognizes this:

We need standard open-source components on as many platforms as possible to enable those rich-client apps to support OAuth. That includes a lot more platforms then just Windows and Mac. The harder part is mobile devices (Blackberry, Symbian, Windows Mobile, iPhone, and yes even Android), and other Internet connected devices like Tivos, Apple TVs, Playstations, etc. that have rich-client apps that ask users for their passwords to access services like Youtube, Google photos, etc. If we build these components, they will be useful not only to Google, but also to any other relying parties which have rich-client apps or exposes APIs, and it will also help enterprise SaaS vendors like Salesforce.

As I’ve been thinking about this problem, I’ve come to see as an intermediate approach to full-on delegated authorization a simpler, perhaps more familiar approach that would be relatively easy to implement given common interface patterns today. For comparison, Pownce’s iPhone app originally used out-of-band browser-based authentication, leading to a swarm of user criticism resulting in a compromised solution that required embedding a web browser in the app. Less than ideal.

In my proposal, rather than ask for a user’s password, an easier-to-remember OP-issued numerical PIN would be used to authenticate requests. Better is that this approach is already supported in OAuth, it’s just not widely used yet (though is similar to how Flickr authorizes mobile clients).

The basic concept is that you’d have one password (or other strong authentication method) for your primary OpenID account and you’d have one (or more) PINs that you would use to access your account remotely — perhaps in limited risk scenarios or where (again) the full browser-based OAuth flow is not possible or warranted.

Although I initially opposed FriendFeed’s use of Remote Keys, I now think that there’s some merit to this approach, as long as the underlying mechanism uses standard OAuth calls.

There are plenty of holes in this approach, but insomuch as it enables an existing pattern to be phased out gently, I think it offers at least the foundation of an idea that could be useful. It also could be used as a counter-balance to some of the current thinking on federated login flows with OAuth.

Consider these three sign in boxes for comparison:

1. Traditional Password
   
2. Lightweight PIN access
   
3. Full OAuth
   

Thoughts welcome.

Monday last week marked the first ever OpenID UX Summit at Yahoo! in Sunnyvale with over 40 in attendance. Representatives came from MySpace, Facebook, Google, Yahoo!, Vidoop, Janrain, Six Apart, AOL, Chimp, Magnolia, Microsoft, Plaxo, Netmesh, Internet 2 and Liberty Alliance to debate and discuss how best to make implementations of the protocol easier to use and more familiar.

John McCrea covered the significance of the summit on TechCrunchIT (and recognized Facebook’s welcomed participation) and has a good overall summary on his blog.

While the summit was a long-overdue step towards addressing the clear usability issues directly inhibiting the spread of OpenID, there are four additional areas that I think need more attention. I’ll address each separately.

Make it easier!

Overwhelmingly criticism of OpenID has been leveraged by developers and web users alike against OpenID’s ease of use.

For developers, implementing OpenID is confusing and cumbersome, and often tacked on as an afterthought to appease annoying early adopters (like me) who badger them to support the protocol. Even those who support the protocol report little upside, compared with something like Facebook Connect, which brings with it richer aspects of someone’s profile and social graph.

For web users, OpenID is confusing and frustrating, resulting in what I call “OpenID double registration taxation” — where a user, immediately following OpenID authentication, is prompted by the relying party (RP) to supply, and then verify, their email address. Why bother with OpenID if they’re going to have to go through the old school registration process anyway? Where’s the benefit in that?

On this latter point, we probably won’t make much headway until email harvesting goes out of vogue, which won’t happen until there’s a better way for sites to spam/bacn their members (bacn: “email you want, just not right now”), or until OpenID Providers (OPs) more consistently pass on profile attributes via SREG, Attribute Exchange or PoCo (or until people realize that email is dead to the MySpace generation).

Unfortunately, mandating that providers pass on profile data is something that cannot, and probably should not, be mandated by the OpenID spec, even though in comparison, Facebook Connect always provides some data. Fortunately OPs like Yahoo! are starting to improve this situation, by enabling opt-in controls that enable users to share their data more easily. If this trend continues, we may see fewer “double taxation registrations” and smoother OpenID login flows.

Still, for both end users and developers, OpenID must become easier to use and more obvious to implement. Fortunately, there is now fairly widespread recognition within the OpenID community of specific issues and a strong willingness to address them.

To that end, for example, advocacy for email addresses to be used as OpenIDs is growing, providing web users the convenience of reusing a familiar identifier, and affording developers a way to “upgrade” legacy userbases that may have been keyed to unique email addresses.

It is my opinion that enabling an email address to be used as a “hint” that resolves to a valid OpenID URL is a necessary step to dislodge one of the main nettles against OpenID. I also believe that this step is necessary to bridge the impending generation gap that’s sure to develop when MySpace flips the switch on their OpenID provider, enabling over a hundred million URL-based OpenIDs. Privacy concerns notwithstanding (remember, most RPs already demand a verified email address anyway), there are few reasons not to use email addresses for OpenID. I’d rather just make it so and let people pick for themselves how they feel most comfortable identifying themselves on services and move on to meatier issues.

Branding and marketing

On that note, Max Engel from MySpace brought up some important points about what it would mean to enable email addresses as OpenIDs. Soon to be one of the largest providers of URL-based OpenIDs (i.e. myspace.com/factoryjoe), he’s concerned that people will only implement support for email addresses if the OpenID spec provides a way to translate email addresses into URLs. This is a valid concern, but one that can be mitigated both in the language of the spec, and in the libraries that perform OpenID authentication.

Here is where I see an opportunity to finally establish OpenID as a brand unto itself, where the word “OpenID” can and should come to mean something to people (though of course not without an ongoing substantial and sustained marketing effort, lead by the OIDF, but primarily prosecuted through grassroots and community “spreading vectors“).

Here’s why: people have learned, over time, that “email” is easier to say (and shorter to type) than “electronic mail”. When you ask someone for their “email address”, most people on the web can give you the answer you’re looking for. We’re a long way off from the same kind of familiarity with OpenID, but ultimately you have to start somewhere. And because “URL-based identifier”, “blog address”, “profile link”, “home site” — ad infinitum — probably don’t mean much to anyone (let alone the same thing) there’s an opportunity to converge on a term that’s easy to say and captures the concept fairly well (or well enough) and is otherwise not known.

It’s also important to consider that not all URLs are in fact OpenID-enabled. This point alone is enough to convince me of the importance of the OpenID name and the potential for the brand. When you ask someone to sign in to your site, you can be pretty sure they’ll know what their email address is. If you ask them for a URL, and they provide you with a perfectly valid address but one that is not OpenID-enabled, they will not be able to sign in. If we can make it clear that “having an OpenID” is something special, and that not all URLs are OpenIDs, then we can begin to create the kind of awareness necessarily to confidently ask people for an OpenID, and have them respond appropriately.

It is here that I disagree with Scott Kveton, who has long argued that his mom didn’t “get SMTP, they got email”. I appreciate his sentiment and used to agree with his argument in principle, but now that I’ve thought about the fact that only “special URLs” are OpenIDs, I think it’s worthwhile to give that class of URLs a specific name.

Consistency

Furthermore, one of the greatest threats to the viability of OpenID is an inconsistent user experience. Unfortunately, this manifests itself both when signing in to a malfunctioning relying party, or attempting OpenID authentication using an OP that an RP doesn’t support (e.g. Microsoft Health Vault currently supports three OPs).

Another manifestation of this problem is that OPs are not required to consume OpenIDs. Though there’s validity in this complaint, change should not be forced at the technical level, because it really should be up to each individual provider to determine whose credentials it’s willing to accept. Now that the majors (save Facebook) have all gotten into the OP game (most recently Microsoft), it really just seems a matter of politics and inertia that none have moved to accept the OpenIDs of their competitors in any significant way (that is, neither Yahoo, Google, or Microsoft allow authenticating against their respective services using one of the other’s OpenIDs — and no, Blogger doesn’t count and Google hasn’t really released their OP yet).

While I’m sympathetic to Allen Tom’s argument that more OPs is frankly better for the web, I’m not convinced that a Visa card is all that useful if none of the major department stores will accept it.

I certainly respect large providers’ desires to both minimize the potential for abuse and to wade through the legal morass around identity technologies, but I can’t see how becoming an OpenID relying party is any worse than letting people create accounts with arbitrary (and untrusted) email addresses.

Hopefully through both political pressure and success-in-the-wild over time, we will see the majors become relying parties to their competitors’ OpenIDs for accessing accounts, and over a longer period of time, enable the use of personal/private OpenID providers or delegated OpenIDs (e.g. factoryjoe.com).

Should we see this situation change, I think it’ll bring about a watershed migration to patterns established by the majors — leading to consistency in the OpenID sign up and sign in experiences, and consistency in what people expect of OpenID account federation, leading to increased credibility and use of OpenID generally.

Leadership

But let’s get real: all these issues are going to require, above all else, solid foresight and leadership and a commitment to pushing through the thorny political issues that can often scuttle the best intentioned technologies (consider HD-DVD and Blu-Ray).

For reasons beyond my grasp, the OpenID Foundation has not met up to my expectations of leadership. Despite considerable progress in some areas, large swathes of stagnation have come to subsume many of the organization’s initiatives. International progress, as overseen by the OIDF, is lacking, except where local chapters (such as in Japan and in some European cities) have taken matters into their own hands. Code improvements to the OpenID libraries has languished and implementation of OpenID in various platforms and open source projects seems non-existent. Marketing simply isn’t happening and even if it were, I’m not convinced that there’s consensus on what we should market. And only now, after research from Yahoo and Google confirm what many critics have said for a long time is there finally work being done to address OpenID’s usability pitfalls.

Now, I realize that technologists don’t always make the best politicians (or designers or marketers for that matter) but that we haven’t seen the kind of OpenID visibility, credibility, innovation and adoption in North America that has been seen in Japan suggests to me that we’re either on the wrong course, or no apparent course at all. Worse, I fear that certain companies are already dividing up the proverbial “identity pie” before the damn thing’s even been put into the oven — a situation that needs to be addressed immediately by prioritizing a series of steps that the OIDF will take to establish OpenID in the marketplace, set firm how it will support individuals and companies alike, plot out its administrative and advocacy agenda for 2009, make clear its budgetary outlook, and list the marketing, design, education and research initiatives it plans for the coming year.

Without a clear path forward, I think that a lot of otherwise positive energy will devolve into useless sniping and infighting. Without strong leadership, we risk marginalizing many of the gains we’ve made to date in establishing OpenID as a core building block of the open social web.

For comparison, consider the progress that has been made with OpenSocial: only a year ago, people dismissed it as a “Gadgets API” (which, arguably it was). Since then, a large coalition of the willing has gathered to support and develop the protocol (which is still far from perfect, but demonstrates steady progress towards a goal), even convincing that old salt David Recordon that what they’re doing is decent. When OpenSocial 1.0 is released (they’re at 0.8.1 right now), there will be a distributed social graph with over 350 million potential customers available to developers (compared with around 100 million on Facebook). While David is right to point out, with Microsoft coming on board, there’ll be well beyond half a billion OpenIDs in the wild, that doesn’t mean that our work is finished. Rather, it’s just begun, and David sums up our situation fairly well:

While this is great news from Microsoft, real web-scale adoption of technologies always faces a chicken-and-egg problem between developers and vendors. Developers don’t want to adopt a technology without buy-in from platform providers and platform providers don’t want to support a technology if developers won’t use it. We’ve largely been able to successfully avoid this concern with OpenID as it grew from roots in an open source community with lots of people and companies involved in making OpenID what it is today. There are now well beyond half a billion OpenIDs available on the web which means we can mark the first phase of OpenID adoption, platform support, as a success.

The next phase of developer adoption will not be measured in the number of OpenIDs or sites that support it, but rather user experience, accessibility, and seamlessness of integration into a wide variety of applications and experiences.

To that end, there will be an Internet Identity Workshop in Mountain View November 11-12 where many of the primary participants in the ongoing identity conversations will converge. Historically the event has been one of the most productive in the space and with all the recent OpenID news lately, I’m hopeful that many of the issues I’ve mentioned above will be addressed and progress will continue to be made.

I will continue to be a staunch advocate of OpenID and think that it’s best times are still to come, but not without a redoubling of focused effort around concrete and ambitious goals.