[twitter-dev] Re: in reply to metadata missing for manual replies
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.
[twitter-dev] Re: in reply to metadata missing for manual replies
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
[twitter-dev] Re: in reply to metadata missing for manual replies
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
[twitter-dev] Re: in reply to metadata missing for manual replies
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?
[twitter-dev] Re: in reply to metadata missing for manual replies
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 On 3 Mar, 16:07, Chad Etzel jazzyc...@gmail.com wrote: 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
[twitter-dev] Re: in reply to metadata missing for manual replies
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 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.
Re: in reply to metadata missing for manual replies
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.
Re: in reply to metadata missing for manual replies
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.
in reply to metadata missing for manual replies
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.
