dev.joeblade.com

Go deep. Zoom out. All in one place. Some notes on the msnbc.com redesign.

Paul Haine — Sun, 04 Jul 2010 14:07:44 +0000

Last week msnbc.com relaunched their news story pages and I’m finding them pretty exciting. The heart of the redesign concept is the notion that in telling a story, all the different parts of a story — an article, a video, a gallery, a comment thread, etc. — are all equally valid and important. To express this, they’ve turned any msnbc.com story page into the canonical, one-stop source for every bit of media and reporting related to that story, instead of having one URL for the article, one for the video, and so on.

Here’s a decent example:

BP, feds too cozy for some in assessing damage
Company weighs in on decision-making in every key aspect

This story is being reported with an article, a video and a photo slideshow — these are referred to as ‘slices’. Each slice also has a ‘drawer’ underneath it to allow you to continue exploring that particular type of media, or expand the article if there’s more content to read. Part of the rationale behind this is to abandon the notion of pageviews, as Mike Davidson explains here. Adverts are integrated into the general flow as slices in their own right, breaking up the content but not getting all in your face about it.

Pages vs packages

At the guardian we have the notion of a ‘story package’; it’s the same concept that msnbc are playing with but it’s simpler. Pieces of content — articles, galleries, videos, etc. — are editorially linked together in the editors’ tools and then every bit of content provides links to everything other bit of the same package. You can see it in action here, on the story about Michael Jackson dying.

It’s more flexible in some ways than msnbc’s approach and allows the editors to thematically link a much larger number of items — the Michael Jackson story package all on one page would be enormous, and the commenting model wouldn’t work; at guardian.co.uk you generally comment on the piece of content, not on the overarching story. In the case of the Jackson package there are several opinion pieces, each with a different slant on the story, each with their own discussion thread. This allows for a far more intimate dynamic between commenter and author, but does also fragment the discussion of the story. Swings and roundabouts.

One advantage to a story page rather than a story package is that more people may explore more aspects of the story if they’re presented in the same space. It’s very easy to quickly browse a gallery or watch a video if it’s immediately after an article and all you have to do to reach it is to continue scrolling.

Navigation

To explore the story page there are several floating icons that allow you to jump straight to slice you’re interested in, including links to the discussion thread and the ‘related content’ area at the foot of the story. These are pretty cool; essentially they’re a jazzed-up modern version of the ‘skip to content’ links that we’ve been peppering our sites with for a few years now except they’re not just for assistive devices, they’re for everyone, and they work pretty well. They always position themselves relative to the length of the page (though this might also work against them — as a user, I may find them easier to use if I always know where they’re going to be).

Their video player features both subtitles and transcripts which is a big usability and accessibility win. I rarely watch videos on sites because it either involves me getting headphones out if I’m in the office or turning down my radio if I’m at home, so subtitle support means I’m far more likely now to explore their video content.

The entire design is extremely polished; it feels like a finished product, very complete and lots of nice touches. It’s like playing a Nintendo game — I keep finding little secret bits and pieces like the hidden headlines at the very top of the page. I love every bit of their photo galleries. I love their timelines, visible on this story. There’s a Newsvine discussion about the redesign and predictably, most of the commenters hate it. In my experience, this means the team behind the redesign have done something worthwhile, and they should feel very proud of themselves.

Some niggles

If JavaScript is disabled, you lose a lot of functionality. Photo slideshows no longer work at all, for instance. Visitors without JavaScript enabled are a small minority these days but nevertheless, some more graceful degradation would be nice.

There doesn’t appear to be any way in referencing a particular part of the story. If I want to send someone a link to the video for instance, I don’t think I can — I have to send them the story link and tell them to find the video. It would be nice if there were per-slice permalinks for this purpose.

The video player is in Flash so I can’t watch videos on my iPhone. There does seem to be a mobile version of the site so maybe I’m just looking in the wrong place, but as MobileSafari is a fully-featured desktop browser, I generally resent being carolled into the cut-down mobile site.

A short article about short links

Paul Haine — Sun, 06 Jun 2010 18:23:25 +0000

In which I briefly note how you can use the Guardian’s own short URLs for our content pages: A short article about short links

Joeblade now using HTML5

Paul Haine — Mon, 31 May 2010 15:31:05 +0000

I’ve reworked joeblade.com to use new HTML5 elements in favour of generic divs:

,

and

The structure I’m using is more or less as follows:

You can view the source code for the full story. The first

is there to contain the masthead, and that’s all it does for now. The

is for ancillary information about the main article and its category: related posts, tags and other posts from the same category. The

is obviously the main bit of content on the page.

The second

, within the

, contains the post headline and the byline. The byline contains the element for the publication date, amongst other things.

The

Custom attributes in HTML5: data-* and dataset

Paul Haine — Sun, 09 May 2010 15:47:52 +0000

Coming up with a proof-of-concept link tracking mechanism for use on guardian.co.uk led us to the ability in HTML5 to create custom attributes for storing metadata on directly on an element.

Preamble

We had to provide some information somewhere in the page markup about the tracked component so that some javascript could then append that information to the href attribute value as a query string. For some non-technical reasons, we had to have this info in the query string and for SEO reasons we didn’t want to just have it appear in the raw href — hence the javascript.

One way of proceeding would have been to hide the information (for this initial stage, just a unique, numerical ID) somewhere near the link, perhaps like this:

id-45 This link will be tracked

What then? With javascript you could traipse back up the DOM to find the nearest span element with a tracking-code attribute, get its content, reformat it and then tag it on the end of the anchor’s href, but that’s all pretty clumsy and you run the risk of those values appearing to the end user.

So, we decided it made sense to include the information directly on the element. First we considered the name attribute:

This link will be tracked

This is neater, but the name attribute is deprecated on anchor elements so it didn’t make sense to implement a new feature with it. We flirted briefly with the idea of hijacking the little-used rev attribute just because I was reasonably sure it hadn’t been used across our site for anything else. But this didn’t sit well with us as, little-used or not, this wasn’t an appropriate use of the attribute. We didn’t want to use the class attribute for similar reasons. It didn’t feel quite right, and would have been marginally more complex to parse as we’re already using it heavily for styling purposes.

So, we turned to custom data attributes:

This link will be tracked

From there, a simple bit of jQuery extracted that value and appended it as a query string to the href on page load. A downside to this mechanism is that to the user, all this is visible as cruft at the end of the URL in their browser but as I said above, there are non-technical reasons for us approaching it in this manner that I won’t go into here. So that we didn’t break SEO, we use canonical data on every page.

Custom data attributes

A custom data attribute is an attribute that begins with data-. As described in the spec, they exist “to store custom data private to the page or application, for which there are no more appropriate attributes or elements” so they were basically exactly what we needed. They’re easy to access with javascript:

var data = document.getElementById("a").getAttribute("data-track");

The HTML5 spec also refers to a dataset object that returns a map of name/value pairs:

var data = document.getElementById("a").dataset.track;

No browser support for that yet, though there is a jQuery dataset plugin.

You can also style them, should you need to:

a[data-track] {
	color: red;
}

Is it safe?

Browsers are supposed to ignore unrecognised attributes, so there’s little risk that this information would ever appear on the page in a broken fashion. From a more philosophical view, it’s not ideal mixing up your data with your markup — it feels like it breaks the model of separating concerns, but then we also use the occasional inline style attribute as well (sometimes it’s just the right tool for the job), so I’m happy to be pragmatic about things.

Update 12 May

The query string will now be appended on the onclick event, not on page load, to further minimise exposure to robots and people. So it’s only visible by examining the URL in the browser’s address bar after the target page has loaded.

Design changes to joeblade.com

Paul Haine — Sun, 21 Feb 2010 20:07:44 +0000

I’ve reworked joeblade.com over the last couple of weeks, trimming it down to just the essentials. Here are some details about why.

Though I liked the wide version of the site, in particular the large masthead images that accompanied many of the posts there, it left me with a lot of space to fill outside the articles. I attempted to fill this space with adverts, and with links to previous posts, latest comments, the usual malarky.

The problem with the ads was that a) they were ugly and irritating and b) nobody ever clicked on them. I don’t blame them for this — I don’t click ads on websites either. I use an ad-blocker, so it was a bit hypocritical for me to include them in the first place, but the logic behind it was that a massive amount of my traffic comes from search engines, and it was an attempt to make a few pence off of the people that don’t hang around, but it never really worked — I think I made a couple of pounds over several months, which wasn’t enough to justify their inclusion.

As for previous posts, related content and all that jazz, this was part of an attempt to get people exploring past content. The site’s been running on and off for years and there’s plenty in the archives, but this didn’t really work either. Regular visitors didn’t need to explore the archives as they’ve read it, and new readers generally didn’t bother either, preferring to stick to whatever was new. Fair enough.

Finally, comments. I’ve been toying with the idea of disabling commenting for quite some time now, and with this version of the site, that’s done (though I plan to restore previous comments soon). There’s never really been a big, thriving, chatty community at joeblade and what I and the guest authors write doesn’t often lend itself well to debate. It’s also partly a reaction against the internet tendency to make everything commentable, even when it doesn’t make sense to do so.

When you enable comments, it alters your mindset a bit. You start worrying when people aren’t commenting, and you start trying to tailor your content to the needs of those that do comment just to try and get a discussion going. But joeblade isn’t really about that, and many of the sites I regularly read have a similar set up — lengthy articles and no commenting. I like this. It makes sense on a technical blog to have comments, so they’re staying open here.

So: the site is leaner, meaner and slightly prettier, using Typekit and wp-typography to make the content sparkle. Though all the above suggests a design failure, I’m not seeing it as such. The underlying architecture was strong, allowing me to make all my changes in under two hours, and I’ve learnt a lot technically as well. Not only that, I’m more comfortable with my own site: I’ve accepted that I have time to write for my site, or to spend ages designing and architecting it, but I don’t have time to do both to the extent that I’d like. As I have to choose, I choose to write.

Using CSS columns in print layouts

Paul Haine — Mon, 31 Aug 2009 11:55:04 +0000

I have a suspicion that print versions of webpages are a bit of a niche market. Nevertheless, they provide a reasonable testing ground for certain client side features that don’t get a lot of use in the screen medium.

For the print version of joeblade articles, I decided to use CSS columns. Here’s a screenshot of the on screen layout of my review of the film Moon:

(click for full version)

Here’s a screenshot of the print version:

(click for full version)

There’s a few things going on there, including some judicious use of text-indent, :first-child and a smattering of sibling selectors, plus the use of a serif font in place of a sans-serif (first choice is Goudy Old Style, followed by Georgia). The CSS for the two columns is simple:

div#article-content {
    -moz-column-count: 2;
    -webkit-column-count: 2;
    -moz-column-gap: 30px;
    -webkit-column-gap: 20px;
    font-size: 16px;
    line-height: 1.6;
    width: 760px;
}

Currently only supported in Mozilla and Webkit, and then only with the -moz and -webkit prefixes, non-supporting browsers simply get a wider, single column instead of two. A further limitation is that Webkit doesn’t actually support this in print mode (but it does in screen mode) but I’ve left the code in case it gets fixed in a future update.

You can see live examples at joeblade.com. It’s a bit rough around the edges at the moment, particularly when there are images or other media within the body of the article but I think for the most part it works pretty well. For instance, in this article on Ridley Scott and James Cameron’s return to science fiction, there are some images that span the width of the content. For the print version, I shrink them down to half their size and the content flows nicely around them. However, the captions look crap, so that’s something I need to fix still.

Specialist fonts with the @font-face rule

Paul Haine — Sun, 02 Aug 2009 19:04:54 +0000

Now widely-supported in the range of non-Microsoft-authored browsers, the @font-face CSS rule allows authors to specify a non-standard font within their CSS, pointing to the font file on their (or someone else’s) server.

At its most basic:

@font-face { font-family: "My Friendly Font Name"; src: url("/fonts/font-file.otf") }

a { font-family: “My Friendly Font Name”, arial, sans-serif; }

Used as above, the result would be that the client-side agent would download and use the font specified within the @font-face rule. For non-supporting browsers, there are some backup font selections.

The major issue with the above is one of copyright; placing your font online and referencing it within your code effectively makes the font publically available, and if you had to buy a license to use your font, you probably don’t have the right to re-distribute it for free. For this reason, it’s prudent to only use open-source fonts in this manner.

Using CSS to identify links to the iTunes store

Paul Haine — Sun, 02 Aug 2009 15:21:28 +0000

Here’s a thing I did in CSS, thought other people might find it useful. I kept on opening iTunes store links when I didn’t want to and I was too brain-dead to see the URL before hitting it. Adding the following code to your user stylesheet will append “(iTunes store link)” to any url that begins with http://itunes.apple.com:

a[href^=' http://itunes.apple.com']:after { content: ' (iTunes store link)'; }

Which results in this:

The Good Shepherd (iTunes store link)

Won’t work in IE but all other browsers should be fine.

So what is it?

The above code is an example of a CSS3 attribute selector, specifically a “substring matching attribute selectors”, and will match an anchor element with an href attribute, the value of which must begin with ‘http://itunes.apple.com’.

It then uses the pseudo-element ‘:after’ to target the area after the anchor element, and finally uses the content property to insert a space, followed by some helpful text.

Other substring matching attribute selectors are available

You can also match a value that ends with a named value by using this:

a[href$='.apple.com']

which matches any href value that ends with ‘.apple.com’, and you can match a value whose value contains at least one instance of the named value:

a[class*='apple']

which matches any anchor with a class attribute that contains ‘apple’ somewhere within it.