Home page of Newsweek.com, May 31, 2010

I don’t know when it happened, exactly, but Newseek.com was recently redesigned. There is so much to say about it, and it is mostly good.

I’ll start with the most obvious: the design.

In short, the home page is easy to scan. There is a clear visual hierarchy. The lead photos and articles have been spot-on for Memorial Day news items, and the clarity of the layout made certain I couldn’t miss them.

The article pages are easy to read and keep enough of the patterns, like the byline and publication date, that it’s easy to figure out what’s what.

My biggest complaint is one that they no doubt haven’t figured out how to get rid of yet: the banner ads.

There’s more talk about the visuals for the new newsweek.com at nymag.com. I won’t go on about that, myself, other than to say, gee, it looks like a professional blog. Oddly, that’s a compliment.

Now let’s look at the markup.

Newsweek.com's namespaces point to interesting uses of meta data.

I’ve had a penchant for information architecture since the late 1990s, and about the first thing I noticed when glancing at the markup for the home page is the references to the Dublin Core meta data definitions and other meta data sets.

I was suddenly intrigued. Good use of meta data is sadly absent in many large-scale websites, and it’s really great to see an effort to play the game for real.

So, at a quick glance through the markup you’ll notice some unusual pieces, first this:
data-track="{'title':'stories being discussed'}", which is an attribute with a value that looks a bit like JSON.

I admit to being behind the times with studying HTML 5, but that attribute spurred my suspicion that this page was using HTML 5. I stopped wondering a few lines later when I spotted an article element, followed soon thereafter by a header element, and a nav element sporting an attribute of role="navigation". Whoa. Newsweek jumped right in.

So what about the meta data? Well, I can’t really know what they’re actually doing, but here is an observation. In a sidebar, they have a list of quotes. Each quote is marked up as a blockquote with an id attribute. Following each quote is a span with attributes like property="dc:creator" and about="#q1". The about attribute refers to the id of the blockquote in question. The content of that span itself is the name of the quoted person, plus which publication the quote came from.

Pretty cool idea: internal markup references like this can build relationships into the content. It could provide some interesting opportunities for parsing later on. Yeah, that’s right, the semantic web.

The problem with this all is…it’s half-baked!

Newsweek.com used "http-equiv" when they needed "name". Oops.

That list of quotes with the ID attributes? All that meta data is duplicated and thereby meaningless! Further, why use a span element when they could have used a cite element? More semantic and those attributes would’ve played as well. Gah!

And back at the top of the markup by those meta data namespace references there is another set of meta tag elements which are sadly marked up incorrectly.

There is a stack of 5 meta elements that use the http-equiv attribute when they should have used the name attribute. I’ll bet whoever coded that knows the difference, but I wonder if they were rushed to get this version out. It feels like a beta.

They are so close to providing some really great examples of meta data use in HTML 5! I hope they release another version soon that gets more precise and cleans up some of this code.

The Vignelli map smartly acknowledged that for passengers of the subway focused on navigating the subway system itself, above ground geography was nothing but a factor of added complexity. So the map instead was oriented around the subway lines and stops themselves, abstracting actual geography. This was a keen simplification from an information design perspective.

But consider this observation from Bierut’s article.

To make the map work graphically meant that a few geographic liberties had to be taken. What about, for instance, the fact that the Vignelli map represented Central Park as a square, when in fact it is three times as long as it is wide? If you’re underground, of course, it doesn’t matter: there simply aren’t as many stops along Central Park as there are in midtown, so it requires less map space. But what if, for whatever reason, you wanted to get out at 59th Street and take a walk on a crisp fall evening? Imagine your surprise when you found yourself hiking for hours on a route that looked like it would take minutes on Vignelli’s map.

The concept of designing the seams between systems has become apparent within the user experience design community over the last couple years. This is an example of that problem of seams.

Passengers of the subway system are also navigators of the city itself, so their context of use spans beyond the subway and the end of their decisions are not merely which stop to get on and off of, but where they are going once they get out of the subway.

Bierut makes the point:

The problem, of course, was that Vignelli’s logical system came into conflict with another, equally logical system: the 1811 Commissioners’ Plan for Manhattan.

How can designers consider the seams between the subway system and the city plan to result in a better-designed subway map?

NYC, of course, has a functioning subway map. Is functionality the only litmus test?

(I’ve taken the subway in New York City only once, and managed to get from Point A to Point B successfully, although with some anxiety.)

Please, take the 18 minutes to watch it, then continue to read.

Watching this talk brought to mind two thoughts related to user experience work.

First, in a recent edition of Interactions magazine there is an article “Stories that inspire action” by Gary Hirsch and Brad Robertson, that has planted the desire in me to uncover the stories of the company I work for, Covenant Eyes. There are so many ideas we have of ourselves, set by the expectations of management, employees, and so forth. But there are also stories of our customers, and by telling many of these stories, I suspect we will hear some stark contrasts that will cause us to reckon with ourselves.

Have we stereotyped our corporate self?

The second thought is in regards to personas. At Covenant Eyes, my colleague Jackie has taken the lead on creating a set of personas that we can use during our design and development work. This is a first for us. This week as we were reviewing the current set of about 16 personas, we were working on writing in various scenarios for each persona. I think the point of each scenario is to enrich the story of that persona.

But perhaps more important is that across the full set of personas, however large it may get, that we have properly balanced the stories that are represented by each persona. I think, at its root, that is part of why personas are valuable in the first place. To challenge the stereotype, the single story, that we might have in development about our “user.” These personas will be valuable if they can help us tell the many stories of our customers and users.