1. Dear Mashup Developers…

    Today sees yet another round of some “awesome” Twitter mashup: tweet cloud that generates you a list of the words you use most in your tweets. It’s not a nefarious application by any means, but it’s yet another mashup that fails to disclose up front what it’s going to do with your user credentials.

    In recent BarCamp talks on Microcopy, I’ve time-and-again used the example of Favstar.fm to illustrate how mashup developers can responsibly create cool stuff and earn users trust.

    Ultimately, as a mashup developer, whatever cool thing your service provides is secondary to reassuring the user that sharing their credentials and details with the application is safe. So:

    1. OAuth - whinge all you like about how it takes slightly longer to implement than username / password authentication, but OAuth gives the user the single-most important feature that HTTP basic can’t offer: the ability to revoke access, without requiring the user to change their password. If you’re curious about what has access to your Twitter account, then check your Twitter account connections here.

    2. Justify why you need account access - This isn’t optional. If you are going to be using someone’s data (or posting automatically to their Twitter profile) you should be disclosing this before they click ‘Sign In with Twitter’ - as shown in the Favstar example above.

    3. Forgo viral l33tness in favour of user trust - By all means, give people the option to tweet the results of using your service. But don’t force them to auto-tweet the results. I know, you’re looking to make the mashup popular and Social Media Consultants everywhere will tell you to spam the crap out of Twitter, but if the mashup is genuinely useful to people - and there’s a convenient Tweet This button next to the results - trust that people will share the details.

    Update: As has been pointed out, few OAuth APIs allow granular access to your account - something that could stop applications from auto-posting to Twitter (for example). FireEagle and Flickr are the only two services that spring to mind with this, and both allow read or read/write permissions to be set when authorising an application.

    Sunday November 29th, 2009 (2 notes)