I disagree. Wrong context for a conversation is useless – so in that sense, it's better not to have it at all. We here at Filttr (http:// filttr.com/) have pseudo-conversation tracking (as more and more applications/services are implementing it), and this new behaviour makes it sensible. If an app's current behaviour doesn't complement this change, then it should change its behaviour as *this* is the right thing to do. FYI, the web *does* set an 'in_reply_to_status_id' via query string if you click the reply link on a tweet. Twitter's 'guessing' was never good, and it saves us about 3-4 checks to make sure the tweet really *was* a reply to the tweet Twitter tells us it was (take @having for example, the biggest pain).
The issue you point out of, Twitter displaying tweets isolated – I support your suggestion of pagination, not the "display five tweets". Let's not clutter up a nice and simple page, shall we? :) To re-iterate (for everyone), the new behaviour is just fine, and if your app isn't already setting the 'in_reply_to_status_id', it's about high time it did. On Jan 24, 8:34 am, simX <[email protected]> wrote: > At @al3x's request, I have decided to start a conversation on this > topic here. > > At issue is the recent /statuses/replies API change that occurred two > days ago. The result of the change causes any "manual replies" to not > have an "in reply to" link associated with the tweet, whereby "manual" > I mean any tweet reply that does not set the "in_reply_to_status_id" > parameter. > > Before the API change, if a client (including the web interface) did > not specifically set the "in_reply_to_status_id" parameter, the tweet > would still have an "in reply to" link, but it would simply point to > the latest tweet (at that point in time) of the person that the tweet > is replying to. > > After the API change, this is no longer the case. If a user does not > specifically click on a reply swoosh in the web interface, and instead > manually types "@al3x", for example, the tweet does not have an "in > reply to" link. > > I consider this a very bad change. > > First of all, this completely breaks existing client behavior. I have > seen this issue manifest itself with Twitterrific, Twhirl, the web > interface, and most likely all other clients, because up to now they > have either been oblivious to the "in_reply_to_status_id" parameter or > they have been banking on the fact that not setting it causes the > tweet to link to the latest tweet of the other twitterer. > Additionally, I don't think all Twitterers who use the web interface > realize that they need to click the reply swoosh in order to get the > "in reply to" metadata, because earlier in Twitter's life, the > "in_reply_to_status_id" parameter was nonexistent, and it was usually > faster to manually type "@al3x" rather than to click the reply swoosh. > > I would submit that breaking existing behavior is something that > should not be done willy-nilly. However, disregarding the pre- > existing behavior argument, there is a more significant argument for > the earlier behavior. > > With the earlier behavior, the "in reply to" link, even though it may > not necessarily point to the exact tweet that the person is replying > to, it still gives a rough context of the conversation. After the API > change, there is *no* context *whatsoever*. Some context, even if > it's incorrect, is better than no context at all. > > Even if the "in reply to" link is incorrect, it gives an upper bound > to a possible tweet that is being replied to. There is an implicit > practical lower bound (people usually don't respond to tweets that > have been made 3 months ago). Without the "in reply to" link, the > upper bound is lacking. Consider years down the road when someone > wants to follow the conversation, it will be easier to figure it out > the conversation with a rough context. > > I appreciate the need for Twitter to want to only link tweets so that > exact conversations can be followed. However, I believe the former > behavior has merit as well, and it's a little dismaying that Twitter's > "product folks decided otherwise", without seemingly considering the > effects of the API change. > > I would hope that Twitter would make an API change so that both are > possible. Perhaps roll back to the previous behavior, but instead > include another parameter with query responses that specifies whether > the "in reply to" link is exact or whether it's only approximate. In > fact, you might have three possible values for this parameter, one > which specifies an exact link, one which specifies an approximate > link, and one which explicitly specifies that no link should be made > at all. The user can decide whether to eliminate context (because > he's starting a new conversation), but the *default* should fall back > to approximate context, not no context at all. > > Another change that would be most welcome in alleviating this problem > is for individual tweet pages to always display five tweets: the exact > tweet being targeted, and two tweets before and two tweets after, so > that if the context is only approximate, the viewer does not have to > go to that Twitterer's profile page in order to find the exact tweet > context. (Better yet would be to have pagination available on > individual tweet pages.) > > Please consider making a change on this very soon, because given > existing user and Twitter client assumptions, the current API is > making it very aggravating to follow conversations that are not exact, > and there surely are many of these "approximate" conversations.
