Simon de la Rouviere

Twitter’s Archive and (my) TwimeMachine.

I started TwimeMachine back in late 2009, because it was a horrible user experience to find and read your old tweets (hint: click next, click next, click next).

Over the years it’s evolved, getting help from people like Misha Kvakin (TwimeMachine’s design for a long time), changing codebases (PHP to Django) and finally having to work around Twitter’s recent deprecation of some timeline features.

Even before Twitter’s recent ‘pivot’ away from its API ecosystem, I knew it was something that Twitter eventually just had to implement. It was a nice, fun side project. I could get what I want, other people could use it, and I can learn new skills (Heroku, Django, better javascript, etc). I never banked or spent too much time on it for this reason. I’m okay with that. I think it would be naive to expect something if you fill a gap in a third-party way. Even if the company has a history of buying up great third-party apps (which Twitter of course doesn’t have), it would still be naive to expect anything.

As you may know, Twitter announced the ability to download and view all your old tweets. I haven’t been able to test it as it hasn’t rolled out to me yet. By the looks of it, you request your archive, it mails it to you, and then through a separate HTML file you can read and search your old tweets. It’s got an interesting interface. By downloading the tweets beforehand, you can quickly navigate through the months on the right. This is similar to how TwimeMachine initially functioned before they changed how the timeline API works. You could quickly skip to parts.

So I guess it comes now to an important question: Do I think it will kill TwimeMachine?

No. The user experience is a bit different. I think TwimeMachine would still be better in some use cases. Firstly, requesting your archive and waiting each time for an e-mail, then opening that HTML file is more effort than simply logging in and waiting a few seconds for 3200 tweets to load.

Secondly, the inline interface is (debatably) better for quickly scanning and browsing your past tweets.

Thirdly, and probably the biggest difference: You can read other people’s old tweets.

—-

So does the fact that Twitter have all your tweets outweigh the other benefits? Not entirely, I’d say, but I do think I’ll lose some traffic over it. Initially I suspect traffic might increase due to chatter, but long-term, the people that use it to read their whole archive (or first tweet) will go the Twitter route. Another factor that is detrimental is that more and more people are tweeting, cruising past 3200 tweets.

It will be interesting to see what happens. I’m proud so far that this little side-project has already been used by about 250 000 Twitter users including Paulo Coelho, Cesc Fabregas, Adidas, CNBC, Sega and ESPN amongst others. I have gotten way more out of it than I could’ve dreamed of.

The ad revenue is after all sponsoring my dev account over at app.net. ;)

Thoughts on app.net

I’ve been watching app.net for a while since Dalton’s ‘audacious’ post about. I really liked what he proposed. I was one of the early adopters of Twitter’s API. I started Tweekly.fm in early 2009, being under the first 500 apps. Now there are more than 3 million registered apps.

I loved working with it, and like most other developers were really excited about what it could become. When Twitter announced annotations, I was really excited. This meant anyone could embed any metadata into posts! An example of something I thought I could easily do on top of Twitter’s API was related to Tweekly.fm. I could embed music information into the posts. Anyone could then mine it for their use, contributing back to an ecosystem.

Alas, that never came to fruition. 2010 was the first and last time Twitter held a developer’s conference. I understand their choice, but I don’t like it. Nothing against them. I still use Twitter daily and probably will for quite a while still.

Now that app.net came along and promised what I wanted, I witheld at first, checking it out. I even started contributing to the API spec before I backed. My biggest worry was kickstarting the network effect. I’m not paying for an awesome API if no one is going to use what I build. Dalton and co pulled out the stops and even provided an alpha version on top of the API. Respect. To give them the benefit of the doubt and really wanting something like this, I decided to back. Even if a small community of tech (hipsters) use the API, it is still the worth a year’s tier.

—-

Now that it got funded, I’m really looking forward to the following. I don’t think people realise what amazing things can be built on it, and what is to be expected of it. My favourite API features: Annotations and Filters.

As mentioned previously, annotations allow any post to be embedded with meta information. Now: Filters allow any stream to filtered based on a lot of criteria. Filters are unique to a user and can be taken with them to any app.net app.

So, let me give you a few example of the power of this:

1) Don’t like it when people cross-post to app.net from Twitter or Facebook? Create a filter that discards all tweets with sources from other social networks. Now you have a pure experience.

Orian Marx describes the power of app.net eloquently (via gigaom):

“App.net will combine the simplicity of cloud infrastructure with the power of web frameworks to deliver the best platform for developing social web applications.”

Now take that idea to something as follows:

2) Let’s start a photo sharing app. Instead of having to build my own social infrastructure, I tack onto app.net. When posting photos, I embed captions, urls, etc. Now in the app itself, doesn’t matter who you follow, I can add a filter to ONLY retrieve this apps photos from your existing app.net graph.

Now, going even further, I can add more filters to that stream as well, only retrieving users you actually chose to ‘follow’ on this service if you don’t want to follow your existing app.net graph.

The potentials are endless. Currently developers are only building the normal suite of apps: ios, desktop, etc. Once the API comes out of alpha, we’ll start seeing the so called ‘killer’ apps that use these new API features.

—-

On the other side. I’m not naive to disregard that app.net might still fail. Inside, its an echo chamber: an early adopter community of great people. Convincing people to join this network for $50 a year (if it stays this) is going to be app.net’s biggest problem. I suspect if a killer app comes along, users will pay. However from a UX perspective it might be a bit jarring, wanting to sign up for a service, but then having to resort to paying for ANOTHER service they know nothing about. Perhaps, developers can handle the payments on behalf of app.net for continuity’s sake.

Either way. I am excited about it. I want it to succeed.

I have a Python API wrapper for it out on github that uses the current available alpha API endpoints.