[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
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)
[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
On Wed, Mar 4, 2009 at 9:51 PM, simX 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
[twitter-dev] Re: "in reply to" metadata missing for manual replies
On 4 Mar, 14:25, TjL 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
On Wed, Mar 4, 2009 at 4:38 PM, atebits 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
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
[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
> 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 * ckai...@floodgap.com -- It's tradition, that makes it okay. -- Weird Al, "Weasel Stomping Day" -
[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 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 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.
[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 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
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 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
> 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
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 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
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?
