Hi Chris, On Sat, Sep 19, 2009 at 8:19 AM, Chris Messina <[email protected]> wrote: > Just for review's sake, here's what Twitter is proposing for their combined > retweet feature: > http://mashable.com/2009/09/18/sneak-peek-project-retweet/ > http://a1.twimg.com/example-retweet-ui-18-sep-09.png > The relevant thread: > http://groups.google.com/group/twitter-api-announce/browse_thread/thread/3641a248d555da20/c0eb496105eece3c?show_docid=c0eb496105eece3c&pli=1 > > Thoughts?
This is tough one. The current lack of provenance information for retweeted items makes things difficult for grassroots journalism / eye-witness scenarios. For example there were hundreds of reposted variants of: """From Iran: CONFIRMED!! Army moving into Tehran against protestors! PLEASE RT! URGENT! #IranElection""" ...bouncing around during June. Tracking the claim to source or evidence was pretty much impossible (a few more details at http://danbri.org/words/2009/06/16/415 ). So - having something like RT pushed down into the protocol makes sense there. If I understand it correctly the current RT API proposal seems problematic, for two reasons: * limits textual expressivity: you basically get to re-broadcast the item, but without changing any words - no scope for adding commentary, humour, skepticism ("WTF!" being a common and concise form...) - no support for messages crossing natural language boundaries, since text can't be rewritten/translated - for common case where the item is a pair of a URL link and brief comment, being able to add/edit/replace the comment seems particularly useful (translation use case above, but also for dialog/debate) * limited API expressivity: at a mechanical level, the only expressivity offered to users is effectively "Hey, I noticed this, check it out!" - this may end up conflating a re-tweet with an endorsement, encouraging people to only draw attention to ideas, links and posts they agree with - reminds me of those anti-dialog Facebook groups that conflate joining the group (which is needed for posting) with agreeing to the group owner's main assertion (who would want to join "1000,000 strong against the moon landing conspiracy"; "Redheads Go Home" etc...?); similarly, YouTube conflates bookmarking with favouriting, which has a similar social awkwardness - if I want to keep track of videos I disagree with, I end up expressing that I "Like" them. I raise these concerns with no concrete counter proposal. But perhaps some principles can be used to ground any API design? 1. Users should be able to draw attention to an existing post, using mechanisms that * make it mechanically clear and unambigous which post is being referenced * do not encourage this act to be interpreted as necessarily an approving or endorsing act (see also the whole rel='nofollow' debate re blog comments) 2. Annotations / commentary / qualifications on re-posted material are critically important; these can usefully be either machine or human readable: * we might allow textual additions / edits to be packaged some how with the reposted item * or allow API-level (ie. machine friendly) labelling of the kind of repost (without, at this stage, imposing a rigid standard schema). For example, POSITIVE, NEGATIVE, etc tags/labels on a re-post might be one possibility * without the editing, tagging, or classification of re-posts, we're left with a system lacking human warmth, character or the benefit of the varied perspectives of the various people who do all this re-posting. The SEO scene is also following this topic quite closely, eg. see the critique, discussion and background info (slideset with RT stats) http://danzarrella.com/mangle-retweets.html That post claims (see slides at http://www.slideshare.net/danzarrella/the-science-of-re-tweets?src=embed ) that * less than 1/4 of all tweets (on twitter; I haven't seen statusnet/identica stats) contain links * over half retweets contain links If this is the case, I suggest it's worth thinking about this idiom explicitly, whether at the API/protocol level or at the UI level. cheers, Dan _______________________________________________ StatusNet-dev mailing list [email protected] http://lists.status.net/mailman/listinfo/statusnet-dev
