Journal tags: bookmarklet

I’m at day two of Indie Web Camp Brighton.

Day one was excellent. It was really hard to choose which sessions to go to because they all sounded interesting. That’s a good problem to have.

I ended up participating in:

• a session on POSSE,
• a session on NFC tags,
• a session on writing, and
• a session on testing your website that was hosted by Ros

In that testing session I shared some of the bookmarklets I use regularly.

Bookmarklets? They’re bookmarks that sit in the toolbar of your desktop browser. Just like any other bookmark, they’re links. The difference is that these links begin with javascript: rather than http. That means you can put programmatic instructions inside the link. Click the bookmark and the JavaScript gets executed.

In my mind, there are two different approaches to making a bookmarklet. One kind of bookmarklet contains lots of clever JavaScript—that’s where the smart stuff happens. The other kind of bookmarklet is deliberately dumb. All they do is take the URL of the current page and pass it to another service—that’s where the smart stuff happens.

I like that second kind of bookmarklet.

Here are some bookmarklets I’ve made. You can drag any of them up to the toolbar of your browser. Or you could create a folder called, say, “bookmarklets”, and drag these links up there.

Validation: This bookmarklet will validate the HTML of whatever page you’re on.

Validate HTML

Carbon: This bookmarklet will run the domain through the website carbon calculator.

Calculate carbon

Accessibility: This bookmarklet will run the current page through the Website Accessibility Evaluation Tools.

WAVE

Performance: This bookmarklet will take the current page and it run it through PageSpeed Insights, which includes a Lighthouse test.

PageSpeed

HTTPS: This bookmarklet will run your site through the SSL checker from SSL Labs.

SSL Report

Headers: This bookmarklet will test the security headers on your website.

Security Headers

Drag any of those links to your browser’s toolbar to “install” them. If you don’t like one, you can delete it the same way you can delete any other bookmark.

I’m a little obsessed with web performance. I like being able to check a page’s core web vitals quickly and easily.

Four years ago, I made a Lighthouse bookmarklet. Whatever web page you were on, when you clicked on the bookmarklet you’d get the Lighthouse results for that page. Handy!

It doesn’t work anymore. This is probably because Google are in the loop. Four years is pretty good innings for anything involving that company.

I kid (mostly). Lighthouse itself is still going strong, despite being a Google product. But the bookmarklet needs updating.

Rather than just get Lighthouse results, I figured that the full PageSpeed Insights results would be even better. If your website is in the Chrome UX report, you get to see those CrUX details too.

So here’s the updated bookmarklet:

PageSpeed Insights

Drag that up to your desktop browser’s bookmarks toolbar. Press it whenever you want to test the page you’re on.

I use Firefox. You should too. It’s fast, secure, and more privacy-focused than the leading browser from the big G.

When it comes to web development, the CSS developer tooling in Firefox is second-to-none. But when it comes to JavaScript and network-related debugging (like service workers), Chrome’s tools are currently better than Firefox’s (for now). For example, Chrome has a tab in its developer tools that lets you run Lighthouse on the currently open tab.

Yesterday, I got the Calibre newsletter, which always has handy performance-related links from Karolina. She pointed to a Lighthouse extension for Firefox. “Excellent!”, I thought, and I immediately installed it. But I had some qualms about installing a plug-in from Google into a browser from Mozilla, particularly as the plug-in page says:

This is not a Recommended Extension. Make sure you trust it before installing

Well, I gave it a go. It turns out that all it actually does is redirect to the online version of Lighthouse. “Hang on”, I thought. “This could just be a bookmarklet!”

So I immediately uninstalled the browser extension and made this bookmarklet:

Lighthouse

Drag that up to your desktop browser’s bookmarks toolbar. Press it whenever you’re on a site that you want to test.

I was idly thinking about the different ways I can post to adactio.com. I decided to count the ways.

Admin interface

This is the classic CMS approach. In my case the CMS is a crufty hand-rolled affair using PHP and MySQL that I wrote years ago. I log in to an admin interface and fill in a form, putting the text of my posts into a textarea. In truth, I usually write in a desktop text editor first, and then paste that into the textarea. That’s what I’m doing now—copying and pasting Markdown from the Typed app.

Directly from my site

If I’m logged in, I get a stripped down posting interface in the notes section of my site.

Bookmarklet

This is how I post links. When I’m at a URL I want to bookmark, I hit the “Bookmark it” bookmarklet in my browser’s bookmarks bar. That pops open a version of the admin interface tailored specifically for links. I really, really like bookmarklets. The one big downside is that they don’t work on mobile.

Text message

This is something I knocked together at Indie Web Camp Brighton 2015 using the Twilio API. It’s handy for posting notes if I’m travelling somewhere and data is at a premium. But I don’t use it that often.

Instagram

Thanks to Aaron’s OwnYourGram service—and the fact that my site has a micropub endpoint—I can post images from Instagram to my site. This used to happen instantaneously but Instagram changed their API rules for the worse. Between that and their shitty “algorithmic” timeline, I find myself using the service less and less. At this point I’m only on their for the doggos.

Swarm

Like OwnYourGram, Aaron’s OwnYourSwarm allows me to post check-ins and photos from the Swarm app to my site. Again, micropub makes it all possible.

OwnYourGram and OwnYourSwarm are very similar and could probably be abstracted into a generic service for posting from third-party apps to micropub endpoints. I’d quite like to post my check-ins on Untappd to my site.

Other people’s admin interfaces

Thanks to rel="me" and IndieAuth, I can log into other people’s posting interfaces using my own website as the log-in, and post to my micropub endpoint, like this. Quill is a good example of this. I don’t use it that much, but I really should—the editor interface is quite Medium-like in its design.

Anyway, those are the different ways I can update my website that I can think of right now.

Syndication

In terms of output, I’ve got a few different ways of syndicating what I post here:

• RSS feeds for my journal, links, articles, and notes.
• JSON feeds for my journal, links, articles, and notes.
• Twitter accounts for my journal, links, articles, and notes (that one is my main Twitter account).
• I syndicate most of my my photos to my Flickr account.
• I syndicate most of my journal posts and articles to my Medium account.
• I used to syndicate my links to my Delicious account but at some point that became fairly pointless.
• Whenever I post a link, The Internet Archive gets pinged and makes a copy for the wayback machine. Here’s an example of a recent link.
• I syndicate just about everything to my Facebook account using If This, Then That recipes (RSS to Facebook posts). Facebook is a roach motel. I never post any original content there—everything starts here on my site.

Just so you know, if you comment on one of my posts on Facebook, I probably won’t see it. But if you reply to a copy of one of posts on Twitter or Instagram, it will show up over here on adactio.com thanks to the magic of Brid.gy and webmention.

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.

Content Security Policies (https://en.wikipedia.org/wiki/Content_Security_Policy) are great except that they prevent bookmarklets like @instapaper from loading. 😐

— Jason Garber (@jgarber) March 16, 2016

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.

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:

huffduff-video lets you send @Huffduffer the audio from videos on YouTube, Vimeo, and more! https://t.co/fBkMBESI61 http://t.co/2pNItWGL8f

— Ryan Barrett (@schnarfed) March 8, 2015

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!

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

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.