On 27 Gen, 00:08, Damon C <d.lifehac...@gmail.com> wrote:
> If you tweeted a question then something completely unrelated (some
> people's Twitter stream _can_ be likened to verbal diarrhea), and
> people replied with a simple @ - then those same 6 @replies would have
> lacked the proper context.
>
> When that happens, it's a challenge in any client (especially the web)
> to click through to an incorrect tweet, back out, look at the old
> tweet, observe the time, review the user's timeline for a matching
> time, etc.
>
> This process is similar when the "in reply to" metadata doesn't exist,
> with the exception of misleading the user in the first place.
Yes, this is true. However, your argument supports rolling back the
API change in terms of UI productivity.
You say the cost of having to find the correct original tweet with
incorrect context is similar to the cost when there's no context at
all. Fair enough. Let's say it takes 10 seconds to find the original
tweet with incorrect or no context, and 1 second if the context is
correct. Consider three scenarios:
1. A user manually replies to a tweet before the API change, and the
auto-linked context is correct.
cost: 1 second to find correct original tweet
2. A user manually replies to a tweet before the API change, and the
auto-linked context is incorrect.
cost: 10 seconds to find correct original tweet
3. A user manually replies to a tweet after the API change.
cost: 10 seconds to find correct original tweet
It's abundantly clear that the behavior *before* the API change saves
time, because there were times (and we're talking about significant
numbers here) when the auto-linked context is correct. After the API
change, you *always* have to go through the rigamarole of going to the
twitterer's profile page, which means it *always* takes time to find
the correct tweet.
The practical situation is so aggravating after the change that I
simply can't believe that people are arguing against, at the very
least, a compromise solution.
> I for one appreciate the decision to not automatically set the "in
> reply to" metadata as I would rather have accurate information than
> not. Most clients _should_ adopt this behavior. The web is definitely
> a challenge, but I'm sure some jQuery action could be tossed in to
> evaluate @user's last tweet on the page, eh Twits? (which _might_ be
> more accurate than just the most recent status id)
I have never argued that accurate context is a bad thing. I argue
that the pendulum has swung so far back in the opposite direction that
the current situation is worse than before. If Twitter wants to do
some evaluation based on the date of the manual reply to find what
would have been the auto-linked tweet, that's fine. ***But this
should be made available in the API, too, not just the web.***
Implementing it only on the web means that Twitter clients would be
left in the lurch.
