Thank goodness for bookmarklets. I have at least a dozen that I use regularly; one that lets me perform a Google search for text within the site I’m currently visiting, another to submit a publish action within a web app I use (whose own publish button is inconveniently placed), another to generate a Bit.ly link from the current URL, and so on. They’re clever, simple add-ons that are usually too niche-oriented to become a standard part of any Web browser, so for me at least they’re an indispensable complement to the browsing experience.
In the past few years I’ve found myself acquiring bookmarklets whose principal purpose is to send a piece of content to another service. This is the way Instapaper works, of course; if I want to read the contents of a Web page later, I just invoke my Instapaper bookmarklet, which then stores that page on the server for me to pick up from a different device, at a more convenient time. This is also basically the way my bookmarklets work for Posterous, Pinterest, Tumblr, Delicious and so many others — the user invokes the bookmarklet, specifies the content to be transmitted, and it’s sent to the service.
Thinking Outside the Browser
These bookmarklets all work great, but one increasing problem I find is that they really only work from within my browser. I can’t send an article to Instapaper from my email client, for example, and the problem is worse in the world of iOS apps, where browsing happens from within many more places than just Mobile Safari. If I want to send an item to Svpply from an app like Flipboard, I’m out of luck. And you can forget any of those ill-advised iPad magazine apps, too.
On the other hand, some apps do go to great lengths to essentially replicate the bookmarklets its users are most likely to employ. The superb Google Reader client Reeder does probably the best job of this, offering a menu of about a dozen services.
This is laudable but it’s not a perfect solution. Newer services are unlikely to be added to a menu like this in a very quick time frame; I’ve recently become a fan of Pinterest and Mlkshk, for instance, and it would shock me if even the next release of Reeder incorporates either of those services. Given the pace of new sites and services debuting in the marketplace, it’s probably unrealistic to expect a developer to continually update a menu like Reeder’s, and why should they have to?
For that matter, why does every service need to generate its own bookmarklet? It’s not that bookmarklets are difficult to develop, but the development is only half the battle; the hard part is getting users to save the bookmarklet within their browser — and across all their browsers at the office, on their home computers, within their mobile phones etc. — and then to hope that the bookmarklets will get used.
One Service Gets You All Services
All we need, really, is one service that can serve as a gateway to any and all of these other services. It could be open and free to any new service that comes along — tomorrow’s Intsapapers and Tumblrs could add themselves to the gateway as soon as they launch. Users could then opt into them at will, so all of their favorites would be available to them in much shorter order, and they can prune the ones that they no longer use.
Of course, in browsers, this gateway could work as a bookmarklet, but it doesn’t need to be restricted to that form. An app like Reeder would only need to integrate with the gateway, and all of the other services would come for ‘free,’ with no additional development necessary. The developer is relieved of the tedium of doing work that’s essentially duplicative, while the user benefits from much timelier availability of new services.
There are lots of details that I’m glossing over here, of course, but none that are insurmountable, from what I can tell, so long as someone industrious undertakes the challenge. What’s probably not workable, though, is the continued proliferation of services that rely on users to manually adopt their bookmarklets and for other developers to manually add them to their apps.
+