twitlonger
Central authentication – good for users, bad for usability
As most of you know, I have a fun little project called Twitlonger that talks to Twitter, including the ability to post to users’ accounts. Until recently, I had to ask for user passwords to enable posting, something I’m not keen on doing because it raises an expectation of trust that, to be frank, I haven’t earned from most people (this goes for all the Twitter apps).
Now, Twitter have enabled support for OAuth for granting applications API access to your account, without the need to give up your password. It’s nice and simple, you click an authorise button, get sent to Twitter which allows you to allow or deny access and get returned to the initial site. All well and good, solves the password problem, gives users control.
At the minute, I control access to Twitlonger by getting users to sign in with their Twitter username and password. This is validated against Twitter and things like password changes etc are pretty much seamless. Users will automatically be logged out if their details have changed since they were last at the site and logging in with the new details automatically updates the details in Twitlonger. Overall, I’m pretty proud of the login experience for Twitlonger.
Naturally, I now want to implement OAuth support, which means I have two choices – get the user to grantTwitlonger access every time the session expires (irritating) or store the keys necessary to authenticate with Twitter and give Twitlonger its own registration system. Not one for duplication of functionality, I was thinking about having OpenID support, so users don’t need to create *another* username/password combination.
Then I thought about the process for the user to be able to use Twitlonger (for the first time, anyway).
- Login with OpenID
- Get sent to external site to authenticate OpenID
- Return to Twitlonger
- Authorise with Twitter
- Get sent to Twitter to authenticate API access
- Return to Twitlonger
- Actually get on with the desired task.
OK, so this should only need to happen the first time the user comes to Twitlonger, but it also means their first experience of the service involves visiting three different sites just to start the task in hand.
On one hand, they will be having a much more secure experience, but from the user-friendly standpoint it will be horrible. I don’t plan to find out how many people would lose interest before the end of the process.
I will be implementing OAuth because it will make me feel a lot better about everything, but I’m afraid OpenID as well would be a step too far.
Twitlonger
It’s no secret that I love Twitter. I get withdrawal symptoms when it goes down and it is one of my primary methods of communication. I also love how it forces you to be concise, to reduce thoughts to the minimum required to convey information.
Sometimes though, just sometimes, 140 characters really isn’t enough. Anyone who has found themselves in a theological or technical discussion knows that it is difficult to convey information in 140 characters. Sure you can email, but you then lose the social network advantages of having the discussion on Twitter in the first place. You can also spread your thoughts across several Tweets, but this is both disjointed and slightly spammy to anyone not involved in the conversation.
So, I’ve made Twitlonger. Think of it as Twitpic for text. You can jot down those longer thoughts and it will generate a truncated Tweet, with a link to the full message. You get the advantages of staying (relatively) within the Twitterverse, but also get to explain things properly, where necessary.
Isn’t this open to abuse? Yeah, that is a worry. People could just use it to be very lazy and not be succinct, but hopefully it will be used sparingly and when appropriate. More information on the how and why is at www.twitlonger.com/about.php.
Currently, I’m running Twitlonger in closed beta, hopefully to catch any glaring problems, but if you want an invite code, tweet me: @stuartgibson.
