Tags: bookmarklet




Someone at Clearleft asked me a question recently about making bookmarklets. I have a bit of experience in that department. As well as making a bookmarklet for adding links to my own site, there’s the Huffduffer bookmarklet that’s been chugging away since 2008.

I told them that there are basically two approaches:

  1. Have the bookmarklet pop open a new browser window at your service, passing in the URL of the current page. Then do all the heavy lifting on your server.
  2. Have the bookmarklet inject JavaScript to analyse and edit the DOM of the document in the current browser window. All the heavy lifting is done directly in client-side JavaScript.

I favour the first approach. Partly that’s because it makes it easier to update the functionality. As you improve your server-side script, the bookmarklet functionality gets better automatically. But also, if your server-side script doesn’t do its magic, you can always fall back to letting the end user fill in the details.

Here’s an example…

When you click the Huffduffer bookmarklet, it pops open this URL:


…with that page parameter filled in with whatever page you currently have open. Let’s say I’ve got this page currently open in my browser:


If I press the Huffduffer bookmarklet, that will spawn a new window with this URL:


And that’s all it does. Now it’s up to that page on Huffduffer to figure out what to do with the URL it has been given. In this case, it makes a CURL request to figure out what to use as a title, what to use as a description, what audio file to use, etc. If it can’t figure that out, I can always fill in those fields myself by hand.

I could’ve chosen to get at that information by injecting JavaScript directly into the page open in the browser. But that’s somewhat invasive.

Brian Donohue wrote on Ev’s blog a while back about one of the problems with that approach. Sites that—quite correctly—have a strict Content Security Policy will object to having arbitrary JavaScript injected into their documents.

But remember this only applies to some bookmarklets. If a bookmarklet just spawns a new window—like Huffduffer’s—then there’s no problem. That approach to bookmarklets was dismissed with this justification:

The crux of the issue for bookmarklets is that web authors can control the origin of the JavaScript, network calls, and CSS, all of which are necessary for any non-trivial bookmarklet.

Citation needed. I submit that Huffduffer and Instapaper provide very similar services: “listen later” and “read later”. Both use cases could be described as “non-trivial”. But only one of the bookmarklets works on sites with strict CSPs.

Time and time again, I see over-engineered technical solutions that are built with the justification that “this problem is very complex therefore the solution needs to be complex” (yes, I am talking about web thangs that rely on complex JavaScript). In my experience, it’s exactly the opposite way around. The more complex the problem, the more important it is to solve it in the simplest way possible. It’s the only way of making sure the solution is resilient to unexpected scenarios.

The situation with bookmarklets is a perfect example. It’s not just an issue with strict Content Security Policies either. I’ve seen JavaScript-injecting bookmarklets fail because someone has set their browser cookie preferences to only accept cookies from the originating server.

Bookmarklets are not dead. They may, however, be pining for the fjords. Nobody has a figured out a way to get bookmarklets to work on mobile. Now that might well be a death sentence.

Huffduffing video

You know what would be awesome? If you could huffduff the audio from videos on YouTube, Vimeo, and other video hosting sites.

To give you an example, A List Apart recently started running online events and once the events are over, they pop ‘em onto YouTube. Now, I’m not saying I don’t want to look at those lovely faces for an hour, but if truth be told, it’s the audio that I’m really interested in.

In the past, my only recourse would’ve been to pester the good people at A List Apart to export audio as well as video, in much the same way as I’ve pestered conference organisers in the past:

I wish conference organisers would export the audio of any talks that they’re publishing as video. Creating the sound file at that point is a simple one-click step. But once the videos are up online—be it on YouTube or Vimeo—it’s a lot, lot harder to get just the audio.

Not everyone wants to watch video. In fact, I bet there are plenty of people who listen to conference talks by opening the video in a separate tab so they can listen to it while they do something else.

Some people have come up with clever workarounds to get the audio track from videos into Huffduffer but they’re fairly convoluted.

Until now!

The brilliant Ryan Barrett has just launched huffduff-video:

He has created a bookmarklet you can use whenever you’re on a YouTube or Vimeo page that you want to huffduff. It works a treat—I’ve already used to huffduff that A List Apart event and a talk by Matt Jones.

It takes a little while to do the initial conversion but you can just leave the pop-up window open while it works its magic. I’ve incorporated it into the Huffduffer bookmarklet now too. So if you’re on a YouTube or Vimeo page, you can hit the usual bookmarklet and it’ll route you through Ryan’s clever creation.

That’s makes two fantastic pieces of software from Ryan that have improved my online life immeasurably: first Bridgy and now huffduff-video. So nifty!

hCard Wizard

The microformats meetup in San Francisco after An Event Apart had quite a turnout. The gathering was spoiled only by Jenn getting her purse stolen. Two evenings earlier, Noel had been robbed at gunpoint. San Francisco wasn’t exactly showing its best side.

Still, the microformats meetup was a pleasant get-together. Matthew Levine pulled out his laptop and gave me a demo of the Lazy Web in action…

On the first day of An Event Apart, I twittered a reminder that my liveblogging posts were filled with hCards. Christian asked how I added the hCards and I replied that, while I just add them by hand, some kind of “wizard” for adding simple hCards to any textarea would be very welcome.

Less than 48 hours later, Matthew had whipped up exactly what I asked for. It’s a bookmarklet. Drag it to your bookmarks bar and click on it whenever you want to add a simple hCard. It uses JavaScript to create a faux window with a form where you are prompted to enter given name and family name. You can also add a middle name and a URL.

This is just a small subset of all the properties available in hCard so it isn’t suitable for detailed hCards. If you’re creating the markup for a contact page, for example, you’d be better off with the hCard-o-matic. But this little bookmarklet easily hits 80% of the use cases for adding hCards within body text (like in a blog post, for example).

This is a first release and there will inevitably be improvements. The ability to add XFN values would be a real boon. Still… that’s really impressive work for something that was knocked together so quickly.

If you want to use the bookmarklet (regardless of what blogging engine or CMS you use), drag this to your bookmarks bar:

hCard Wizard

Feed reading

There are some great pieces of software out there dedicated to reading RSS, each with their own take on the task. As a Mac user, I’m spoiled for choice with NetNewsWire, NewsFire and Shrook to choose from.

Then there are the myriad online feed readers like Bloglines, Newshutch and Google Reader. They’re all pretty slick as long as you’ve got a relatively well-specced machine with a JavaScript-capable browser.

But I’ve never found an RSS reader that I’ve been completely satisfied with. I find all too often that the experience reminds of using an email client. Reading email can be an enjoyable activity but more often than not, it’s all about getting the unread count in your inbox down to zero, right?

I gave up on feed readers for quite a while and just started reading the few feeds I’ve gathered together at Adactio Elsewhere. But this doesn’t keep track of what I’ve already read.

I quite like the way the “favorites”(sic) feature on Technorati works. Here, the freshness of the post takes precedent over the author. Everyone’s posts are mixed up into one river of news. It feels more like reading through a single blog.

I didn’t think there was any new way to catch up on RSS feeds until James set me straight.

We have weekly Monday morning meetings at Clearleft at which everyone is encouraged to offer up a “lightbulb moment”—an insight or revelation that’s useful or just cool. This week’s meeting didn’t happen until Wednesday (we’re not the best clockwatchers). For his lightbulb moment, James pointed out a nice little feature now offered by Google Reader.

If you go to Settings and then look under the Goodies tab, you’ll see a bookmarklet marked “Next” that you can drag to your bookmarks bar. Clicking on this bookmarklet (or favelet, if you will) takes you to the next unread post in your river of news.

I really like this way of reading. Like the Technorati solution, the order is determined by date rather than author. But the authorship is very relevant in that you view the entry in its original context; on that person’s website rather than in a feed reader (something that I know a lot of my designer friends have strong feelings about).

This little bookmarklet manages to bring RSS reading back into the browser in a completely different way than simply emulating a desktop feed reader. Whenever I want to read something new, I click the “Next” link in my bookmarks bar. I don’t know exactly what I’m going to get but I know that it will something that I haven’t read before, it will be written by someone I enjoy reading and it will be fresh.

This solution manages to straddle the fine line between the convenience of RSS (pull rather than push notification) with the tyranny of RSS (a daunting list of feeds to read through). And I don’t need to keep opening new tabs or windows—something that’s hard to avoid with regular feed readers be they on the desktop or in the browser.

I’m thinking of creating an OPML file that consists of nothing but del.icio.us links (or quicklinks or blogmarks or whatever) from people whose taste I trust. Then clicking on that “Next” button would have a lovely touch of serendipity, constantly finding something new and fresh, landing me on a web page for no other reason than someone I know thought it was worth bookmarking.

It kind of reminds me of what it was like to surf the Web back in the old pre-RSS days before information overload overwhelmed us all. If you’ve got a Google Reader account, give the bookmarklet a whirl and see what you think. It might change the way you think about reading RSS.