Marcel Molina wrote:
> To give you some ideas of how you can use the API to display retweets,
> here is a recent mock up of one of the potential UIs for the retweets
> timeline on twitter.com:
> http://a1.twimg.com/example-retweet-ui-18-sep-09.png

In this example, how did you retrieve the number and names of people that
retweeted? Did you have to issue a separate request to statuses/retweets for
every single tweet in the timeline? I am concerned about how this affects
(mobile) clients on slow and/or expensive connections. Also, how will this
interact with the API rate limiting?

I would like to present the names and count of all *friends* (people the
user is following) that re-tweeted the tweet. This is a much more useful
metric than the total number of strangers worldwide that retweeted it
(especially when you consider re-tweeting spammers). It seems like this will
be impossible if more than 100 people re-tweeted the tweet. The old design
was much better in this respect.

In particular, now how can we answer the question "who do I need to
un-follow to stop get this tweet out of my timeline"?

There's a potentially serious problem with tying the display of the retweet
with the first time it is retweeted. Let's say one of your friends ("Ae")
retweets something on a Friday night. Then a bunch of your friends tweet
through the weekend. Then, 50 of your other business associate friends show
up for work on Monday and retweet the same thing Ae re-tweeted on Friday
night. You will likely not even realize that your business associates are
interested in that retweet when you show up for work on Monday, unless you
scroll page through all those weekend tweets to the time Ae retweeted them.
With the old design, the client could handle this in a much smarter way.

Will there be an increase in the API rate limits when this change is made?
AFAICT, this new feature increase the number of requests my client makes per
"refresh" substantially for many of my users. The increase in the number of
requests seems to be a killer because of rate limiting.

I would love to be included as a tester of this in the web UI. I am
@BRIAN_____ and @GOROGOROmobi.

Regards,
Brian

Reply via email to