Hi Will,
Its good to get some replies, I was getting a little worried that no-one
wanted to talk it through ;)

I have already seen changes in syntactical use of RT some people are
starting to use ">", however, my main point is that things change and
codifying RT as a solution is restricting emergent behavior rather than
developing it.  I can see value in clearing the language around a retweet,
the language used "RT" or ">" is not obvious for new users.  If a RT API can
clear the syntax up then it is a good thing, but I don't think it will,
people can type still type RT (and I suspect most will) on a reply and do it
that way.

The introduction of a RT API is intended to change the current convention of
RT - so it is different from the mentions API which was an opening of what
was demanded (I used to hit the search API 20 times a second with Twe2 until
mentions was introduced).

Current RT's work because in most cases the original user is still
referenced (a simple reply with RT prepended to the tweet) and it can be
typed from the input box ( a lot of people still edit a tweet before they RT
- to shorten it, to add opinion etc).  I will probably still use the RT
syntax because I can simply type it in a reply - whether or not the client
supports it or not.

Mentions with the @ syntax works very well because it can be typed in with
no specific need for an API, much like Twitter do with direct messages.  If
twitter parsed RT at the start of the tweet much like they do "D" and this
allowed all RT to be visible via the API methods then I don't have much of
an issue, but they can't do this because there is little way to know the
original tweet (unless the API is used) - and this is my problem; it will be
bypassed by some users and then won't be available in the API and it will
raise a lot more questions

RT's are being used and emerged from the need to express a +1 for a tweet
and also as Forwarding facility, my point is: if the favoriting API was
expanded and opened up then this reduces the use case for the RT API by one,
and also focuses the RT API soley on forwarding - the two combined are very
powerful as you have two sets of useful information and not just one. I as a
user can: express a like and not share; share and not like; share and like.

I have it on some authority that this RT API will be implemented regardless
- so my arguments maybe moot.  After all I suspect that the majority of the
development work has already been done.

Paul

2009/8/17 Will <wyme...@gmail.com>

>
> I just wanted to point out a few counterpoints to Paul's arguments.  I
> think it's important that they are brought up and I hope they are
> taken at face value and not construed in any way as a personal attack.
>
> 1. The mentions API evolved from the @reply convention and originally
> was also a 'user developed based meme' that Twitter decided to
> incorporate into their site and API.  The mentions API is now a key
> part of the Twitter landscape and I don't think anyone can imagine
> Twitter without that API.  The retweet convention has been used by the
> twitter community for as long as I have been a part of it.  I don't
> see the community 'changing its mind about it' anytime soon.
>
> 2. Virtually all third-party clients support some method of
> retweeting.  This new API would not add clutter to a client's
> functionality as the method is already supported.  In fact, it would
> serve to standardize the retweet method, which is a good thing as
> clients format retweets differently.  (Even TweetDeck has a retweet
> button.  Not sure why you don't just use it instead of 'hitting reply
> and typing RT at the front'.)
>
> As a third-party developer, I am bummed at the thought of having to
> rebuild my app to support the new 'timelines' that Twitter is
> requiring clients to support, but for the sake of evolution of the
> platform, I am happy to see the progress.  I also somewhat agree that
> the solution to adding comments and crediting the originating
> authority is hacky and will not satisfy everyone's retweet needs, it
> brings it closer.  And I fully support progress . . . as long as it's
> in the right direction.  No matter how small.
>
> Will
> http://twitter.com/wymesei
> http://twitterneni.com
>
>
>
> On Aug 15, 7:00 pm, Paul Kinlan <paul.kin...@gmail.com> 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
> >    2. 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.
> >    3. 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.
> >    4. 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.
> >    5. 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.
> >
> > Paul - grumpy - Kinlanhttp://twitter.com/PaulKinlan
>

Reply via email to