Lex Friedman blogs here.

Lex is the EVP of Sales and Development for Midroll, the world's best podcast advertising network.

He was previously Macworld's senior writer, and continues to contribute to the publication. He is the cohost of the Not Playing podcast, a cohost of the Turning This Car Around podcast, a cohost of the The Rebound podcast, and the sole host of the Your Daily Lex podcast.

Lex's first book, The Snuggie Sutra, is exactly what it sounds like. His most recent book is a Dr. Seuss parody for adults; it's called The Kid in the Crib.

You should follow him on both Twitter and App.net.

Lex would be delighted to speak at your awesome event.

How to improve the Twitter experience in almost zero steps

You love Twitter, right? You read tweets, you write tweets — you’re a tweeting fool. But you’re not always in one place, so sometimes you manage Twitter from your iPhone, and other times you Twitter from your iPad, and still other times you Twitter from your Mac.

I use Hibari on my desktop, Twitter on my iPhone, and rotate between Twitter and Twitterrific on my iPad. And the experience of Twitter client hopping sucks. That’s because when I switch from one to the other, no client has any idea where I left off in the other. I either skip chunks of tweets against my will, or need to scroll through oodles of tweets I’ve already read.

There’s a better way. And it shouldn’t be on the customer’s side to deal with. This is a problem Twitter developers can and should solve.

I’m proposing — and hosting — an API through which different Twitter clients could painlessly keep track of where users are in their timelines.

I envision a painless API with two methods — get and put — where any client could either ask “What’s the last tweet ID seen by this user?” or declare “Here’s the last tweet ID seen by this user.” That would solve the bulk of this Twitter client-switching problem.

There are weaknesses, of course. “Last seen” could be defined uniquely by different clients. To me, the most recent visible tweet in the timeline counts. But the nice thing is, there’s no risk that I can see here: A client can position you in the timeline at what it thinks is the “right” place, but you can of course still scroll to wherever you need if it’s wrong. When it works, it makes your tweet-reading experience better, and when it doesn’t, it’s the same as it’s always been.

Here’s a quick implementation I put together:

http://lexfriedman.com/lastseen/get
http://lexfriedman.com/lastseen/put

Both “get” and “put” take:

c: string, client name. In this case, TestClient.
u: user_id for the Twitterer
k: a unique secret key based on the client. For TestClient, it’s: f3254c1b6f9efc99eb52f5cb97a45890

On “put,” you add one final parameter: The ID of the last-seen tweet.

So, when I record your last-seen tweet, it’s:
http://lexfriedman.com/lastseen/put?c=TestClient&u=785133&l=25680758613&k=f3254c1b6f9efc99eb52f5cb97a45890

When I want to fetch the last-seen tweet for the user (on app startup), it’s:
http://lexfriedman.com/lastseen/get?c=TestClient&u=785133&k=f3254c1b6f9efc99eb52f5cb97a45890

For both calls, the API returns the numeric value of the last-seen tweet ID on success, and a text error on failure.

Obviously, this kind of approach would only work if numerous Twitter clients on multiple platforms all were interested in supporting it. My challenge, of course, is that I don’t know many Twitter developers personally.

But perhaps you do! I’ll gladly establish a secret key for any Twitter client that wants to support this. Tell your favorite Twitter developer to email me at my first initial (“L”) at lexfriedman.com.

Let’s make Twitter awesomer together!

Posted on September 29th, 2010