Features

I’ve been noodling on how best to present a coherent vision of user-centric website and web service design and think I came up with at least a basic model that will serve my purposes. It’s made up of identity, friends or contacts, services, activities and notifications.

To get concrete, let’s take The Future of Web Apps (London) site. The site’s pretty hot from a purely aesthetic perspective, but from an interactive or social point of view, it’s lacking. This is something that can be remedied, though, with a revised conceptual model and the adoption of a few forward-facing technologies (not all of which are completely baked just yet) but many of which are already becoming the de-facto foundations for decentralized social applications.

The Problem

The fundamental problem with the FOWA site, like most sites today, is that it is site-centric, rather than user-centric, and this has a profound effect on how the site is designed, the features it offers, and what people’s expectations for the site might be.

On the one hand, the site has an obligation to be informative, providing the basic event details: dates and location, schedule, speakers, how to book tickets, etc. On the other hand, and in support of the organizers’ desire to promote and improve engagement before, during and after the event, the site could do so much more to connect attendees and act as a digital scrapbook of everything that occurred during the event.

So while event sites still need to meet promotional and informational objectives, there’s no reason why they can’t also serve to facilitate socialization and aggregate the social objects and creative output that result from such gatherings.

The Opportunity

Now, don’t get me wrong. The point is not to turn every site into a social network. However, especially in this case, where socializing is a large part of the event’s appeal, there’s no reason why the FOWA site shouldn’t make it a little easier for folks to meet and connect before the event — to see who’s coming, and maybe to dog a couple of their friends into attending as well.

In order for social features to get traction, they’re going to need to provide an obvious upside without being too time-consuming or hard to use. Any friction to enjoying these social features — especially before making the upside obvious or significant — are going to inhibit their use and adoption.

Therefore, the easiest way to minimize barriers is to reuse the social connections and tools that people maintain elsewhere. As long as an external service provides a means for extracting media, data or connections, you can let other someone else focus on storing, editing and adding metadata to content, or simply facilitate adding event metadata to remote social objects. An event site, just like the event it represents, should really be a zeitgeist for a moment in time — an epoch for ideas, connections and learning.

The Building Blocks

The foundational building blocks of such a site begin with:

• identity: who is this person? Do they have an account or profile elsewhere that represents them or that they might rather use for identification?
• contacts or friends: a way of expressing or importing relationships between individuals as well as details like email, name, location or URL, to help find friends who might have already signed up
• services: sources of media like photos, videos or other content that can be imported or republished
• activities: atomic-sized descriptions of what someone’s doing or has done (commonly aggregated into so-called “lifestreams”; popularized by Facebook’s newsfeed)
• notifications: sites typically take email for notification for granted, but folks increasingly prefer to receive updates via other services, like feeds or Twitter. Given people the ability to choose how they want to be contacted will probably improve the likelihood that the recipient will appreciate hearing from you.

Identity

It can almost be taken for granted that just about everyone who comes to your site and wants to interact probably has an account or profile someplace else that they maintain (especially if your site is for an event called “The Future of Web Apps”). Indeed, all sites seem to presume an email address at minimum these days, and increasingly it’s becoming safe to assume presence on at least one of the following: MySpace, Facebook, LinkedIn, Yahoo, Flickr, YouTube, Google or owning a personal blog somewhere. It’s certainly not universal — yet — but for the audience that does maintain a profile elsewhere, it seems a wise idea to start looking at how you can leverage it.

After all, who really needs yet another password? Why not let them sign-in to your site using credentials that they’ve established elsewhere, say at Facebook, WordPress, Blogger or Yahoo? All of these sites act as identity providers, because they support the OpenID protocol. And so when someone signs in to your site, verifying their OpenID to you, it’s no different than you sending them an account confirmation email, except there’s no need to deal with checking email or worrying about the confirmation getting marked as spam. The whole verification process takes place in the browser.

Going one better, why not also import their existing profile? Here you have several options: scraping hCards from sites like YouTube, LinkedIn or Flickr (and many, many more); requesting several basic profile attributes with SREG; making use of the Attribute Exchange protocol.

By supporting the concept of remote identities on your site, you’re implicitly recognizing that your site is not the only one that people use — and that you want to make it as easy as possible for people to interact. Your first priority — and your customer’s — should not be to create another account and another password, but instead to consider what you’re offering, and whether it might provide them any value. Getting the account creation step out of the way means this process can happen faster and more immediately.

Contacts, Friends and Relationships

Now that you’ve discovered who someone is, wouldn’t it be useful to help someone find the people who they might already know on your site? You might be tempted to take the discredited approach of just asking for someone’s username and password for their email address book, but why take on the liability of someone else’s email password when you can now skip this uncomfortable and unpopular password anti-pattern?

Again, you have several options: scrape friends lists marked up in XFN from blogrolls, Twitter or other microformatted services; use the new Portable Contacts API with OAuth to do friend-importing; use a proprietary delegated authorization protocol to access some of the more popular address books. For an example of this done right, see the New York Times’ TimesPeople social network:

Now, it’s important to keep in mind that the purpose of importing friends should be to provide real value: to aid in sharing and connecting. A simple but very valuable way to leverage such “portable contact lists” is to show someone a list of their friends who are already planning to attend the event. Better yet is to keep a record of someone’s friends and if any of them end up registering, let both parties know of each other’s plans. This can be done by storing hashes of identifiers (i.e. do not store the actual email address itself unless the email owner has provided it to you) and matching those hashes whenever someone new signs up.

And of course, if you allow people to connect through your site, always make sure that they can take that connection offsite by supporting the Portable Contacts API (i.e. allow for export of the speakers’ public contact information)

Services

Just as more and more people maintain accounts elsewhere, more and more people use several web services to store their photos, videos, links, blog posts, tweets, wishlists and the like. Similar to how it’s convenient reuse existing user accounts, it’s equally easy and useful to import their existing content from somewhere else.

Of course you can always just specify a universal tag (say, “fowaexpo08″) and subscribe to correctly marked-up media . Even better is to facilitate the contribution of specific pieces of content — from services that might already be indicated in what’s called someone’s “discovery profile”: an XML document marked up in the XRDS-Simple format. The beauty of this format is that it is designed to be attached to someone’s OpenID URL. So at the time of OpenID account verification, you can grab someone’s public discovery profile to learn about the different services that they use. The format also specifies how to identify “authorization endpoints”, which essentially are the gatekeepers to accessing private data stored on these remote services.

By combining OpenID, XRDS-Simple, Portable Contacts and OAuth, you can enable someone to reuse an existing account, discover their list of friends, request authorization to access this list, and then, if granted, suggest people already on the site with whom they can connect or invite to participate. What used to be a cumbersome and dangerous process is now smooth, straight-forward and secure, and applies to more than just accessing your friends.

Activities

Now that we have identity and friends accounted for, and know what services someone uses, it becomes fairly easy to start to expose, on your site, the activities that someone performs related to the event. In its simplest form, when someone registers to attend the event, you can create an activity for them, both in their personal stream but also as a feed that they can bring elsewhere; when someone connects to a friend, just like on Facebook, you can expose that; when someone imports a photo or video, you can offer a thumbnail; when someone tweets about the event (say, using the hashtag), you can quote them… and so on.

The point of activities is not to show off everything that someone does, but to highlight relevant activities as a means of social discovery.

There is much work still to be done on the basic format for activity streams, but the most basic activity takes the form of actor verb social object. If you publish activity streams on your site, it is suggested that you consider using the hAtom microformat to start, and then mark up the various components using the respective classes: actor, verb, object. At least until something better comes along.

In the meantime, for an event site, activities could be useful for exposing interest in sessions, or helping attendees to let speakers know that they’re looking forward to hearing them or even for spreading new information about the event in bite-sized chunks (i.e. new speakers, etc).

Notifications

The last thing to consider is how to handle notifications. While email still reigns supreme, syndicated content and services like Twitter have become alternative viable means for staying in touch.

There are lots of options here, from instant messaging over XMPP to SMS to Twitter to posting activities of your own. The important thing is to recognize that email isn’t the only means to stay in touch any more — and for some, might not even be the most preferable method of contact. The interest to drive people back to your site must be balanced against the obligation to provide useful communication.

Web services are increasing the types of notifications they offer, and provide fairly granular control over how they contact their members. Mixin is one example to consider:

Another is Brightkite:

Thinking about your opt-in notifications strategy ahead of time — by coordinating efforts among your team to reduce duplication and increase value — will likely improve your read and conversion rates, and keep your attendees satisfied and informed.

Conclusion

Putting this all together, we start to see that a more formal conception of the components of user-centric web services is becoming clear. A user-centered web service prioritizes the situation of the individual and his or her use of the service, rather than the objectives of the service. This means: making logins easier and passwords fewer, the ability to interact with known friends without having to add them all over again, surfacing activities as a mechanism of discovery, and using several means of notification based on convenience. Indeed, this approach is necessary for continuing to innovate, create and offer new web services. Luckily, as this article demonstrates, a number of open and non-proprietary technologies like OpenID, OAuth, XRDS-Simple, Portable Contacts, and microformats exist that will make this approach not only feasible but simple and less costly to implement.

The conference or event site example used here is just the obvious case of a user-centered web service that would benefit from recognizing the broader context in which their users exist on the web. Hopefully through greater promotion and adoption of the technologies and concepts outlined above, we will start to see a new wave of highly valuable, useful and low-effort user-centric event sites blossom that provide high value through low-cost interactions for users and developers alike.