Progressively Enhancing Progressive Enhancement

Last Friday I made a joke on Twitter about progressively enhancing the progressive enhancement on a site—turtles all the way down, ha ha. But in some ways I was being quite serious. One of the beautiful things about working on the web is that a site is never truly done, sometimes for worse but usually for the better. You can keep improving things iteratively, smoothing over the rough edges that may have existed at launch.

The Essay and Voices in Time articles on Lapham’s Quarterly feature random artwork and quotes (random in a sense that they’re only tangentially related to the article). Every issue has an associated pool of artwork and quotes, and each time we load an article we dip into that pool and inject some artwork/quotes into locations specified by the content author. This worked fairly well, but it’s always bothered me that our first implementation relied on JavaScript. So if JavaScript wasn’t available, or somehow failed (which we all know never ever happens, no no)—you didn’t get the artwork. We justified that decision based on the fact that the artwork and quotes are an enhancement on the article—the article makes perfect sense even without the random elements.

But still: it felt like it warranted a second pass. I really like how Aaron Gustafson advocates for unobtrusive JavaScript in his book Adaptive Web Design:

“Unobtrusive JavaScript is an idea that meshes perfectly with progressive enhancement philosophy because it forces JavaScript into the role of functional enhancement, as opposed to absolute requirement.”

So this past week we went back to work under the hood, pulling the JavaScript-reliant parts into a custom Drupal module. We did the same things we were doing on the client-side, except now we do them just before we render the page, using some new tricks we learned about selectively replacing markup after all Drupal modules have run. The result is a page that has all its artwork and quotes, even if JavaScript takes a nap. Most people (hopefully) won’t notice a thing, but I’m glad that we’ve continued to move towards a more accessible and inclusive site.

Lapham’s Quarterly

A few dev notes on the recently-launched redesign of Lapham’s Quarterly:

  • The site was designed and built by Bluecadet (with the exception of the online store, for which we only did the design templates). Design was led by Theresa Decker. Will Vedder and Greg Sarault handled most of the development. Kevin Zakszewski did a lot of early responsive prototyping during the wireframe and design phases. Rebecca Smith handled both content strategy and project management (!). I did technical strategy and a few tricky Drupal/JavaScript pieces.
  • It’s a Drupal site. Drupal can be a sprawling beast sometimes, but it was a good fit for this project because of the complex relationships between issues, contributors, and individual articles.
  • We built and deployed the site on Pantheon, which allowed us to open up the CMS to content authors in one tier while we developed/tested on the other tiers.
  • A lot of Lapham’s Quarterly’s content requirements involved some form of what we internally dubbed “sophisticated whimsy” – Essays and Voices in Time on the issue page had to be pulled randomly, for instance. We ended up doing a few compound views to achieve complex layouts.
  • Artwork and quotes that appear on Essays and Voices in Time are not directly related to the piece itself (carrying over a hallmark of the print quarterly). For the website, however, Lapham’s Quarterly wanted the artwork and quotes to also be random, lending the piece a slightly different look each time it was loaded. Content authors choose the point at which they want to insert an instance of one of three types of content: a column-width image, a widescreen image, or a quote. These generate markup patterns that then replaced with a random instance of artwork, pulled from the available options for that issue (each issue has a bucket of artwork/quotes).
  • Each issue that Lapham’s Quarterly publishes has a signature color. In the website’s design system this translates to a set of four hex values to cover different states: default, rollover, emphasis, etc. We wouldn’t be able to treat those colors as Sass variables, since we didn’t want to have to add to the stylesheet each time Lapham’s Quarterly published a new issue. So they are injected at the page template level, based on the values set by content authors for that issue. The styles … cascade.
  • Lapham’s Quarterly needed a way to designate an issue as “Coming Soon”. This meant that any content associated with that issue would not be displayed/linked from the archive pages. We had to write a few hook functions to filter taxonomies prior to display.
  • Handling BC dates turned into more of an interesting development problem than we anticipated, because we wanted to keep the actual date value different from the display, to make sorting content by date easier. We ended up writing a small custom module to transform BC dates for display.
  • There was a lot of iterative design and development for this project. One example is the slide-out tab allows you to get back to the main issue page. That was originally visible at all times, but as we started testing content we realized that it obscured the widescreen images. So we turned it into a little pull-tab.
  • There’s no single workflow technique that emerged from this project, just a general feeling that team conversations around a whiteboard are rarely a waste of time. In most cases we arrived at a faster, more bulletproof solution than if we had sealed ourselves off to work in isolation.

We’re still fine-tuning thing under the hood, but I’m very happy with how the project turned out.