To the Leapmobile?

Strictly speaking, Leapfrog should be an app, not a web site. There are several reasons:

• Leapfrog collects data speculatively. When you sign in, it gets permission from that service to ask it on your behalf for your new stream data, then does so even when you haven't used Leapfrog in a while. To right-time the aggregation, we'd have to back off when you haven't looked for a while, then look immediately when you sign in after being gone a while.
• Leapfrog collects private data. Because Leapfrog is contacting Twitter or Flickr on your behalf, it can see posts that your contacts have shared with you but not the public internet. It's scary and sketchy whenever a service holds your private data for you, which is why so many don't.
• Leapfrog doesn't add any network value. Leapfrog might make it quicker and easier to read your contact streams, but Leapfrog doesn't get better as more people join. Even the new feedback feature goes directly to the source instead of occurring on Leapfrog: you favorite tweets on Twitter, and there's no such thing as a “Leapfrog favorite,” because why the hell bother when everyone else already has them.

If Leapfrog is expensive to operate centrally and nobody benefits from it, why not make it an app so everyone can just run their own?

Increasingly, being an app means being a mobile app. Leapfrog would work pretty well in this context. The main problem is you'd have to invoke it to have it read your streams, as you do with a mobile Twitter client, since it couldn't do it in the background as it currently does. It could still apply all the content-focusing rules, though that's probably more work on the client than any other simple stream reading apps do (other than Reeder, which seems to do a bunch of steps even if it's just pulling from Google Reader).

In this sense Leapfrog is more like Flipboard than some of the other stream reading services cropping up lately. (Laterstars comes to mind since Matt mentioned it, but it's its own weird stream+Instapaper thing.)

Comments

[Martin Atkins]

The one universal benefit of a webapp still applies: settings and state are not confined to one device. I still want a "last read" marker to remind me what I've seen, but that wouldn't make sense without a central place to store it.

Also, "mobile" is not how you spell iphone. HTH.

[markpasc]

True, you only get one narrow platform when you write an app. Someone else asked in regard to the blog posting idea why not make it an app, and I realized I didn't think about that here either.

You could just pull out last-read state and content transformation into a web service, but at that point why not just do it all as a web app with a machine-readable interface—as you know, since that's what you were planning to do for an Android Leapfrog app already.

[Martin Atkins]

I guess one more reason that applies specifically to leapfrog is that it would ideally be using push notifications rather than polling to get content, and in order to do that you need to have a real, persistent presence on the Internet.

Your post this morning got me thinking again about sending activities as machine-readable email attachments, since there's already infrastructure available from a variety of providers to offload your "inbox" to someone else but be able to sync the content down to your client when possible.