Weird - there was no emphasis intended on the favoriting as a first class
citizen paragraph - damn iphone :)

2009/8/18 Paul Kinlan <paul.kin...@gmail.com>

> Hi zac,
>
> I dont think I said there is a decrease in usage just that it is developed
> by the community and as such may wane in popularity as another type of
> emergant mechanism takes it's place.
>
> I would argue that retweet should stay roughly as is and not be directly
> codified into the core architecture of Twitter as is currently being
> proposed.  I belive someone suggested a simple retweet of Id working the
> same way as replies and allowing you to enter your own comments along with
> it.
>
> The fact that there are three new views and that you can't modify a retweet
> smack of over complexity and a destruction of what makes Twitter the way it
> is - it's simplicity and I would go as far to say that it will abruptly stop
> emergant behaviour around rt.
>
> My other point generally is that this is very similar to the favoriting
> api apart from the injection into the users stream. I would love to see
> favoriting as a first class citizen.
>
> A reply and a favorite would work in a similar way to the new rt api if
> favorites were more public.
>
> The fact that retweet is part of the api and it means that if everyone
> doesn't flip over it means that the api isn't really working.
>
> One of the important things for a general user, is that they see tweets
> from people they follow as they are placing value and trust in knowing
> something is coming from one of the people they are following - they are not
> bothered that an external site can use the information or that a developer
> can do some funky stuff with the data.
>
> The other point is that is the problem the message stays intact - it only
> covers one portion of the case for retweeting.
>
> The final point I was making originally is that some sections of the
> community were less than pleased that they were losing credit for the
> original tweet (I have seen some bonkers arguments about the source of
> tweets) and the the retweeter was getting credit and not the retweetee.  The
> retweet api solves that problem, but it is in my opinion such an edge use
> case that it doesn't matter and copyright will protect you if you are
> actually that bothered about losing credit.
>
> I am not a fan of this api, but I can be convinced :) and from what I have
> been told the api is unlikely to change too much.
>
> Paul
>
> On 18 Aug 2009, at 00:32, Zac Bowling <zbowl...@gmail.com> wrote:
>
>
> I see value in a retweet API.
>
> I disagree on your first point. Retweets have been around for some
> time and still happen quite a bit. No decrease in usage. (its even
> showing in sites like mashables retweet button and
> http://iphone.tomtom.com/ (look at the share button)).
>
> The only issue I see is that not everyone will flip over to the new
> system immediately so it will not be fully adopted into the system and
> inconsistent across clients for a while.
>
> Point 3, no one says that you have to add support for it. However
> unifying the retweet functionality drastically simplifies consumption
> of retweets and outweighs any slight input requirements and an API
> complexity required for it.
>
> Point 4, I think you missing the point of how it would work
> internally. As I understand it, the original 140 char message stays
> intact.
>
> Point 5, I'm confused with what point you are trying to get across.
>
> Zac Bowling
>
>
>
> On Sat, Aug 15, 2009 at 2:00 AM, 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.
>
>
> 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
>
>
> 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.
>
> Paul - grumpy - Kinlan
>
> http://twitter.com/PaulKinlan
>
>

Reply via email to