"in reply to" metadata missing for manual replies

[simX]

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.

[Jesse Stay]

How about, rather than guessing which thread to link it to, if it is manually sent, create a meta "tag" variable that identifies that an individual has been mentioned in the Tweet.  Those that want their Tweets to appear threaded can go to their preferred UI and do so, and those that don't care can at least get their message out to the individuals they're mentioning.  As clients begin to build UI around this threaded interface of linked replies, users will have to be taught that just manually entering @username anywhere won't get it in the threading, but IMO that's just a Ux problem.  In the end this solution is win-win. Users can still choose manual syntax, or they can thread their replies.  Either way the correct individual gets notified when they are replied to, whether you can track what that reply was to or not.

--Jesse

[Aditya]

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.

[Stuart]

2009/1/24 simX <simsi...@gmail.com>:

> 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.

I kinda agree but I can also see where Twitter are coming from. The
display of conversations loses meaning when the in reply to id is
automatically assigned. However I would have preferred to see an
attribute added to indicate whether it was specified or automatically
assigned. That would IMHO give the most flexibility for client usage
and analysis.

-Stuart

--
http://stut.net/

[TCI]

I disagree with SimX.
I consider this change very useful and necessary since it does
organize the conversation properly. Consider that many people use
@replies to start a conversation with another user, not necessarily to
reply to *any* preexisting tweet. If all you need is an upper bound,
just use the reply's post time.

[PockeTwitDev]

Even if the in_reply_to_status_id isn't being set automatically, the
in_reply_to_user_id *is*, so you can still see what user it was in
reply to through the API even if the client didn't provide the field
when posting the update.

It's very disconcerting to attempt to view a conversation and have it
completely broken because twitter guessed at the wrong status, and
this change was a long time coming. I hope that clients can update
quickly and follow the specs laid out in the API.

[Cameron Kaiser]

> > 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 kinda agree but I can also see where Twitter are coming from. The
> display of conversations loses meaning when the in reply to id is
> automatically assigned. However I would have preferred to see an
> attribute added to indicate whether it was specified or automatically
> assigned. That would IMHO give the most flexibility for client usage
> and analysis.

This sounds like a good middle ground to me.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- UNHOLY UNION: Heavy Metal and Electronics -> Twisted Trans Sister ----------

[Steve Brunton]

On Sat, Jan 24, 2009 at 12:27 AM, Aditya <adi...@adityamukherjee.com> wrote:
>
[..snip..]

>
> 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.
>

While I'm currently only building some internal applications for
${work}, the next [REDACTED] site redesign might change some of that.
The new release way of handling replies seems the sane way, especially
if you want to show properly threaded context. It would be the way I
expected it should work if I hadn't read the API and messed with it.
I've always found that assuming or guessing you know what the end user
is attempting to do is a sure sign of something going wrong.

-steve

[simX]

On 24 Gen, 08:01, Steve Brunton <sbrun...@gmail.com> wrote:

> I've always found that assuming or guessing you know what the end user
> is attempting to do is a sure sign of something going wrong.

But that's exactly what the *NEW* way of handling replies is doing!
It's *assuming* that when a user manually types an @reply, the user is
obviously starting a new conversation. In my experience it's clear
that this is absolutely not the case. Now, with the new change, about
half of the @replies in my timeline are clearly in response to other
tweets, yet lack the "in reply to" link from the web interface. It's
*extremely* aggravating.

*Both* methods (auto-linking manual replies and not linking manual
replies) assume something about what the user is doing. Assumptions
will *have* to be made in order to keep the Twitter interface simple,
and I think the current assumptions that are being made are bad for
the UI of Twitter.

Here are two things to keep in mind:

1. On the Twitter web interface, the only way to set the
"in_reply_to_status_id" parameter is to click the reply swoosh. How
many people know about this? Furthermore, how *fast* is this? If I
were to reply to @al3x's latest tweet, it would almost *certainly* be
faster to simply type "@al3x" instead of moving my hand off the
keyboard and clicking the reply swoosh of @al3x's latest tweet.
Humans are lazy creatures. What do you think they are more likely to
do? Combine that with the new assumptions that Twitter is making, and
it clearly disrupts conversation linking when it would usually be
accurate.

2. When you're talking in normal conversation, what's the default
assumption? If I say something to you in person, it's assumed that
I'm usually replying to the last thing you said. I never have to
*explicitly* say that. For example, if I say, "What time is it?", you
don't say, "In reference to your question about the time, it is 5 PM."

The new assumptions in the Twitter API are akin to requiring users to
make conversation linkage explicit. It requires more effort on the
part of users, and people aren't always going to go against their
habit of being lazy.

[simX]

Just as a data point, of the 20 most recent @replies I have received,
6 of them lack the "in reply to" metadata when they are clearly
responding to a specific tweet of mine.

That's a linkage failure rate of 30% due to this change in Twitter's
API behavior. I would say that's pretty severe.

[Christopher]

Manually typing "@username blah" in the entry field on a client should
set in_reply_to_user, obviously. That requires a client-side change,
but I think right now, the backend should help out with this; it
should be done for the next few weeks at the very least.

Why be all kind about the backend assistance? Because the web UI
doesn't do this right now. Until the web UI does what third-party
clients are being told to, I find it hard to support any API change
that breaks replies as badly as this one has.

[Fábio Silva]

Well, would be nice to have both behaviors working together (the typing one at the textarea box and the 'reply to' button).
I would think of (maybe) query for the last tweet regarding the @name I'm typing directly at the textarea box. The returned record would (if exists) give me the 'reply to' behavior thing. And if no data returned, we have the ' we are starting a new conversation' thing. And we don't have the need to refactor the 'reply to button' behavior. That would be an example of a workaround regard the problem at typing directly a tweet. Would that be too expensive from a performance point of view?

If this has nothing to do with this conversation, sorry. ^^

Best regards
Fábio Silva.

[Damon C]

But this depends on how fast you tweet and how/where they see the
message, doesn't it?

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.

I've always wanted the Twitter web to have forward and next buttons on
a tweet status page (for numerous reasons), and that's a great use
case (and justification) for linking to incorrect status id's...but it
just doesn't exist.

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)

dpc (@dacort)

[simX]

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.

[simX]

When is this problem going to get fixed? 1.5 months after the
original API change, I am still getting a significant portion of
replies in my timeline that are supposed to be *to a specific tweet*,
but are not because Twitter is no longer auto-linking manual @replies
and people are lazy and don't want to take the time in the interface
of their client to "correctly" reply to a tweet.

Note: user laziness is *not* a failure on the part of the user, this
is a failure on the part of Twitter. Requiring a user to go through a
specific part of the UI just to reply to a tweet is not acceptable.

When is a viable compromise solution going to get implemented so that
@replies become tolerable again?

[Chad Etzel]

Just curious, of these replies that *should* be linked to a specific
tweet, how many are coming "from web" and how many "from another
application" ?
-Chad

[atebits]

> Requiring a user to go through a specific part of the
> UI just to reply to a tweet is not acceptable.

How else would you expect it to work? Twitter can't read users' minds.

[simX]

Most of them are coming either from Twitterrific or from "web", but
that's probably just an artifact of those users whom I follow. Most
of my friends on Twitter are those who do Mac and iPhone development,
and are most likely using Twitterrific on their Macs.

Incidentally, it was pointed out to me that m.twitter.com does not
even offer the reply swooshes that set the "in reply to" metadata. So
much for Twitter clients "conforming" to the new API. :rolleyes:

Also, it should be noted that while there are some users that are
constant violators (and seemingly never go through the UI steps to set
up the "in reply to" metadata), other users sometimes *simply forget*
to make a tweet so the correct metadata is applied. This is expected;
humans make errors all the time. Breaking metadata because of it is
lame.

-- Simone

[simX]

Uh, Twitter doesn't *need* to read users' minds, it just needs to
merge the two approaches together. Before, Twitter auto-linked
everything, and manual replies were considered genuine replies even if
they weren't. Now, it auto-links nothing, and manual replies aren't
auto-linked even if they *are* genuine replies.

So Twitter can auto-link manual replies that aren't specifically
marked as such (e.g.: by clicking the reply swoosh in the web
interface), and store that data *separately* from genuine replies that
are specifically marked as replies. That is, the "in_reply_to" data
can have a flag letting the client know if the data was auto-linked or
if it was not. Then, clients can decide what to do with that extra
data.

For example, there could be a setting in the Twitter web interface to
show "in reply to" links for manual replies *and* genuine replies, or
to show "in reply to" links only for genuine replies. That way it can
satisfy me (and the other users that feel the same way), as well as
those that only want the most accurate links between conversations.

I (and some of my followers) think that more context is better than no
context at all, even if the context is only approximate. Others think
that only accurate context is valuable, and approximate context isn't
at all. Such a change would preserve *more* metadata and would allow
*both* kinds of users to use Twitter how they want to.

-- Simone

[Abraham Williams]

One of my main concerns is with SMS. There is current *no* way for SMS users to reply to a specific status.

I recently submitted an issue to make the in_reply_to_status_id updatable so people could repair their broken threads if they wanted to. But it has been marked as wont fix. http://code.google.com/p/twitter-api/issues/detail?id=309

Are there more false positives happening before the change or are there more correct links that are now not being applied? I would wager the first is correct. I find it nice that now they are almost always correct.

On Tue, Mar 3, 2009 at 19:04, simX <simsi...@gmail.com> wrote:

Uh, Twitter doesn't *need* to read users' minds, it just needs to
merge the two approaches together.  Before, Twitter auto-linked
everything, and manual replies were considered genuine replies even if
they weren't.  Now, it auto-links nothing, and manual replies aren't
auto-linked even if they *are* genuine replies.

So Twitter can auto-link manual replies that aren't specifically
marked as such (e.g.: by clicking the reply swoosh in the web
interface), and store that data *separately* from genuine replies that
are specifically marked as replies.  That is, the "in_reply_to" data
can have a flag letting the client know if the data was auto-linked or
if it was not.  Then, clients can decide what to do with that extra
data.

For example, there could be a setting in the Twitter web interface to
show "in reply to" links for manual replies *and* genuine replies, or
to show "in reply to" links only for genuine replies.  That way it can
satisfy me (and the other users that feel the same way), as well as
those that only want the most accurate links between conversations.

I (and some of my followers) think that more context is better than no
context at all, even if the context is only approximate.  Others think
that only accurate context is valuable, and approximate context isn't
at all.  Such a change would preserve *more* metadata and would allow
*both* kinds of users to use Twitter how they want to.

-- Simone

- Show quoted text -

On 3 Mar, 16:24, atebits <loren.brich...@gmail.com> wrote:
> > Requiring a user to go through a specific part of the
> > UI just to reply to a tweet is not acceptable.
>
> How else would you expect it to work?  Twitter can't read users' minds.

--
Abraham Williams | http://the.hackerconundrum.com
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.

[Cameron Kaiser]

> One of my main concerns is with SMS. There is current *no* way for SMS users
> to reply to a specific status.

Actually, this also affects mobile web, since you can't mark a post to reply
to on m.twitter.com either (unless you are using the standard interface,
of course).

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- It's tradition, that makes it okay. -- Weird Al, "Weasel Stomping Day" -----

[simX]

Back and forth with atebits over e-mail:

>>I, personally, found the false positives much more acceptable than the
>>current situation where you have to hunt for originating tweets for "false
>>negatives".

>Doing anything interesting like automatically crawling conversation
>webs is flat out impossible with false positives, and only an
>annoyance with false negatives.

It is a lie that it is "impossible" with false positives. With false
positives, you can *always* crawl all conversation webs when they are
correct, even when auto-linked, and you can easily tell when the auto-
linking targeted an incorrect tweet. With false negatives, it's a lot
worse because sometimes you can't crawl a correct conversation web at
all.

It is *far* faster for a user to identify a false positive then a user
to hunt for a false negative. Again, it takes 1 second to identify
that the auto-linking was incorrect, but 10 seconds to MINUTES to find
the correct reply to a false negative, especially if the user is a
prolific tweeter.

Again, the new "in_reply_to_status_id" is relatively new, so with most
people using that, the conversation webs will largely be correct. But
when someone forgets to use the reply swoosh, I'd rather have Twitter
auto-link the reply even if it causes some conversation webs to be
falsely connected.

>I would also argue that false negatives should be blamed on crappy
>clients. I know that a few clients (up until recently) didn't set the
>in_reply_to_status_id AT ALL, even for tweets where the user
>*explicitly* replies to a particular tweet (i.e. clicked the reply
>button next to it).

I'm sorry, but also no. I have seen many people who are using
conforming clients not jump through the UI hoops to perform a
"correct" reply, both out of habit (i.e.: constant violators), or out
of error (i.e.: just a one-time mistake). I prefer to take both kinds
of human error out of the question via auto-linking.

The false negatives were caused by people not used to the fact that
they have to perform additional UI actions because of the change. To
force users to do something to get a correct reply is stupid, in
contrast to letting them do what they naturally do (which is how it
was before).

>There will be some growing pains, which will last as long as people
>continue to use crappy clients. After that, many really interesting
>things become possible.

No, again, people are already using conforming clients. And, no,
again, even with false positives, really interesting things are
*already* possible. False positives do not inhibit any of those
really interesting things.

>That sounds rather hackish. I think the correct long term solution is
>to leave it exactly as-is. The other thing I'd like to point out is
>that with the old system, there was no way to express a "general"
>reply. By that I mean a reply to someone that *isn't* in response to
>a particular tweet... more of just a "directed" tweet - which is a
>legitimately useful thing to express (and I'm not sure how you would
>express it using your workaround).

*facepalm* I am well aware that you couldn't express a general reply
with the old system. Stop convincing yourself that I'm advocating to
go back to the old way. With my way, you do it exactly as you do it
now, and as you did it before: you simply type in "@atebits" and then
your message. Twitter will auto-link it, and then display the link if
the user's prefs say to display auto-links. The user can figure out
whether the context is correct or not.

The point is that humans are much more capable of determining whether
context is correct or not, but computers are far better at
establishing any sort of context in the first place. So the most
effective way to establish the best context is to let both computers
and humans do what they are best at doing. Computers will provide as
much context as possible, and humans will throw out the context that
isn't good.

-- Simone

[atebits]

I don't have much time to debate this, but two points:

1. If a client is making users jump through hoops to reply to a
specific tweet, the client is doing it wrong. Twitter.com does an
excellent job making it easy, as do the vast majority of iPhone
clients.

2. Adding another setting to control whether or not you see auto-
linked reply links (as Simone proposes) is too complicated. I dare
you to try to explain what that setting does to the vast majority of
users. Most of them can't figure out what the current replies setting
does.

The end of auto-linking was a fantastic change for two reasons: 1. it
keeps everything simple (no new settings or flags or functionality),
2. it allows developers to trust in_reply_to_status_id, paving the way
for some *really* fantastic stuff down the road.

Loren

[TjL]

On Wed, Mar 4, 2009 at 4:38 PM, atebits <loren.b...@gmail.com> wrote:

> 1. If a client is making users jump through hoops to reply to a
> specific tweet, the client is doing it wrong.

[snip]

> The end of auto-linking was a fantastic change for two reasons: 1. it
> keeps everything simple (no new settings or flags or functionality),
> 2. it allows developers to trust in_reply_to_status_id, paving the way
> for some *really* fantastic stuff down the road.

Agreed on both points.

I like the possibilities for actual conversation threading (not yet
realized in summize searches but you can see the potential)

With the exception that m.twitter.com really needs to get a "reply"
button that works properly.

If people are too lazy, well... tough. Just like proper mail
filtering/threading, if they can't be bothered to figure out how it
works, they'll lose some of the advantages that the software can
provide for them.

If they are using outdated software, then all sorts of things may
break, including favorites (broken in an earlier version of
Twitterrific when the API changed). Again, tough.

There *should* be a way to start a "conversation chain" without
setting an in-reply-to being added where it doesn't belong. That's
where it makes sense that you would type in @NAME by hand.

Twitter shouldn't be held hostage to "the way it used to be" for a
feature which was clearly broken by indicating a relationship between
two posts when there was none. Neither should they be held hostage to
"Users are too lazy to do it the right way."

And yes, if their twitter client makes "real" replies too hard, they
should be updated to make it easier or they should fall into disuse.

TjL

[simX]

On 4 Mar, 14:25, TjL <luo...@gmail.com> wrote:

> There *should* be a way to start a "conversation chain" without
> setting an in-reply-to being added where it doesn't belong. That's
> where it makes sense that you would type in @NAME by hand.
>
> Twitter shouldn't be held hostage to "the way it used to be" for a
> feature which was clearly broken by indicating a relationship between
> two posts when there was none.  Neither should they be held hostage to
> "Users are too lazy to do it the right way."

As I have attempted to explain to atebits and to others, I AM NOT
ADVOCATING TO GO BACK TO THE WAY IT USED TO BE. I am advocating for a
*compromise* solution. I *understand* the need for there to be an
accurate way to follow conversation chains, and I *like* that the new
way allows for this. But the approximate context that the previous
method used should *also* NOT be tossed out.

If an extra flag is set in addition to the in_reply_to_status_id
metadata, then BOTH methods can be used. Clients which want to throw
out any non-exact context can accept only that data which includes the
"exact" flag, and clients which want as much context as possible can
simply ignore the flag. BOTH METHODS CAN BE DONE AT ONCE.

> And yes, if their twitter client makes "real" replies too hard, they
> should be updated to make it easier or they should fall into disuse.

This is just arrogant. This is completely false. When someone wants
to reply to me, typing five characters, "@simX" is *far* faster than
moving your mouse to target a tiny little reply swoosh. It takes a
whole second to move your hand to the mouse, when you can type those 5
characters in under a second if you're a fast typer. Saying that
users who refuse to jump through the UI hoops are somehow inferior is
lame and condescending. Not only that, but humans often make mistakes
and simply forget to target a specific tweet. Losing the context
because of simple human error is unnecessary.

The @reply syntax was created organically by users. It was not
created by Twitter. As such, it represents more of how users actually
want to interact with Twitter. That functionality should be preserved
AS WELL AS providing a way to accurately follow conversation chains.

The mere fact that there are genuine replies that don't have the
in_reply_to_status_id metadata set demonstrates that the new interface
should not completely replace the old functionality.

-- Simone

[TjL]

On Wed, Mar 4, 2009 at 9:51 PM, simX <simsi...@gmail.com> wrote:
>> And yes, if their twitter client makes "real" replies too hard, they
>> should be updated to make it easier or they should fall into disuse.
>
> This is just arrogant.  This is completely false.

Call it whatever you want. I call it my logical conclusion.

> When someone wants
> to reply to me, typing five characters, "@simX" is *far* faster than
> moving your mouse to target a tiny little reply swoosh.  It takes a
> whole second to move your hand to the mouse, when you can type those 5
> characters in under a second if you're a fast typer.  Saying that
> users who refuse to jump through the UI hoops are somehow inferior is
> lame and condescending.

You're talking to someone who used PINE for years after people had
moved on to graphical mail clients, and whose major complaint about
Mac OS X is that it isn't as easy as Windows in using command keys
(even though I have lots of my own set) and purchased a program called
KeyCue to make it easier for me to use the keyboard instead of the
mouse.

Telling me I don't understand the value of keyboard usage just makes
you sound like an uninformed idiot, if you want to start calling each
other names.

If someone is reading Twitter on the website, they are already using
the mouse, as there is no way to move back and forth between pages by
the keyboard. They are (more than likely) using the scrollbar by
either using their mouse or their mouse scrollbar. So the idea of
moving their mouse 2" to click the "swoosh" (which I agree could be
bigger and which I'd agree should NOT be hidden by default which I
think was a lousy change by Twitter, Inc and makes it harder for
people to know where they are aiming for.

In addition they are in all likelihood going to have to use their
mouse to get into the textarea at the top of the screen in the first
place.

So your argument of mouse vs keyboard use doesn't even convince ME, an
avid keyboard user.

> Not only that, but humans often make mistakes
> and simply forget to target a specific tweet.  Losing the context
> because of simple human error is unnecessary.

Instead you just want to add extra unnecessary metadata and then have
programmers try to guess what the original intention was.

> The mere fact that there are genuine replies that don't have the
> in_reply_to_status_id metadata set demonstrates that the new interface
> should not completely replace the old functionality.

Maybe to you, who is convinced that every Twitter client programmer
should be expected to write extra code because someone is too lazy to
move their mouse 2 extra inches to click the arrow.

And what AI are they going to use to determine whether this extra
metadata or lack thereof means that this is an actual reply? They're
going to go whichever they prefer.

Meaning that they are going to get a different result for
'conversations' depending on whether they use Summize (which is going
to have to choose one method) or some other client.

It's possible that I might have one client on my desktop that does it
one way and another client on my iPhone that does it another way.

OR, we have one way that works the same on every client.

I choose consistency as a better alternative.

Sorry if you don't agree, but telling me that I don't understand your
argument is what I find arrogant and completely false.

I'm just not convinced by it.

TjL

[simX]

> So your argument of mouse vs keyboard use doesn't even convince ME, an
> avid keyboard user.

I like it how I'm supposed to be the one that's an "uninformed idiot",
except for the fact that I actually use the Twitter website daily, and
I can tell you that simply typing @name is faster than having to click
a reply swoosh, especially since the website's text field is
automatically focused when the page is loaded.

Like I said, I *use* the reply swooshes *myself* because I like to get
the accurate metadata, too! What part of "I understand the benefits,
I just want the benefits of the old way as well" is hard to
understand?

> Instead you just want to add extra unnecessary metadata and then have
> programmers try to guess what the original intention was.

Thanks for completely misunderstanding what I'm trying to point out.
Programmers need not do guesswork at all. Programmers can leave it up
to the user to decide whether a tweet is a genuine reply or not,
because the user is the best-equipped to figure this out. Users can
use whether a reply was specifically linked by the twitterer or if it
was automatically linked by Twitter, and they can use the text of the
linked tweet to figure it out, too.

> And what AI are they going to use to determine whether this extra

> metadata or lack thereof means that this is an actualreply?  They're

> going to go whichever they prefer.

*facepalm* There is no AI involved. The point is to equip the user
with as much information as possible to determine the context of the
tweet. Even approximate context is better than none.

> Meaning that they are going to get a different result for
> 'conversations' depending on whether they use Summize (which is going
> to have to choose one method) or some other client.

Yes, that's right, depending on whether the client or the app in
particular is dependent upon extremely accurate twitter conversation
links (like, for example, conversation-trackers like the now-defunct
Quotably), or if they just want the user to be able to figure out more
information about the topic in question (such as most Twitter
clients).

The only "different result" that will occur is that those who wish to
use the approximate data will have longer conversations that may or
may not be accurate. But they will be a complete superset of the
shorter, exact conversations that use the exact in_reply_to data.
Users can easily figure out when the approximate context is wrong in
the course of scanning such data, far faster than any AI that I'm
supposedly advocating for.

> I'm just not convinced by it.

Please provide a way to easily figure out which tweet this is in
response to, given the new policy of Twitter to not auto-link manual
replies: http://twitter.com/KuraFire/status/1176556069 . Until you
do, I am unconvinced that *you* understand the complete exercise in
*utter* frustration the new feature has caused in trying to follow
some conversations.

[Dossy Shiobara]

It's a lovely flame going on, but hoping to increase the S2N ratio _just
slightly_, I think summarizing what Twitter's behavior _should be_ will
be helpful:

1) If a POSTed update has in_reply_to metadata included, always use that.

2) Else, if the update starts with @name, auto-populate the in_reply_to
metadata with the latest tweet from the named user.

The current Twitter behavior where a tweet starts with "@name" but has
NO in_reply_to metadata is a DEFECT, and I suggest we open an issue in
the issue tracker and all vote it up to make this very clear:

#373: Tweets starting with @name missing in_reply_to metadata
http://code.google.com/p/twitter-api/issues/detail?id=373

The people who needs to understand this bug are the Twitter folks, not
some random person on the mailing list who doesn't understand it and
doesn't seem to want to.

--
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

[tcdent]

I'm adding my opinion to this thread after a little bit of back-and-
forth with @simX and @KuraFire on Twitter the other day. 140
characters is just not enough to convey a complete argument.

This change of functionality has turned a feature that was in a
definite gray area, to black and white. The application is no longer
assuming a user's intentions (possibly incorrectly), but requiring
them to assign the additional data if they wish. Yes, it takes
additional effort to create additional information, but saving and
displaying assumed-to-be-correct information as fact is wrong.

When you create a new message in Apple Mail (or any other mainstream
mail client I'm aware of) it is not automatically marked as a reply to
the last message you received. You have to specify which message you
are replying to, and have the choice to start a new thread by replying
to nothing at all. Your solution does not provide this as an option.
All messages prefixed by a username will be treated like a reply with
no way to opt-out.

Your suggestion to include multiple posts on all an individual status
pages is conventionally incorrect. A direct link should only show one
status: the one you asked for. However, Twitter could take advantage
of the 100% accurate metadata present in the new reply functionality
and create conversation pages showing the thread. This, and any other
application taking advantage of the metadata, would be broken if it
contained the false positives your solution introduces.

Travis Dent
@tcdent