Friday, June 26, 2009

Why Do We Still Maintain Those User Accounts on Our Services?

Let's say you're building a website or an e-commerce site where you expect to have many visitors. By default you consider that people will need to log in to the site. When they log in, you'll collect some data about them. Sooner or later this data may be changed by the user on his/her profile page. This is a usual scenario, as old as web apps are.

And in every single project of that sort - the same thing: user registration, account management, password reminder etc. etc. If you look at a decent e-commerce software (e.g. Magento) or some content management system (e.g. Drupal) these features are built-in and looks like there is no issue with that. Surely, you can't have anonymous people doing things with your service.  And of course user profile data is a very valuable piece of information.

But here is a paradox: by collecting this valuable user information we actually lose much other valuable (or even more valuable) information and when we realize that we need it (e.g. user social graph) we start building on top of what we have, in order to obtain it... Complicated life...

If we look around every single web site has a database of users. And this database is filled by almost always the same process:

  • Register

  • Confirm your e-mail

  • Fill data in your profile

What about only one and a half step:

  • Register

  • (modify information about yourself)

I strongly believe that the second case can be achieved using OpenID and OAuth and some code around them.

A big part of the account management feature in web applications can (and probably should) be delegated to third party services such as different social networks. This is because the e-mail is not a personal identifier anymore (just look at Google Wave - email is not there at all). If I play in a band I will most likely share my MySpace url; if I am a hardcore blogger, I'll give everyone the link to my blog; if I am networking on Facebook, I'll simply connect to people by their name. E-mail is good only to confirm one's identity, not to represent it.

A shift in thinking of web apps is necessary to go from 3-step account management to 1.5-step. How to do that?

  1. Instead of registering user using their e-mail force them to sign up using their confirmed identity on another (trusted) service. For instance, if I'am creating a website or e-shop the default way for users to log in should be with Facebook or Google.

  2. Prefil user profile with data from the external service as follows:

    • Pull user picture (allow to swap it with his/her Gravatar) and other relevant info

    • Let the user to connect other services to your application, e.g. Flickr, Facebook, or whatever makes sense.

    • Ask for additional data that is not provided by third parties (preferably only when it's necessary to perform an action on the site)

    • Allow the userto create a persona and define privacy settings

That's it!

Look at Google Friend Connect. Ok, it's very general purpose, not even sure if it's a very successfull project. Still it depicts how websites should operate, i.e. people should navigate around the web and have their social life present everywhere. That's how we live in reality: we travel to different places but are always in touch with relatives and friends via phone, email, etc. So every site on the Internet should have kind of  "Friend Connect" feature instead of the stereotipical user management feature.

Of course, we can run into issues and questions like:

  • Identity mapping, when the user is allowed to sign in using different identities from different services

  • How expensive is it to build the user management infrastracture genuinly based on integration to other services as opposed to having standard (prebuilt) e-mail based implementations?

  • How much can one trust in the third party services? What if companies behind them go bankrupt?

But let me list the benefits from top of my head:

  • User is not required to sign up to yet another service, giving away the e-mail, memorizing the password

  • Since social networks will be like air, we're already integrating to other services through REST or JavaScript APIs. So why not doing it from the scratch?

  • Thanks to OpenID and OAuth as soon as another service appears it's relatively easy to plug it into your site if you've pluged one already

  • You get much more data about users on your site(e.g. friends, activities etc.), so you can track and engage in many different ways than just e-mail

  • The user experience of 1.5-step scenario is better than that one of 3 steps

  • Using computing resources of third party services

  • You might be able to bring your service to outside just your website, e.g. an OpenSocial widget on MySpace. This may turn into a viral effect which could increase the popularity of your service.

In short, let the people be free, don't close them in your little "walled garden", it just does not make sense, as you'll have to break the walls anyway :)

No comments:

Post a Comment