Archive: March, 2016

It’s funny how times have changed. Remember back in the 90s when Microsoft—quite rightly—lost an anti-trust case? They were accused of abusing their monopolistic position in the OS world to get an unfair advantage in the browser world. By bundling a copy of Internet Explorer with every copy of Windows, they were able to crush the competition from Netscape.

Mind you, it was still possible to install a Netscape browser on a Windows machine. Could you imagine if Microsoft had tried to make that impossible? There would’ve been hell to pay! They wouldn’t have had a legal leg to stand on.

Yet here we are two decades later and that’s exactly what an Operating System vendor is doing. The Operating System is iOS. It’s impossible to install a non-Apple browser onto an Apple mobile computer. For some reason, the fact that it’s a mobile device (iPhone, iPad) makes it different from a desktop-bound device running OS X. Very odd considering they’re all computers.

“But”, I hear you say, “What about Chrome for iOS? Firefox for iOS? Opera for iOS?”

Chrome for iOS is not Chrome. Firefox for iOS is not Firefox. Opera for iOS is not Opera. They are all using WebKit. They’re effectively the same as Mobile Safari, just with different skins.

I had a dream where this was removed:

“2.17: Apps that browse the web must use the iOS WebKit framework and WebKit Javascript” #ItsTime

— Dion Almaer (@dalmaer) March 19, 2016

But there won’t be any anti-trust case here.

I think it’s a real shame. Partly, I think it’s a shame because as a developer, I see an Operating System being let down by its browser. But mostly, I think it’s a shame because I use an iPhone and I’m being let down by its browser.

It’s kind of ironic, because when the iPhone first launched, it was all about the web apps. Remember, there was no App Store for the first year of the iPhone’s life. If you wanted to build an app, you had to use web technologies. Apple were ahead of their time. Alas, the web technologies weren’t quite up to the task back in 2007. These days, though, there are web technologies landing in browsers that are truly game-changing.

In case you hadn’t noticed, I’m very excited about Service Workers. It’s doubly exciting to see the efforts the Chrome on Android team are making to make the web a first-class citizen. As Remy put it:

If I add this app to my home screen, it will work when I open it.

I’d like to be able to use Chrome, Firefox, or Opera on my iPhone—real Chrome, real Firefox, or real Opera; not a skinned version of Safari. Right now the only way for me to switch browsers is to switch phones. Switching phones is a pain in the ass, but I’m genuinely considering it.

Whereas I’m all talk, Henrik has taken action. Like me, he doesn’t actually care about the Operating System. He cares about the browser:

Android itself bores me, honestly. There’s nothing all that terribly new or exciting here.’

save one very important detail…

IT’S CURRENTLY THE BEST MOBILE WEB APP PLATFORM

That’s true for now. The pole position for which browser is “best” is bound to change over time. The point is that locking me into one particular browser on my phone doesn’t sit right with me. It’s not very …webby.

I’m sure that Apple are not quaking in their boots at the thought of myself or Henrik switching phones. We are minuscule canaries in a very niche mine.

But what should give Apple pause for thought is the user experience they can offer for using the web. If they gain a reputation for providing a sub-par web experience compared to the competition, then maybe they’ll have to make the web a first-class citizen.

If I want to work towards that, switching phones probably won’t help. But what might help is following Alex’s advice in his answer to the question “What do we do about Safari?”:

What we do about Safari is we make websites amazing …and then they can’t not implement.

I’ll be doing that here on adactio, over on The Session (and Huffduffer when I get around to overhauling it), making progressively enhanced, accessible, offline-first, performant websites.

I’ll also be doing it at Clearleft. If you work at an organisation that wants a progressively-enhanced, accessible, offline-first, performant website, we should talk.

I have lovely friends who are making lovely things. Surprisingly, lots of these lovely things aren’t digital (or at least aren’t only digital).

My friends Brian and Joschi want to put on an ambitious event called Material:

A small conference based in Reykjavik, Iceland, looking into the concept of the Web as a Material — 22nd July 2016, https://material.is

They’re funding it through Kickstarter. If you have any interest in this at all, I suggest you back it. Best bet is to pledge the amount that guarantees you a ticket to the conference. Go!

My friend Matt has a newsletter called 3 Books Weekly to match his Machine Supply website. Each edition features three book recommendations chosen by a different person each time.

Here’s the twist: there’s going to be a Machine Supply pop-up bookshop AKA a vending machine in Shoreditch. That’ll be rolling out very soon and I can’t wait to see it.

My friend Josh made a crazy website to tie in with an art project called Cosmic Surgery. My friend Emily made a limited edition run of 10 books for the project. Now there’s a Kickstarter project to fund another run of books which will feature a story by Piers Bizony.

An Icelandic conference, a vending machine for handpicked books, and a pop-up photo book …I have lovely friends who are making lovely things.

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.

Over on The Session I have a few instances of a progressive disclosure pattern. It’s just your basic show/hide toggle: click on a button; see some more content. For example, there’s a “download” button for every tune that displays options to download the tune in different formats (ABC and midi).

To begin with, I was using the :checked pseudo-class pattern that Charlotte has documented so well. I really like that pattern. It feels nice and straightforward. But then I got some feedback from someone using the site:

the link for midi files is no longer coming up on the tune pages. I am blind so I rely on the midi’s when finding tunes for my students.

I wrote back saying the link to download midi files was revealed by the “download” option. The response:

Excellent. I have it now, I was just looking for the midi button which wasn’t there. the actual download button doesn’t read as a button under each version of the tune but now I know it’s there I know what I am doing. I am using the JAWS screen reader.

This was just one person …one person who took the time to write to me. What about other screen reader users?

I dabbled around with adding role="button" to the checkbox or the label, but that felt really icky (contradicting the inherent role of those elements) and it didn’t seem to make much difference anyway.

I decided to refactor the progressive disclosure to use JavaScript instead just CSS. I wanted to make sure that accessibility was built into the functionality, rather than just bolted on. That’s why code I’ve written doesn’t rely on the buttons having a particular class value; instead the buttons must have an aria-controls attribute that associates the button with the element it toggles (in much the same way that a for attribute associates a label with a form field).

Here’s the logic:

1. Find any elements that have an aria-controls attribute (these should be buttons).
2. Grab the value of that aria-controls attribute (an ID).
3. Hide the element with that ID by applying aria-hidden="true" and make that element focusable by adding tabindex="-1".
4. Set aria-expanded="false" on the associated button (this attribute can be a bit confusing—it doesn’t mean that this element is not expanded; it means the element it controls is not expanded).
5. Listen for click events on those buttons.
6. Toggle the aria-hidden and aria-expanded when there’s a click event.
7. When aria-hidden is set to false on an element (thereby revealing it), focus that element.

You can see it action on CodePen.

I’m still playing around with this. I think the :focus styles are probably far too subtle right now—see this excellent presentation from Laura Palmaro for more on that. I’m also not sure if the revealed content should automatically take focus. I’ll see if I can get some feedback from people on The Session using screen readers—there’s quite a few of them.

Feel free to use my code but you might want to check out Jason’s code to do the same thing—his is bound to be nicer to work with.

Update: In response to this discussion, I’ve decided not to automatically focus the expanded content.

The latest issue of Spaceflight—the magazine of the British Interplanetary Society—dropped through my door, adding to my weekend reading list. This issue contains a “whatever happened to” article about the military personnel who were supposed to crew the never-realised MOL project.

Before Salyut, Skylab, Mir, or the ISS, the Manned Orbital Laboratory was the first proposed space station. It would use a Gemini capsule and a Titan propellant tank.

But this wasn’t to be a scientific endeavour. The plan was to use the MOL as a crewed spy satellite—human eyes in the sky watching the enemy below.

The MOL was cancelled (because uncrewed satellites were getting better at that sort of thing), so that particular orbital panopticon never came to pass.

I remember when I first heard of the MOL and I was looking it up on Wikipedia, that this little nugget of information stood out to me:

The MOL was planned to use a helium-oxygen atmosphere.

That’s right: instead of air (21% oxygen, 79% nitrogen), the spies in the sky would be breathing heliox (21% oxygen, 79% helium). Considering the effect that helium has on the human voice, I can only imagine that the grave nature of the mission would have been somewhat compromised.

Last year I met up with Simon McManus in a Brighton pub where he told me about his plan to run a conference dedicated to progressive enhancement. “Sounds like a great idea!”, I said, and offered him any help I could.

With the experience of organising three dConstructs and three Responsive Days Out, I was able to offer some advice on the practical side of things like curation, costs and considerations. Simon also asked me to MC his event. I was only too happy to oblige. After all, I was definitely going to be at the conference—wild horses wouldn’t keep me away—and when have I ever turned down an opportunity to hog the mic?

Simon chose a name: EnhanceConf. He found a venue: The RSA in London. He settled on a date: March 4th, 2016. He also decided on a format, the same one as Responsive Day Out: four blocks of talks, each block consisting of three back-to-back 20 minute presentations followed by a group discussion and questions.

With all those pieces in place, it was time to put together a line-up. I weighed in with my advice and opinions there too, but the final result was all Simon’s …and what a great result it was.

Yesterday was the big day. I’m happy to report that it was a most splendid event: an inspiring collection of brilliant talks, expertly curated like a mixtape for the web.

Nat got the day off to a rousing start. They gave an overview of just how fragile and unpredictable the World Wide Web can be. To emphasise this, Anna followed with detailed look at the many, many console browsers people are using. Then Stefan gave us a high-level view of sensible (and not-so-sensible) architectures for building on the web—a talk packed to the brim with ideas and connections to lessons from the past that really resonated with me.

After that high-level view, the next section was a deep dive into strategies for building with progressive enhancement: building React apps that share code for rendering on the server and the client from Forbes; using Service Workers to create a delightful offline experience from Olly; taking a modular approach to how structure our code and cut the mustard from Stu.

The after-lunch session was devoted to design. It started with good ol’ smackdown between Phil and Stephen, which I attempted to introduce in my best wrestling announcer voice. That was followed by a wonderfully thoughtful presentation by Adam Silver on Embracing Simplicity. Then Jen blew everyone away with a packed presentation of not just what’s possible with CSS now, but strategies for using the latest and greatest CSS today.

Finally, the day finished with a look to the future. And the future is …words. Robin was as brilliant as ever, devising an exercise to get the audience to understand just how awful audio CAPTCHAs are, but also conveying his enthusiasm and optimism for voice interfaces. That segued perfectly into the next two talks. Stephanie gave us a crash course in crafting clear, concise copy, and Aaron tied that together with Robin’s musings on future interactions with voice in a great final presentation called Learn From the Past, Enhance for the Future (echoing the cyclical patterns that Stefan was talking about at the start of the day).

As the day wrapped up, I finished by pointing to a new site launched by Jamie on the very same day: progressiveenhancement.org. With that, my duties were fulfilled.

I thoroughly enjoyed listening to the talks and then quizzing the speakers afterwards. I really do enjoy moderating events. Some of the skills are basic (pronouncing people’s names correctly, using their preferred pronouns) and some are a little trickier (trying to quickly spot connections, turning those connections into questions for each speaker) but it’s very rewarding indeed.

I had a blast at EnhanceConf. I felt bad though; lots of people came up to me and started thanking me for a great day. “Don’t thank me!” I said, “Thank Simon.”

Thanks, Simon.

James and I went to Ipswich last week for work. But this wasn’t part of an ongoing project—this was a short intense one-week feasibility study.

Leon from Suffolk Libraries got in touch with us about a project they’re planning to carry out soon: replacing their self-service machines with something more up-to-date. But rather than dive into commissioning the project straight away, he wisely decided to start with a one-week sprint to figure out exactly what the project would need to go ahead.

So that’s what James and I did. It was somewhat similar to the design sprint popularised by GV. We ensconced ourselves in the Ipswich library and packed a whole lot of work into five days. There was lots of collaboration, lots of sketching, lots of iterative design, and some rough’n’ready code. It was challenging, but a lot of fun. Also: we stayed in a pretty sweet AirBnB.

You can read all about it in our case study. You can also read all about from Leon’s point of view on his blog:

I can’t recommend this kind of research sprint enough. We got a report, detailed technical validation of an idea, mock ups and a plan for how to proceed, while getting staff and stakeholders involved in the project – all in the space of 5 days.

I think this approach makes a lot of sense. By the end of the week, James and I felt pretty confident about estimating times and costs for the full project. Normally trying to estimate that kind of thing can be a real guessing game. But with the small of investment of one week’s worth of effort, you get a whole lot more certainty and confidence.

Have a look for yourself.

Running The Session and Huffduffer is immensely rewarding …most of the time. There are occasions when the actions of a few bad apples make it a real pain in the bum.

Yes, I’m talking about SEO spammers.

Huffduffer tends to get it worse than The Session, but even then it’s fairly manageable—just a sign-up or two here or there. This weekend though, there was a veritable spam tsunami. I was up late on Friday night playing a constant game of whack-a-mole with thousands of spam postings by newly-created accounts. (I’m afraid I inadvertently may have deleted some genuine new accounts in the trawl; if you signed up for Huffduffer last Friday and can’t access your account now, I’m really, really sorry.)

Normally these spam SEO accounts would have some pattern to them—either they’d be from the same block of IP addresses or they’d have similar emails. But these all looked different enough to thwart any quick fixes. I knew I’d be spending my Saturday writing some spam-blocking code.

Most “social” websites have a similar sign-up flow: you fill in a form with your details (including your email address), and then you have to go to your email client to click a link to verify that you are indeed who you claim to be. The cynical side of me thinks that this is mostly to verify that you providing a genuine email address so that the site can send you marketing crap.

Neither Huffduffer nor The Session includes that second step of confirming your email address. The only reason for providing your email address is so that you can reset your password if you ever forget it.

I’ve always felt that making a new user break out of the sign-up flow to go check their email was a bit shit. It also strikes me as following the same logic as CAPTCHAs (which I hate): “Because of the bad actions of a minority, we’re going to punish the majority by making them prove to us that they’re human.” It’s such a machine-centric way of thinking.

But after the splurge of spam on Huffduffer, I figured I’d have no choice but to introduce that extra step. Just as I was about to start coding, I thought to myself “No, this is wrong. There must be another way.”

I thought a bit more about the problem. The issue wasn’t so much about spam sign-ups per se. Like I said, there’s always been a steady trickle and it isn’t too onerous to find them and delete them. The problem was the sheer volume of spam posts in a short space of time.

I ended up writing some different code with this logic:

1. When someone posts to Huffduffer, check to see if they’ve posted at least ten items in the past;
2. If they have, grab the timestamps for the last ten posts;
3. Calculate the cumulative elapsed time between those ten posts;
4. If it’s less than 100 seconds (i.e. an average of one post every ten seconds), delete the user …and delete everything they’ve ever posted.

It worked. I watched as new spam sign-ups began to hammer the site with spam postings …only to self-destruct when they hit the critical mass of posts over time.

I’m still getting SEO spammers signing up but now they’re back to manageable levels. I’m glad that I didn’t end up having to punish genuine new users of Huffduffer for the actions of a few SEO marketing bottom-feeders.