1999

Excite!. Goes so far as to ask you your race, and then a further question about whether you are of Hispanic or Latino descent. Oh, and then your household income! Talk about building barriers to signup!

2001

Yahoo!. IIRC Yahoo! also used to ask for your profession and related stuff, but simplified things a bit somewhere along the line. They’re still adding big barriers though by asking a lot of unnecessary questions. As for these security questions, they’re of dubious value. When exactly did Yahoo! remove questions on professions etc? I’m not sure, but I’ve set the date at 2001 as it’s the kind of time people started doing that.

2004

37Signals’ TadaList. Seemed pretty simple at the time, just asking for the basics. But still, characteristic of its time, it goes for email and password confirmations. Optimising for an unlikely error condition isn’t a great idea. Also, you have to tick to agree to terms and conditions. I’m not a lawyer, but I suspect you could argue that signing up is implicity agreeing to terms and conditions, so the slight increase in complexity isn’t justified for simple websites. (On a minimal form, the extra checkbox could raise the number of controls by 50%.)

2007

Tumblr. Keeping it DRY. Just the facts, Ma’am.

2009

Posterous. Signup form? We don’t need no stinkin’ signup form. Posterous uses one of the new registration and login grammars – Email-Driven Interaction – to obviate registration, at least until the user really wants to. Even then, it’s dead simple.

For clarification, all these screenshots were taken today. The years are reflective of the site’s origins (not necessarily their year of creation, in the case of Yahoo!) and the kinds of forms that were around at the time. I dig all of the sites here and their inclusion is testament to their role as representatives of an era. I just wish some of them would modernise their signup forms a bit .

Before we walk through these new interaction patterns, let’s be clear about the “old” pattern we’ve come to know and (sometimes) love. It starts with visiting a new site:

• use the site anonymously. Nothing you do yet is persistent; you can look (sometimes), but you can’t touch.
• sign up by providing username, email, and password. (variants: email is \*username\*, password is auto-generated)
• click on link in verification email
• now you can log in by providing username/password and logout by clicking the logout button or by explicitly timing out

Right, you know that sequence and it works okay. However, problems remain: - barriers to signup: perhaps the biggest problem faced by site owners is getting users to sign up. A known, authenticated, user gets a much richer experience, can contribute in mire valuable ways to the community, and can receive targeted services, not to mention targeted ads. - barriers to login. Users might have signed up at one stage, but rarely sign in due to the hassle factor, a factor that multiplies when they have forgotten their password. - timeout. For security reasons, timeout must happen and that will frustrate users and see them going elsewhere. - mobile access. My dear reader may well bear the latest and greatest web-enabled digital communications circuitry in thir pocket or handbag, but the majority of phones still lack a basic web browser. Even when you do have a browser, it’s difficult to login, especially if you are using suitably complicated passwords. There’s something to be said for more fluid models of mobile-webapp interaction.

Lazy Registration (NetVibes)

In Lazy Registration, an anonymous user is allowed to interact with the site right away, and through the magic of cookies or unique URLs, the site builds up a profile before the user even signs up. Once the user does sign up, they take their existing (hencetoforth anonymous) profile with them. The benefit is clear: the ability to start playing with the site without incurring the overhead of registration. The better e-commerce sites do this by letting you add to your cart as an anoynomous user; where most of those fail is they completely time you out after a short time. See Partial Logout below …

Unverified User (Flickr pre-Yahoo!)

Here is another pattern that defies the traditionally strict dichotomy between those who are in and those who are out. You sign up as normal, but you don’t have to verify the link straight away. There’s effectively an “email verified” flag against your name and unverified users only have partial rights, e.g. You might be able to start maintaining content, but no-one else can see it until you’re verified. The benefit here is eager users can get going right away, and have a reason to click on the verify link when they come across it later. (I’m afraid the only example I can think of is Flickr’s Guest Pass concept, before they tied login to Yahoo!. I’ve seen it elsewhere, but can’t recall where!)

Partial logout

Something like a rewind of Lazy Registration, the Partial Logout pattern allows for differing degrees of “logged-in-ness”. Once a user has been idle a while, instead of completely timing them out and making them anonymous again, the system continues to “sort of” trust them by letting them view some things and keep building up some aspects of their profile. In this state on amazon, you can view your shopping cart and personalised rexommendations, and products you view will be fed into your profile; but try and purchase a book or change your credit card details, and you’ll be faced with a login form. Timeout is the main reason to be partially logged out, but it might also be something else which leads the system to believe there’s a risk the browser is no longer under the user’s control; for example, the user logs in from somewhere else.

Device-Driven Interaction (SMS-Twitter)

You can tweet from Twitter.com or any number of web and desktop clients, but one of the main driving forces for twitter was the ability to say what pure doing wherever you are, a perfect example of SMS-driven authentication, and the reason why tweets are limited to 140 characters (leaving room for a username as well). The verification is all thanks to the caller ID. There are interesting international implications since the recipient pays in the US, while most other countries run a model where the sender pays. And when the sender is roaming abroad, they always pay to send. And it’s usually an absurd amount.

A variant is MMS-Driven Interaction (e.g. Joomla MMS module, although its cost – and immaturity in the US – makes it less viable. The more general way to depict this pattern is to see it as Device-Driven Interaction, where your possession of the device is used to authenticate you. Thus, a variant would be GPS-Driven Interaction, such as Google Latitude.

Email-Driven Interaction (Posterous, Tripit, Twitpic)

Email-driven interaction is becoming really popular lately; Posterous especially is taking off right now. In the simplest case, it’s just emailing a new post to your blog, to a secret destination address you can see on the web page when you logged in. Where all this gets more interesting is when you don’t even have an account yet! You simply send an email to their generic address (post@posterous.com; plans@tripit.com) and you’re up and running. In Posterous, you can also reply to comments from the comfort of your mail client too. All this is fantastic in a mobile context, where it’s often more convenient to fire off an email from your camera app than log into the website and upload it. It’s also cheaper than sending MMS content around too. Of course, these services still let you log into a website the regular way too; they’ll send you a link that gets you in the first time. Of particular interest is their use of simple, public, addresses. It raises the distinct risk of spoofing to act as someone else, but in practice, the services seem to be smart enough to thwart such attacks. Somewhat. So far.

Secret URL (SlideShare, Skitch)

A secret URL is “the login you’re having when you’re not having a login”. (Which makes it a “Claytons login” in Aussie vernacular). A privileged user can see the secret URL, it being a long unguessable string, and can then distibute to trusted others. The chief benefit is no-one needs to log in. From the owner’s point of view, they don’t have to tediously list everyone who can see the resource, and it’s more granular than just “only show my friends” if you already have a list of friends. Also, the owner can access it from any device or browser just by knowing the URL, and without worrying about timing out. Secret URLs are especially nice in a real-time setting (Web 3.0, here we come), where you want your friends to converge on a website for closed communication and collaboration. The main downside of course is that it’s simplistic, offering rather limited security, and in most implementations the resource must be treated as read-only, as you don’t want to let people change something unless they can be held accountable for their actions. Skitch’s settings for an individual image are shown below:

Federated (open id-e.g. StackOverflow; Facebook Connect-e.g. CNet)

Federated login, most famously exemplified by OpenID, allow for a single identity across the internet. You authorise sites with your OpenID provider, and you only need to log into your provider to access those sites. More recently, Facebook Connect provides its own brand of federated login, which is conceptually easier and simpler for users, at the cost of tying their identity to a single provider. So while purists are grizzling about lack of openness, mainstream users right now seem happy to sign in to sites with Facebook Connect, as opposed to signing up to the site separately. And sites seem keener to integrate Facebook Connect than OpenID, probably because the story is clearer for end-users, and there is a tie-in to Facebook too (e.g. site activities can show up on the user’s Facebook feed). Facebook supports OpenID login, is now on the OpenID board, and will probably become an OpenID provider at some stage.

Special Mention: Delegated authority (OAuth-e.g. Twitter)

In a somewhat separate category is OAuth, the protocol that lets you delegate authority from one site to another. It is sometimes likened to giving someone a valet key, i.e. they have partial authority at your discretion and you can revoke it any time. For example, an OAuth-powered Twitter mashup will redirect you to Twitter, where you tell Twitter you accept certain actions being conducted with your account by the mashup. From that point on, until you revoke it, the mashup will be able to work with your Twitter data as if it were you. All this would be possible if the mashup asked you for your username and password, but OAuth offers a more secure model because you can moderate, track, and revoke privileges at any time. In that sense, it is unlike the other techniques here as it is less about making the service more convenient or user-friendly; and more about allowing for extra functionality by third parties, and with a hardened security model.

Concluding Remarks

What sparked this post was the rise of Posterous, which is undergoing some kind of tipping point lately. First, I heard the founders on Technometria a few days back, outlining their plans to provide flexible templating. Then they turn up on TechCrunch, having acquired Y-Combinator stable partner Slinkset. And finally, A-List blogger extraordinaire Steve Rubel announces his new publishing strategy yesterday, with Posterous playing a big part in it. All in all, a big week for a company whose key selling point is a new registration grammar.

(“Grammar” is a term used by Josh Schachter at a at a 2006 FOWA.)