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.
+
I use http://quixapp.com/ to do something similar to this. Hit the quix bookmarklet, hit i and it is sent to instapaper. db for delicious, etc.
I agree with the problem, but I have another idea for a solution: what if there were a standard API for this? What if any service that saved a URL based on input from a user did it the same way? For example:
http:///accept_url?url=
Or whatever. Then, all an app developer like Reeder has to do is give you a place where you can enter the domain names of the services you use.
I’m over-simplifying it, too (there would have to be authentication, and such), but I like the idea of it being nice and RESTful like this.
Jeff: That’s an interesting approach. But then wouldn’t I need to enter all the services I like to use for each app? If I have say five services — Instapaper, Delicious, Posterous, Pinterest, Mlkshk — that could get tedious if I want to have them available from say five apps.
Nitpick: Instapaper does have an email service. Poke around on the website and you’ll find a private email address that will add anything sent to it to your Instapaper queue.
Otherwise, I agree with Jeff. The sensible way to do this is to have a spot for “put in the URL of your service (ex. instapaper.com), your username, and password (if any)” and then the app constructs a virtual bookmarklet based on that info.
Fair point, Khoi.
I think the biggest issues with your suggestion that there be one gateway service are:
1. It’s centralized. There’s a single point of failure, and puts a lot of power in the hands of one company/service. That scares a lot of people.
2. It would be a ton of work. It sounds simple on the surface, but to do it right (i.e. without storing user’s Instapaper, Tumblr, etc. passwords), you’re going to need those third-party services to support OAuth or other token-based authentication, and most of them don’t. If you have to give your Instapaper, Tumblr, etc. passwords to the gateway service, issue number one is compounded a great deal.
As always, there are tradeoffs between security and convenience. Not really sure what the best solution is, here, but I definitely agree that there’s a problem. 🙂
Couldn’t both exist? A standard – “canonized” – list, and then a place where you could enter in the services you wanted to expand upon what the app offers. In fact, doesn’t Twitter for the iphone do this with the “custom endpoints” functionality for image services, url shortening, etc.?
I like what Jeff suggests, and agree that it would be a TON of work, but I think there is a middle ground that could be sought before having to go that far.
I agree – I have pondered this, mainly on trying to abide by the “chrome” philisophy where the browser is nothing more then a window to your cloud.. now my bar is jampacked with bookmarklets i have a backup issue to take care of and i can only use mysetup from my browser, i would like to have this across all devices.. which requires this level of abstraction.. good idea.
I support.
I like Khoi’s idea of a single service. Federation and or proper scaling could handle single point of failure issues. For example, a service/solution I could run on my own server, but could always use a commercial version as a backup.
Many services are already using OAuth, Twitter, Facebook, or Google to authenticate you anyway. I think where this would really be great is in the mobile space. I know currently, I either send to email or send to Instapaper; then I have to reprocess things once I get to a laptop. Post that to Facebook, post this to Twitter, send this to Posterous, etc.
It is centralized, but I think that AddThis does pretty much what you want. You’ve probably see their widgets all over the web, but they also have bookmarklets, toolbars, and stuff to integrate into your apps. If you use an account with them, (and maybe even without, on some platforms), they remember which services you use the most and those are the ones that appear first for you in the widgets, bookmarks, and so on.
People who create services can submit their service to AddThis, and assuming it meets the technical requirements, (follows a specific querystring format for adding a URL), it gets added fairly quickly.
They have an API so developers can take advantage of their library of sharing apps, so, for example, Reeder could rely on AddThis for their sharing/bookmarking bookmarket.
There are a few problems. AddThis *is* a centralized service, so if they go down then anyone relying on them loses their sharing ability. Also, I believe, (but I’m not sure), that in order to track your data and always show you the sharing apps that you’re most interested in across devices that you would need to authorize each device/bookmarklet/iOS App to access your AddThis account, which would be a hurdle, (and for some people the tracking itself could be an issue). However, it is quite close to what I think Khoi is asking for: 1 bookmarklet, cross-platform, to rule them all, that always has the latest apps already in it.
Some bookmarklets do more than send and Instapaper is one example. In an interview with Rands, Marco Arment described the hoops his Instapaper bookmarklet jumps through to ensure that if you “can see the page in your browser, you can save it to Instapaper.”
http://www.randsinrepose.com/archives/2011/01/25/interview_marco_arment.html
Many bookmarklets do little more than load in external JavaScript, to prevent users from having to update their bookmarklet with each change and to avoid any browser-based limitation on bookmark length. What if instead of pushing URL’s to a site/service, the sites/services agree to a standard filename and location of a bookmarklet script to be pulled? This would be similar to the industry standard practice of resources such as “favicon.ico” and “robots.txt.”
This would make it easy for sites to add support for new services – either through a gateway or manually – and allow the services to add new features to their scripts.
Jeff’s call for a standardized API (or David’s, which is a good extension) seems like a no-brainer, regardless of whether another company takes things further and creates a centralized repository. Apps could offer a a list of popular sharing options (which would save a lot of data entry), and then give users the option to customize the list by entering the domain names of their favorite services.
Re the centralized service: Google seems like a potential candidate to do it. They have a huge number of existing accounts, their products rarely go offline, users think of them as an information company, and I’m sure they’d love to have the data. People are beginning to get a bit more suspicious of them, but I think their reputation is still very good overall—certainly better than that of Facebook, or most other existing companies that could pull this off.
blog Release Candidate One did a post very similar to this, but from an OS perspective. worth a read.
I’ve found Shareaholic absolutely indispensable as a bookmarklet aggregator. First and foremost, it provides an ever expanding directory of integrated services. In addition, Shareaholic has a couple nice little usability features built in– drag/drop to set the menu order of your services, and create keyboard shortcuts for them.
AddToAny did this in 2006. Yes it’s a single point of failure but it works great. You should see “o-exchange” too.
Completely agree with Reeder do an amazing job at providing users with multiple places to “share” to. I think the best solution would be a slightly different one to yours and probably easier to implement for the developers: give users an easy way to add a bookmarklet to the app themselves.
On a side note, you should try sending a tweet to the Reeder developers, I sent them a tweet and an email a while ago with a request for ZooTool to be added to the app —аit appeared not long after.