2010-02-01
Rich Feeds for Tumblr Blogs
benw:
the RSS output from Tumblr stinks. I assume it’s an evil incentive to use the Dashboard.
So, I’ve written a feed script. It’s called Tumblfeed, which sounds like tumbleweed… which I suppose is a metaphor for the semantic desolation of the Tumblr RSS feeds… or something. It was an accidental rhyme.
This looks good. I may even start offering feeds of my stuff through it.
2009-12-01
post/265305205
Give Retweets a Chance at the Tweetie support site.
This post succinctly sums up the advantages to “proper” (as opposed to “folk”) “retweets”, and they rest on one thing: metadata. As with replies, doing so using Twitter’s API methods gives users the metadata they need to do useful things: in the case of retweets, collapse repeats, and hide or ignore retweets. Not doing so deprives them of it, forcing them to scrape for data (or just put up with things). Don’t do that.
2009-08-05
post/156424512
I’ve probably left it so late that nobody cares, but here’s my tuppence on the front page redesign.
Firstly, I hate that the sign in form is now hidden by default; it stops Keychain filling in the password. The old login page is still available and works, but for how long?
Secondly, obviously in pulling search to the forefront Twitter are continuing to build on the Summize acquisition and the value they (and others) see in trends.
Thirdly, it looks like trending topics now get a description written. It’s fairly obvious this is being done manually. For one thing, they take a while to show up. For another, topics that are evidently referring to the same thing can have somewhat different descriptions.
Fourthly, it’s annoying that logged-in users have no way to access the historic trending topics or the descriptions of them. The former is a bit tricky to fix, but a title attribute on the links in the trending topics sidebar would be nice. (The descriptions would also be useful via the API.)
Generally, for all I share the suspicion that trending topics aren’t particularly insightful, they probably do work as a hook into the service.
2009-07-21
Twitter, @replies and in_reply_to
benw:
Existing conversation trackers don’t work with this. The
@@replies get left out of threading tools. That’s a shame, but that’s the reality of new behaviour. It takes time to be recognised and supported. That as much as anything is why I’ve documented@@here, as a reference and explanation for you to use as you advocate the practice, and to encourage everyone to settle on the@@syntax in preference to the many that currently circulate.
There’s a reason that conversation trackers don’t get @@replies, but it’s quite longwinded to explain. However, since Ben has a fairly longwinded explanatory section to his post, and because I’ve wanted to get this down anyway, what the hell; let’s go with it.
Once upon a time Ev invented Twitter. And people saw it was good, and started using it, and as Ben says, came up with what became formalised as a way of replying to a named user: @replies. (I’d love to know where that convention started, by the way. Presumably some web forums, but which, and when? Not that anyone is likely to care enough to dig through terabytes of text to establish it. Anyway.)
And Twitter saw that their users were doing this, and that it might be useful to make it clever, so they started marking up @user with links to twitter.com/user. Furthermore, they came up with a heuristic: if a post started @user (or, in Perlish,
if $post =~ m/^\@user/
except Twitter’s front end is in Ruby, but it’d be similar) then you’d assume that the person was replying to user’s latest post.
All well and good, except… when it wasn’t true. So, some time last year (again, I don’t care to trawl; someone else might) Twitter added the “swoosh” link to the web interface. Clicking this didn’t just populate the post field with @user at the front: it set a bit of metadata saying “this post I want to create is an reply to this exact post ID here”. Technically, and unsurprisingly, this is the in_reply_to field.
There’s rules attached to this, both from the front end and from third-party clients via the API, though. For the in_reply_to argument to be honoured, the post must start with the @user the in_reply_to post is by. In fact, it has to match the regular expression above. Add a space? Add the letters “RT” or the recycle symbol? No in_reply_to metadata for you, buddy.
It also means that if you come to see a post that you want to reply to and just put @user without using the swoosh, or your client has a brainfart and drops the in_reply_to argument, your post also lacks the in_reply_to metadata. The upshot? Anyone coming along more than, say, a day later to your post has no idea which of @user’s posts you’re actually responding to. If you’re lucky it’ll be clear. If not, well, tough. “This was the previous behavior and was changed because of user complaints over false positives.” WONTFIX.
So, what have we learnt?
- in_reply_to is a relatively late change to Twitter
- in_reply_to is only available if you start your post @user
- in_reply_to is reliant on the user and client explicitly responding to a post
- in_reply_to is absent for retweets, @@replies, and the like
- in_reply_to is implemented as is because Twitter believe false negatives are better than false positives
2009-07-10
post/138976951
(via atsween)
Dean Allen seems upset. Unfortunately, I find favrd is as shitty as the newcomers tweetorites and favstar.fm, because my stream is private, so none of them can be persuaded I exist. At least the otherwise appalingly garish favstar tells me why I am apparently so unpopular.
Now, I’ll admit that, as with Microplaza, supporting private users is tricky, but it’s possible - set up an account associated with the site and follow private users so you can see what’s going on.
Fundamentally, though, the whole model that all these sites work on is a monstrous hack. Unlike Flickr¹, Twitter has no public mechanism to find out which of your posts have been marked as a favourite, so all these services pull down RSS for many users, looking to see which status updates get marked. Naturally, this isn’t exhaustive; if someone they’re not tracking (like a private user, sigh, or someone new) adds something, it’s ignored. Of course it’s also horrifically inefficient.
It’s even more annoying to find that a few select users do actually have this feature within Twitter itself, but it’s not exposed. Here’s an example.
Hopefully one day Twitter will stop growing stupidly fast and their engineers can spend some time, you know, adding features. Features like exposing favourites (which might even help eliminate the scourges of “retweeting” and trending topics). I’m not holding my breath, though. In the meantime, it’s tempting to take my account public just so I can use all the third-party apps that don’t cater for private users.
¹ Flickr’s Recent Activity shows you favourites. It doesn’t have an API method, but I can live with that when the site shows it.
2009-06-16
post/124785177
Jonathan Zittrain: Could Iran Shut Down Twitter?
This reminds me of something tangential I’ve been meaning to say for a while. I’ve more experience writing apps that work with Flickr, and while I’ve had some people using apps that are hosted on external sites, I always had the impression that fidding around within the site using Greasemonkey scripts was a far more common approach for adding functionality.
By contrast, Twitter has a huge ecosystem not just of client applications, from the basic to the complex, but also a range of websites. Because the core website is so minimal, users almost expect to have to look elsewhere for functionality that any other service would have built in (link expansion, archives, tracking favourites; heck, even search was originally a third party, and it still (sort of) lives on another domain).
In a way, this is annoying, because Flickr users are so hard to get off the site. On the other hand, I think I’d rather use a service that bothered to build things itself.
2009-05-17
Twitter, Flickr, APIs and Permissions
benw:
From working on Fire Eagle, I’m an advocate for granular control. Pick sensible defaults, and allow users disable optional parts if they desire. It seems even more important in the case of Twitter, where the impact of abuse is higher.
Take Flickr: If an application asks for read/write access to my photos, that includes private photos and deletion rights. I can’t disable that. I can’t just say ‘this app only accesses public content’.
That’s because Flickr’s API allows access to any public photo without authentication, so that level is implicit in posting your photos. To me, this makes sense: it’s on the web anyway, so if you didn’t allow API access, one could just scrape the data. (It is possible to opt out of API searches, but if I know your photo ID or user ID I can still use API calls.)
From what I understand of Twitter’s API, it’s actually similar: you can fetch any public user’s updates (or the bio of any user) without authentication. It’s only updating, and reading the updates of a private user, that require authentication.
It’s probably a fair point to suggest that Twitter should split these, though. Perhaps Flickr and Twitter should also both offer full-blown API optouts (for as much as it pains me as a developer, it’s probably right ethically.)
2008-12-04
Tumblr API updated
[this is good] - although it might be nice for third-party apps to have an OAuth rather than username/password method for logging in. Ah well, maybe next time?
We’ve added some new features to the Tumblr API:
- Edit and delete posts
- Authenticated reading to include private posts
- Convenient login behavior for embedded Dashboard browsers
- AIFF audio format support
- The optional
filterparameter to/api/read- A new
/api/authenticateaction with expanded informationCheck the documentation for details.
2008-10-17
Red Sweater Blog | I'd Tumbl For You
Daniel Jalkut lets MarsEdit users know that Tumblr’s API isn’t up to snuff for him to use it. I comment with a couple of Get Satisfaction tickets, but in the meantime someone from Tumblr shows up to promise an expanded API. Here’s hoping.
2008-09-18
Vocal Grumblr
Tumblr has a nice API (for reading anyway) that lets you get posts as JSON. Unfortunately, you can’t filter by tag, and per-tag pages don’t have RSS or Atom feeds of their own.
Vox has a nasty heavy Atom API for reading which doesn’t seem to do JSON, but it does filter by tag, and per-tag pages have feeds of their own.
Sigh.
