Fitting Design to the News

Last week, Felix Salmon wrote a blog post titled “Against Beautiful Journalism.” In it, he argued against the wholesale elevation of online news stories with designs he categorized as “beautiful.” He noted:

It’s time for websites to put a lot more effort into de-emphasizing less important stories, reserving the grand presentation formats only for the pieces which deserve it. In theory, most content management systems these days support various different story templates; in practice, however, there’s a kind of grade inflation going on, and everything ends up getting the A-list treatment.

Salmon professes a view that news is generally meant to be short and disposable. Kitting out articles with, “huge photos, loads of white space, intuitive and immersive scrolling, [and] super-wide column widths,” signals the opposite of that to the reader.

Because it’s often tangled up with personal taste, conversations about news design can get very messy, very fast. Our idea of what news should be influences our aesthetic preferences. Clearly that’s the case for Salmon.

That said, few could argue with a call for design to better match content. That’s the ultimate goal of all editorial design. To that end, we shouldn’t be giving toss-off content the Rolls Royce treatment. Beyond that though, I think Salmon’s post is off in some key areas.

First, “beautiful” is not the current majority default, despite the impression the post gives. The usual suspects cited—the New York Times, Quartz, Medium—represent a rarefied subset of what’s going on across the entire news and publishing spectrum. Yes, they are incredibly influential, and yes, there is certainly a trend, but several high profile examples does not constitute a landslide of over-design. Spend a little time looking around, and you’ll likely find “ugly” is still very much the default.

Second, with regard to CMSs, everything hinges on those two key words: “in theory.”

In theory, yes, plenty of modern CMSs give us flexible templates. In practice, I can count on one hand the newsrooms that are happy with them. (To count the ones that actively hate the template limitations imposed by their CMS, I’d need several volunteers worth of hands.) We’re not talking about minor nitpicks, either. Basic design tasks like customizing headline sizes or swapping layout modules on the fly still gum up the works far more often than they should.

The situation is improving, and therein lies the irony. Across newsrooms in the last eighteen to twenty-four months, the main driving force behind greater CMS flexibility is the same thing popularizing the aesthetic Salmon takes to task: Snow Fall.

As I’ve said before, the current bespoke editorial trend is paying us dividends beyond pretty articles. It’s been an active R&D lab, one of the biggest areas of experimentation being template flexibility.

Step one was inventing ways to “jailbreak” from CMS defaults. Step two is folding those inventions back into the CMS. Taken together with lessons learned about how and when to use it, the result is a major step forward for online art direction.

We’re gaining the ability to dial presentations up or down on a per-article basis, when the situation calls for it. It just happens we started by concentrating on the “up,” because “down” is a place where most of our designs have already been.

Gemsbok Diorama

The gemsbok diorama at the American Museum of Natural History, photographed a few weekends ago.

Turning Against the Stream

Last week Alexis Madrigal, writing in The Atlantic, explored a possible turning point for “streams” as a media design principle. Taken at its most literal, the “streams” mindset has resulted in news designs optimized almost exclusively around reverse chronological lists. It’s an idea that’s been hot inside news startups these last few years, with entire outlets launching around the concept. Madrigal remarks:

There are great reasons for why The Stream triumphed. In a world of infinite variety, it’s difficult to categorize or even find, especially before a thing has been linked. So time, newness, began to stand in for many other things.

But while it may work for some apps and services, I’ve always felt it was a particularly thin organizing principle for all but the shallowest content. Content that isn’t much more than a datum, where timeliness really is the only modifier beyond the basic fact being conveyed. A list of headlines. A crawl of stock quotes.

For those things, “nowness” can be a wonderful thing to optimize for. But the stream does a lousy job of communicating any context other than timeliness. It’s not even good at conveying time beyond a certain limited range, since the characteristics of most reverse chronological lists make even that utility fleeting.

At its worst, the stream represents an abdication of design and editing in news. The lessons we learned from the mid-aughts, when news design departments were getting hit with feverish requests to redesign their sites around search bars, feel particularly relevant here.

We re-learned then that organizing for a single approach vector hurt the prioritization of information, the establishing of context. When users come to a news homepage or land on a story, they often don’t know what they don’t know. Or they have an idea there’s something they should read up on and need to find out more about. Streams are an inefficient mechanism for either.

That said, I don’t think the two are as mutually exclusive as Madrigal implies. There are operations capable of toggling between the two, representing content in an editorially-informed way when that context matters, and switching to a view that optimizes for timeliness when that takes priority. (Or, to use Madrigal’s artful turn of phrase, between “nowness,” and a, “network of many times.”)

Organizations already equipped with a strong editorial component will have an easier time operating across these two modes. For them, presenting content in a stream is an act of reduction and reordering. A filter switch.

Companies that have baked the vogue for streams too deeply into their mindsets and operating structures will have the harder time of it. For them, creating context requires developing a shrewdness they don’t already possess. And it only follows after a recognition that context matters—maybe even more, in the long run, than the success of streams led them to believe.

Prototype for a 3D Printed House, Softkill Design
Open artist studio, Museum of Arts and Design

Materializing and Rematerializing

If you find yourself passing through midtown Manhattan and have a little spare time on your hands, I recommend a detour over to the Museum of Arts and Design.

Their latest exhibition, Out of Hand: Materializing the Postdigital, features works conceived or built using digital techniques. There’s a heavy emphasis on geek-friendly tools like 3D printing, CNC milling, and even “digital knitting.”

Many of the resulting works sport intricate constructions too challenging or cost-prohibitive for traditional manufacturing. Others involve playful reinterpretations of existing works enabled by 3D scanning and editing.

The museum is camera-friendly, and operates a set of open studios on the upper floors, where you can visit with artists and discuss their work.

Print to Screen, Static to Dynamic

A little over a week ago I attended the first US incarnation of Ampersand, a web-centric gathering of type pros and enthusiasts hosted by the good folks at Clearleft. The days since have been a bit packed, so I’m totally being that guy and just getting around to posting something about it now.

Print to Screen

One of the highlights for me was Jonathan Hoefler’s talk on the evolution of web typography, starting with the construction of his own Hoefler Text and leading all the way to the launch of H&FJ’s cloud.typography service. Nuanced and timely, Hoefler conveyed a ton of detail with impressive eloquence. To echo Jeffrey’s tweet, it was one of the best type talks I’ve seen.

Hoefler dissected the problems that come from blindly applying existing methods to new mediums. For web type, that means reusing fonts originally designed for print without tuning them for the screen. It might not seem too bad, but consider that what you see on screen when you’re using a print font is actually a representation of the intended output, not the actual design.

The results can be pretty horrific, even to the untrained eye. But it’s still the way many typefaces make it to the web. Hoefler summarized the situation as having, “fonts on the web, but not fonts for the web,” and went on to detail the incredible effort H&FJ has put into retooling their own type library for the screen.

Static to Dynamic

I do have a little quibble with something that came up later in the talk, though.

At one point Hoefler displayed two maps side by side to illustrate a point about the typographic richness we’ve lost (or have yet to rebuild) in the shift from print to digital. On one side was an old print map, dense with typographic details, all used to convey a wide array of information in a single packed view. On the other side was a relatively sparse screenshot from an online map service, sporting few if any typographic details.

In the context of a static presentation slide, the print map seemed like the one using typography to maximum effect. It conveyed the most information in a single glance. The absence of that detail in the interactive map gave the impression that the newer service had less to offer. But the context is incomplete.

The paper map is a piece of static information design. It needs to convey everything it can in the single view it has. The density of its typography is a feature born of necessity. It can’t adapt to its context, and has no ability to selectively give focus to what’s relevant at the moment.

The digital map can do all these things. It doesn’t need type to function in exactly the same way it did in print because it’s dynamic and adaptable. That doesn’t mean it doesn’t need typographic richness. It just doesn’t have to show it the same way as the print map.

A frozen picture of the thing simply doesn’t convey the fundamental nature of it. It isn’t fully realized until it’s interacted with. And that’s important to remember when making these old-vs-new comparisons.

Giraffe Needs a Monocle

Photographed last weekend in the Carter Giraffe Building at the Bronx Zoo. I really enjoy these serendipitous moments behind the lens, when chance lets you present slightly unfamiliar subjects in slightly unexpected contexts. Hope to add more to this Flickr set soon.

Recent Instagrams: Urban and Rural

A few Instagrams from recent travels. Clockwise from upper left: Pelicans flying formation over Daytona Beach, Florida; a construction crane in midtown Manhattan; the new facade of the Smith & 9th Street subway station in Brooklyn; a farm field in Germantown, New York.

Making Inline SVG Play Nice in Legacy IE

Last week I was tearing my hair out trying to track down why the latest version of this site was rendering so badly in legacy versions of Internet Explorer.

It was particularly annoying because I’m such a strong believer in progressive enhancement. I try to build my projects with the basics first, then layer on the more sophisticated bits. That usually makes legacy browser support easier, if not trivial. The fancy stuff typically doesn’t render or get in the way, and foundation-level content still works in the accounting department’s crusty old browser of choice. But not this time.

Specifically, jQuery was going a little nuts trying to traverse the DOM in IE8 or older, returning weirdly inconsistent results. Here’s a sampling of some queries and their pass/fail results:

  • $('footer[role="contentinfo"]') = failed
  • $('div[role="contentinfo"]') = worked
  • $('div[role="contentinfo"] nav') = failed
  • $('footer') = worked

After doing a few reductions I found the issue, and it wasn’t at all what I expected: inline SVG. Specifically, there are two components of inline SVG that seem to scramble legacy IE’s brain:

  1. The XML namespace attribute: Removing the xmlns attribute from svg elements (or simply setting its value to “ ”) returns sanity to the DOM. Interestingly, related attributes such as xmlns:xlink don’t have a similar negative impact. Only the default namespace attribute causes this behavior.
  2. Self-closing elements inside inline SVG: The presence of self-closing child elements in inline SVG (like <circle /> or <path />) consistently triggers this issue in IE8 and lower. This one also has an easy fix. Simply change self-closing child elements in your SVG to have a separate closing tag. So instead of <circle />, use <circle></circle>.

Update: Both Fixes Work

I’ve updated this post to reflect feedback I’ve received since it was initially published. Tab Atkins responded on Twitter to point out that xml attributes should be ignored by the HTML5 parsing algorithm in modern browsers, so they can be safely removed. That means both methods are viable options for bulletproofing your inline SVG, allowing it to degrade gracefully in older versions of Internet Explorer.