July 4th, 2015

July 3rd, 2015

100 × 100

For 100 days I wrote and published a blog post that was 100 words long. This was all part of the 100 Days project running at Clearleft. It was by turns fun, annoying, rewarding, and tedious.

It feels nice to have 10,000 words written by the end of it even if many of those words were written in haste, without much originality and often without much enthusiasm. There were many evenings when I was already quite tired and then remembered that I had to bash out 100 words. On those occasions, it really felt like a chore, but then, that’s the whole point of the exercise—that you do it every day regardless of how motivated or not you feel on that day.

I missed the daily deadline once. I could make the excuse that it was a really late night of carousing, but I knew in advance that I was going to be out so I could’ve written my 100 words ahead of time—I didn’t.

My exercise of choice wasn’t too arduous. Some of the other Clearlefties picked far more ambitious tasks. Alas, many of them didn’t make it to the finish line, probably because they set their own bar so high. I knew that I wanted to do something that involved writing, and I picked the 100 words constraint simply because it sounded cute.

Lots of people reading my posts thought that 100 words was the upper limit in the same way that 140 characters is the upper limit on Twitter. But for me, the whole point of the exercise was that each post needed to be 100 words exactly. Now I kind of want to write a Twitter client that only lets you post tweets that are exactly 140 characters.

Writing a post that needed to be an exact number of words long was where the challenge lay, but it was also where the reward was found. It was frustrating to have to excise words or even whole sentences just to make the word count fit, but it was also very satisfying when the final post felt like a fully-formed thing.

I realised a few weeks into the project that the piece of software I was writing in (and relying on for an accurate word count) was counting hyphenated phrases as one word. So the phrase “dog-eat-dog world” was counted as two words, not four. I worried that maybe I had already published some posts that were over 100 words long. Later on, I tried to avoid hyphenating, or else I’d add in the hyphens after I had hit the 100 word point. In any case, there may be some discrepancy in the word count between the earlier posts and the later ones.

That’s the thing about an exercise that involves writing exactly 100 words; it leads to existential questions like “what is a word anyway?”

Some of the posts made heavy use of hyperlinks. I wondered whether this was cheating. But then I decided that, given the medium I was publishing on, it would be weird not to have any hyperlinks. And the pieces still stand on their own if you don’t follow any of the links.

Most of the posts used observations from that day for their subject matter—diary-like slices of life. But occasionally I’d put down some wider thought—like days 15, 73, 81, or 98. Still, I suspect it’s the slice-of-life daily updates that will be most interesting to read back on in years to come.

July 2nd, 2015

Black Hack Down is the same story as Red Dawn, just told from the perspective of the invading force.

Baseline

Jake gave a great talk at Responsive Day Out 3 all about nuanced progressive enhancement, with a look at service workers in particular (a technology designed with progressive enhancement at its heart).

To illustrate the performance gains, Jake used his SVGOMG site as an example—a really terrific resource for optimising SVGs.

SVGOMG requires JavaScript for its core functionality (optimising an SVG file). That was a deliberate choice. Jake could’ve made the barrier-to-entry as low as any browser that supports input type="file" but he decided that for this audience (developers) it was a safe assumption that JavaScript would be available.

Jake talked about this in an interview with Paul about the site:

I’m a strong believer in progressive enhancement, but also that each phase of the enhancement needs a user.

I agree completely with this approach. It makes sense to have a valid reason for adding any enhancement. But there’s something about this particular example that wasn’t sitting right with me. It took me a while to figure it out, but I now realise what it is.

Jake is talking about making it work on the server as an enhancement. But that’s not an enhancement, it’s a fallback.

Thinking in terms of fallbacks is more of a “graceful degradation” approach (i.e. for every “full” feature, thinking of a corresponding fallback). That’s not how I like to think of progressive enhancement. I like to think in terms of a baseline. And that baseline, in my mind, does not require a user to justify its existence. That’s because the baseline isn’t there to cover the use cases we can think of, it’s there to cover the use cases we can’t predict.

That might seem like a minor difference in wording to the graceful degradation approach but I think it’s actually a fundamentally different way of approaching the situation.

When I was on the progressive enhancement panel at Edge Conf, Lyza asked how low the baseline should be. I said “as low as possible.” Some of my fellow panelists took issue with this saying it varies from project to project, and that’s completely true, but I think I should’ve clarified that when I talk about a baseline, I’m not talking about browsers. I don’t think about a baseline in terms of “IE4 and above, Android 2.1 and above, etc.”—I think about a baseline in terms of “the minimum required technology to allow a user to accomplish the core task” (that qualification about core tasks is important—the baseline does not need to cover tasks that are nice-to-have; those can safely require more sophisticated technology).

That “minimum required technology” often turns out to be a combination of a web server, HTTP, and some HTML.

So to take SVGOMG as an example, I would begin with the baseline of “allowing a user to optimise an SVG file”. The minimum required technology is a web server running a programme that does the optimisation, and an HTML document that contains a form element with input type="file". Once that’s in place, then I can start applying Jake’s very sensible approach of thinking about enhancements in terms of specific user benefits. In this case, it’s pretty clear that 99.99% of the users would benefit from not having that round-trip to the server and have the SVG optimisation happen in the browser using JavaScript.

There’s an enhancement provided for the use case that I can imagine. But—and this is the subtle but important distinction—there’s a baseline for all the use cases that I can’t think of. I need to recognise that I won’t be able to predict all the possible use cases, and that’s okay—as long there’s a solid baseline in place, I’ve got an insurance policy for unforeseen circumstances. It’s still not perfect, but it lowers the risk somewhat by reducing the number of assumptions being built in at that baseline level.

Going back to Jake’s chat with Paul, he says:

I thought about making the site work without JS by doing the SVG work on the server, but this would be slow and a maintenance burden.

The maintenance burden is a very valid point. This is something that Stuart talked about a while back:

It is in theory possible to write a web app which does processing on the server and is entirely robust against its client-side scripting being broken or missing, and which does processing on the client so that it works when the server’s unavailable or uncontactable or expensive or slow. But let’s be honest here. That’s not an app. That’s two apps.

Leaving aside the promise of isomorphic/universal/whatever JavaScript, this issue of developer convenience is big issue. When I use the term “developer convenience” to label this problem, I am not belittling it in any way—developer convenience is incredibly important (hence the appeal of so many tools and frameworks that make life easier for developers). I still believe that developer convenience should be lower on the list of priorities than having a rock-solid baseline, but I can totally understand if someone doesn’t share that opinion. It’s a personal decision and if the pain involved in making a more universal baseline is greater than the perceived—and, let’s face it, somewhat abstract—benefit, I can totally understand that.

Anyway, that’s my little brain dump about progressive enhancement and baseline experiences. Something about treating the baseline experience as an enhancement was itching at my brain and now that I’ve managed to scratch it, I can see what was troubling me: thinking about the baseline experience in the same way as thinking about enhancements doesn’t work for me.

Personally, I’m going to strive to keep the baseline as low as possible. I’m also going to strive to apply Jake’s maxim about every enhancement requiring a user.

July 1st, 2015

It’s the hottest day of the year so far and I’m going to spend it going to London and back in a train.

This will not end well.

June 30th, 2015

100 words 100