A few days ago Josh Porter was tweeting about the notion of “fatigue points”:
I think it’s a very useful concept, pointing out that people’s decisions aren’t binary: it isn’t a single yes/no decision but an active, ongoing negotiation, which determines which services you use and don’t use.
You can also think about the barrier to entry of a new user in a similar fashion. Any time you try out a new application or service there are a few barriers, and whatever the application developer can do to lower those barriers the more users will get over that threshold.
(One of the key benefits of open source, from my point of view, is the relatively low threshold of entry it makes possible – no need to negotiate an enterprise license, sign up for 2 years of support, and get lawyers to agree on terms – just download, install, and try out).
In social web applications, the barrier to entry is generaly sign up – authorization and authentication. Applications running inside containers like Facebook have the benefit of bypassing the authentication problem – by relying on Facebook to determine that you are appropriately logged in to your own identity – but still need to get authorization from you to “install” themselves to your profile.
The problem is that Facebook (or Facebook application developers, guided by the Facebook API) seems to treat this experience as a binary choice: you either install the application or you don’t. From the application’s point of view, you are either a user who has installed the app (in which case you’re in) or a user who has not yet installed the app (in which case you’re out).
Why should I have to install an application in order to be able to see the message my firend sent me using it?
Jonathan Terleski, from Google’s User Experience Team, posted a movie today showing a better way: allow users to experience the application and then – after they have determined it has some value to them – ask for the install.
What do you do, though, if you’re outside the environment of an open social container or the Facebook API? Use OpenID and OAuth.
Keeping the barrier to entry low:
- Let people have a decent sense of the experience before “creating an account” (or whatever language you use to describe registering). Let ’em try before they buy, as much as possible.
- Use OpenID. Enable people to log in to your new service using their existing identity elsewhere. With Yahoo! and AOL on board, and the directed identity features of OpenID 2.0 (which let users click a button marked “log in with your Yahoo! account” rather than remembering a URL) we should see end user adoption of OpenID take off. (It may be “unaware adoption” in the sense that people don’t know it is OpenID being used, but that’s actually a good thing).
- Leverage their data from elsewhere, using import via Google’s Social Graph API, hCard profiles they may have on other sites, XFN or FOAF notations from sites like Twitter which markup links with microformats, and OAuth to access third party data.
I’m looking forward to seeing more detail on the Ringside Social Application Server next week – looks to offer a very compelling path to bringing social networking features into applications without imposing a high barrier to entry. See also DiSo, Noserub, Shindig, and the Appleseed Project (which may need to change its name to avoid the other Appleseed Project).
