Companies should make identity management easy within their online services. Specifically, it’s becoming more and more desirable to have a “split my identity” feature.
For example, I have a Twitter account. Turns out I like Twitter. (It wasn’t always the case.) Eventually I want to split my twitter stream into a personal stream and a business stream. The business stream would be open to followers. The personal stream I’d probably restrict to people I’ve met in person. When I’m posting about selecting music for vacuuming, that’s personal-stream material. When I’m wishing out loud for a feature improvement in Adobe InDesign that can be public.
But what if I decide to split my streams after I have 100 followers, not all of whom belong on the personal list?
The current practice is to start announcing on the existing account that you have a new account – “if you haven’t met me in person I’m planning to block you, so go follow me over at this new account.” You might announce this every day for a week, perhaps a few times on the last couple of days, then go block everyone you haven’t met in person.
Some followers will make the move, some won’t. Unless you care a lot you probably won’t track who fell off the list, especially if you have far more than 100 followers.
It would be better if I could choose which followers to “move” to the new account. That is, I would choose which followers will follow my new business account instead of my existing personal account – without any action on their part. I move their “following” subscription to another identity. Maybe they get an email letting them know.
That’s it: no business rules, no criteria, no searching. Just a list of followers (rows) and maybe two columns of checkboxes – people could be on either or both lists.
This wonderful solution assumes that the service can associate my two accounts with each another. In other words, one person can have more than one account. For many services you are allowed to have more than one account, but many times the service uses your email address to create the unique account.
It’s very convenient for developers to use an email address as a login – I’ve done it myself. It’s convenient because it’s guaranteed to be unique without any development effort. No downcasing, no uniqueness checking, the user doesn’t have to remember lots of different login names, etc. But if every account requires a unique email, then this “split my identity” feature is very, very difficult – potentially impossible – to implement.
To allow each email address to have more than one identity is a very big architectural change if the initial design didn’t account for this idea. Changing the one-to-one relationship of a login account to a one-to-many relationship will likely have a lot of “ripple effects” throughout the codebase, so the development cost will be very high. Thus the probability of developing the feature is low. Well-financed services can do whatever they need to do to service their users. Bootstraps and startups usually cannot.
Had the service started out with this idea it would be much easier to design and build, even if they didn’t implement it at the start. This is a good example of the importance of key architectural decisions made early in the design process. Sometimes you know what you’ll want to do in the future, and sometimes you don’t. But it’s worth spending enough time in the very earliest design stages to think through the implications of the trade-offs you’re making.
In theory this problem is an aspect of what OpenID is supposed to solve, going further by abstracting across websites and services, not just within one service. It’s designed by Brad Fitzpatrick, so it’s probably the right idea. Reviewing the history you can see why, in general, adoption by developers is slow (but growing and accelerating). But even using OpenID, the service will have to build their data model around a one-to-many login/account relationship. Twitter’s growth provides a good example of why the effort might be worth it.
January 26, 2009