Journal tags: instapaper

3

Bookmarklets

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:

https://huffduffer.com/add?page=…

…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:

https://adactio.com/journal/6786

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

https://huffduffer.com/add?page=https://adactio.com/journal/6786

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.

Returning control

In his tap essay Fish, Robin sloan said:

On the internet today, reading something twice is an act of love.

I’ve found a few services recently that encourage me to return to things I’ve already read.

Findings is looking quite lovely since its recent redesign. They may have screwed up with their email notification anti-pattern but they were quick to own up to the problem. I’ve been taking the time to read back through quotations I’ve posted, which in turn leads me to revisit the original pieces that the quotations were taken from.

Take, for example, this quote from Dave Winer:

We need to break out of the model where all these systems are monolithic and standalone. There’s art in each individual system, but there’s a much greater art in the union of all the systems we create.

…which leads me back to the beautifully-worded piece he wrote on Medium.

At the other end of the scale, reading this quote led me to revisit Rob’s review of Not Of This Earth on NotComing.com:

Not of This Earth is an early example of a premise conceivably determined by the proverbial writer’s room dartboard. In this case, the first two darts landed on “space” and “vampire.” There was no need to throw a third.

Although I think perhaps my favourite movie-related quotation comes from Gavin Rothery’s review of Saturn 3:

You could look at this film superficially and see it as a robot gone mental chasing Farrah Fawcett around a moonbase trying to get it on with her and killing everybody that gets in its way. Or, you could see through that into brilliance of this film and see that is in fact a story about a robot gone mental chasing Farrah Fawcett around a moonbase trying to get it on with her and killing everybody that gets in its way.

The other service that is encouraging me to revisit articles that I’ve previously read is Readlists. I’ve been using it to gather together pieces of writing that I’ve previously linked to about the Internet of Things, the infrastructure of the internet, digital preservation, or simply sci-fi short stories.

Frank mentioned Readlists when he wrote about The Anthologists:

Anthologies have the potential to finally make good on the purpose of all our automated archiving and collecting: that we would actually go back to the library, look at the stuff again, and, holy moses, do something with it. A collection that isn’t revisited might as well be a garbage heap.

I really like the fact that while Readlists is very much a tool that relies on the network, the collected content no longer requires a network connection: you can send a group of articles to your Kindle, or download them as one epub file.

I love tools like this—user style sheets, greasemonkey scripts, Readability, Instapaper, bookmarklets of all kinds—that allow the end user to exercise control over the content they want to revisit. Or, as Frank puts it:

…users gain new ways to select, sequence, recontextualize, and publish the content they consume.

I think the first technology that really brought this notion to the fore was RSS. The idea that the reader could choose not only to read your content at a later time, but also to read it in a different place—their RSS reader rather than your website—seemed quite radical. It was a bitter pill for the old guard to swallow, but once publishing RSS feeds became the norm, even the stodgiest of old media producers learned to let go of the illusion of control.

That’s why I was very surprised when Aral pushed back against RSS. I understand his reasoning for not providing a full RSS feed:

every RSS reader I tested it in displayed the articles differently — completely destroying my line widths, pull quotes, image captions, footers, and the layout of the high‐DPI images I was using.

…but that kind of illusory control just seems antithetical to the way the web works.

The heart of the issue, I think, is when Aral talks about:

the author’s moral rights over the form and presentation of their work.

I understand his point, but I also value the reader’s ideas about the form and presentation of the work they are going to be reading. The attempt to constrain and restrict the reader’s recontextualising reminds me of emails I used to read on Steve Champeon’s Webdesign-L mailing list back in the 90s that would begin:

How can I force the user to …?

or

How do I stop the user from …?

The questions usually involved attempts to stop users “getting at” images or viewing the markup source. Again, I understand where those views come from, but they just don’t fit comfortably with the sprit of the web.

And, of course, the truth was always that once something was out there on the web, users could always find a way to read it, alter it, store it, or revisit it. For Aral’s site, for example, although he refuses to provide a full RSS feed, all I have to is use Reeder with its built-in Readability functionality to get the full content.

Breaking Things

This is an important point: attempting to exert too much control will be interpreted as damage and routed around. That’s exactly why RSS exists. That’s why Readability and Instapaper exist. That’s why Findings and Readlists exist. Heck, it’s why Huffduffer exists.

To paraphrase Princess Leia, the more you tighten your grip, the more content will slip through your fingers. Rather than trying to battle against the tide, go with the flow and embrace the reality of what Cameron Koczon calls Orbital Content and what Sara Wachter-Boettcher calls Future-Ready Content.

Both of those articles were published on A List Apart. But feel free to put them into a Readlist, or quote your favourite bits on Findings. And then, later, maybe you’ll return to them. Maybe you’ll read them twice. Maybe you’ll love them.

Rebooting

I’m off to Copenhagen for Reboot 10. Reboot is always a fun gathering. It might not be the most useful event but as part of a balanced conference diet, it’s got a unique European flavour.

As usual, I’m going to use the opportunity to talk about something a bit different to my usual web development spiels. This time I’ll be talking about The Transmission of Tradition, a subject I’ve already road-tested at BarCamp London 3:

This talk will look at the past, present and future of transmitting traditional Irish music from the dance to the digital, punctuated with some examples of the tunes. This will serve as a starting point for a discussion of ideas such as the public domain, copyright and the emergence of a reputation economy on the Web.

At the very least, it will give me a chance to debut that mandolin I picked up in Nashville.

This will be my third Reboot. My previous talks were:

I recently discovered the video of that last presentation. Jessica was kind enough to transcribe the whole thing. She also transcribed my talk from this year’s XTech. Go ahead and read through them if you have the time.

If you don’t have the time, you can always mark them for later reading using Instapaper. I love that app. It does one simple little thing but does it really well. Hit a bookmarklet labelled “read later” and you’re done.

Here’s a little sampling of documents I’ve marked for later reading:

Maybe I should fire them up in multiple tabs and read them on the flight to Denmark. Or I could spend the time brushing up on my Danish.

If you’re headed to Reboot, I’ll see you there. Otherwise …Farvel!