November 30, 2008
I would love it if someone would write a TwitterBot service. It would:
- Allow you to give it the Username and Password of a given Twitter Account (let’s say JSKitSupport)
- Auto-follow people when they followed it
- Auto-unfollow people when they unfollow it
- Allow you to register one or more ‘Bot Owners’ (Both Twitter account and Email Address)
- Forward any @replies or references to given keywords to Bot Owners
- Allow bot owners to direct message it and have it relay those messages to its followers (perhaps optionally auto-append the Owner’s twitter name to the end of the message)
- Allows Bot Owners to direct message it commands
- One of those commands could be ‘d tag last’ which ques up the last @reply in some sort of ‘follow up’ queue for the bot owners.
Can you think of any other features? Add them in comments and if I like them I will append them here!
August 22, 2008
One of the most common comments/questions I get while talking about data portability is ‘The OpenID User Experience sucks – how do we make it more user friendly?’.
The problem is two fold. First, users do not understand why they need to provide a URI to log in. Second, users get confused by bouncing around to a 3rd party site.
I’ve given a lot of thought to this problem.
The only answer I’ve had so far is that while the OpenID user experience is difficult to explain to users who expect an email address and password log in, the data portability value proposition may help justify the added cognitive load for users and vendors.
It’s probably true – but it’s not a good enough answer.
More recently I’ve been thinking about another potential solution.
I believe the 3rd party site bounce is actually becoming common place. Passport, Facebook, Google use it and, as such, users are becoming more comfortable with it.
The question of using a URI as a ‘username’ however, is a more difficult pattern to explain to users at a login screen.
Mapping email addresses to OpenIDs
The purists among us will argue that identity should not be tied to messaging. That is, uniquely identifying people by email address is a bad idea. It encourages spam and other unhealthy activity.
Putting that aside for a moment, however, imagine this.
Rather than asking for a user’s OpenID, ask them for their email address:
Now imagine the application refactoring the address on the fly to something like this:
The point here is that we take everything before the @ and place it after a slash. Remove the @ and put HTTP:// at the start and you end up with a well formed URI.
Now imagine that Gmail provided OpenID functionality for each email account in this way.
There are a number of challenges to pulling this off. Not the least of which is getting major email providers to support OpenID, and get existing OpenID consumers to refactor email addresses (if provided) on the fly.
It’s certainly worth thinking about though.