In print, designers put a lot of work into giving feature stories the right aesthetic, building them around pull-quotes and art to set the right tone and help the reader navigate long pieces. If you open a cover story, what you see is bespoke, tailored to the article.
But the web is a dynamic medium. I can write a line of code to make subheads change fonts and colors, but I’ll have to maintain that line of code forever. It’s all too easy to trap yourself under a sea of special cases. Do enough of these, and it would become impossible to do any front-end work on TheAtlantic.com without unintended consequences.
And what happens to these stories when we do a redesign? Or two? We obviously don’t want our archives to look broken, and as the number of bespoke designs accumulate, porting the work forward would become a huge problem.
Etch it in stone? Not so fast.
One way product teams have tried to solve this problem is by archiving the final product in static html. That works for now — future changes to the site won’t hurt the article, but is that a good thing?
My other big project is trying to make our ads load faster and go easier on slow browsers. If you’re reading a 20,000 word story on a phone (people do!), you’d benefit a lot from this. But if we froze the page as static html, it wouldn’t benefit from any new ideas or updates.
And over time, frozen pages grow stale. We have a few archival pages like this. They look like they were built in 2006 (they were) and don’t work on mobile, because they were left behind during our responsive redesign.
The standards for news sites are always on the rise. I’d hate to have some of our best journalism trapped in an old format.
Enhancements is Born
To solve this problem, we made a small tool called Enhancements.
The way web frameworks (i.e., Django) render a page is by taking a context (information from the database, like the article’s text, authors, and images) and applying it to a template, producing HTML. Enhancements provides a way to modify the context just before the page renders.
- The version of the article we keep in the database is clean. If you take the customizations away it looks like any other big story, complete with large art, but none of the bespoke styles.
- On the web, for as long as we choose to maintain it, I can do any transformations I want.
That’s given us the freedom to layer headlines over photos, make custom pullquotes that fit the tone of the piece, tweak caption styles, and other small design changes that help capture the tone of the story.
And it lets us do it fast. The Trump story took was done and tested in an afternoon. For a small team like ours, that’s a huge deal.
On a technical level, this works with a custom stylesheet for the story, and swapping out pieces of the regular template to avoid collisions.
When the day comes that we have a big redesign, or need to make all our archives work in Virtual Reality Internet (is that the next frontier?), we have a choice:
We can do whatever work needs to be done to bring the custom styles into the new world, or we can retire them, and the article will return to the regular look and feel of our other feature stories.
Of course, our designers are only starting to scratch the surface of what they can do with this.
The Dark Side of Bespoke Cover Stories (And How We Tried to Solve It) was originally published in Building The Atlantic on Medium, where people are continuing the conversation by highlighting and responding to this story.