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. Th
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 i
> 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 havin
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 conclu
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
>
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
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
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 impo
> 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).
--
--
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.googl
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 *ar
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
> 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.
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 st
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
On 27 Gen, 00:08, Damon C 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, i
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
lacke
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' beh
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.
On 24 Gen, 08:01, Steve Brunton 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 @
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 a
On Sat, Jan 24, 2009 at 12:27 AM, Aditya 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
${
> > 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 co
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
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 us
2009/1/24 simX :
> 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 t
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
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 @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
29 matches
Mail list logo
