[twitter-dev] Re: in reply to metadata missing for manual replies
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
[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 Wed, Mar 4, 2009 at 4:38 PM, atebits loren.brich...@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
[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
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 On Tue, Mar 3, 2009 at 7:04 PM, simX simsimb...@gmail.com wrote: 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.
[twitter-dev] Re: in reply to metadata missing for manual replies
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 simsimb...@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.
