On Sat, Aug 15, 2009 at 10:00:30AM +0100, Paul Kinlan wrote:
>    Hi Guys,
>    When I saw the original message stating that the retweet API I was
>    about to say straight away that I despise the idea, but I thought I
>    would refrain - give it some thought. I still despise the idea and I
>    have to make it known the reasons why I think it is a very very bad
>    idea and in the long term will negatively affect Twitter as a
>    communications platform for the future.
>     1. You are embedding a user developed based meme into the Twitter
>        infrastructure - the popularity of RT itself may wane after some
>        point. Users are very fickle, they change their minds, take a stand
>        and don't listen to them - you know your platform and I am pretty
>        sure you know that this is a bit of a hack. Â Let users use they
>        system how they want, they will evolve how they use it, constraints
>        via an API
>     1. Twitter already has the capability to do smarter things
>        that completely negate the need for this API if they just change
>        the current API a little
>      Not every app will use RT API (especially legacy ones) and not every
>    user will use it and as such Twitter and this list will get lots of
>    questions why certain RT's are accessible by the retweet API. Â Again,
>    RT's are a user concept, and is very easy for them not use.
>      Whilst I use TweetDeck, I really dislike the amount of utility
>    buttons it has and the amount of options it has - introducing another
>    API for another function is tantamount to the same thing, you are
>    asking us app developers to include more options in our apps. Â The
>    great thing about a RT is that I just hit reply and type RT at the
>    front.
>      A big thing that people have requested is that quite often there is
>    not any room in the very limited 140 characters to add comment to a
>    retweet, this doesn't seem to solve that problem.
>      Authority of a user based on a RT and credit to the originator is a
>    misnomer, no one actually needs it, very very few people care about -
>    and when they do care about not getting the credit for the original
>    tweet you have to ask why do they care? and why should we care? again
>    it is still very easy to bypass. Â If you have a problem with it, as
>    per the Twitter TOS you are the copyright holder of your content.
>    My honest vote is not to pollute the Twitter API with a special RT
>    capability, rather:
>      * Enhance Favorites and the favorites API, allow me to get a list of
>        everyone's favorites, allow me to see a list of people who
>        favorited a tweet. Â If you look at the proposal for RT API it is
>        doing something similar to this. The entire UX for Favorites makes
>        a lot more sense than retweet - infact you can go as far as saying
>        if you like something favorite (star) it, if you really like your
>        favorite - Forward (RT).
>      * Allow me to get a list of a users favorites (similar to the "Likes"
>        feed in FriendFeed) - this type of concept is so powerful, I can
>        discover people who share very similar likes. Â I can also do Best
>        of Day very easily
>      Enhance in_reply_to, allow me to see all tweets that reply to this
>    tweet in an object returned by the current api ( that is so I don't
>    have to keep re-querying the search API), further more allow me to
>    request N levels deep of replies to a given tweet (yes this is similar
>    to threaded comments)
>    So by enhancing Replies and favorites you can remove the need for
>    special RT API because you can combine both parts of the API to get at
>    the originator of a popular tweet, have notification and
>    visual queues of popular tweets. thus keeping the twitter API
>    simple.Â

I agree on everything Paul Kinlan here so clearly expressed.

+1 to enhancing the replies and favs first.

:   Marteen
:   CA49 DEE9 7F5B A373 5121  2F82 1047 1BB9 83EC D3C9

Reply via email to