Some quick thoughts about the Guardian mobile redesign

I use the Guardian mobile site all the time, so I was intrigued by the new redesign. My initial response was not positive. It has some strange design decisions.

Fonts

Inspecting the page through an emulator reveals that the headline and standfirst text are the same font displayed in a different colour. The font is the Guardian's house face, Egyptian, in its Headline variant.

The headline font is embedded in the document as an inline style: this makes sense as it needs to be present at first render to allow the text to flow properly, but it does add 10kb to the page. A navigation font is included as an external file, despite appearing before the fold.

On an iPhone Egyptian Headline appears very heavy and doesn't alias as nicely as a system font, but I can understand the desire for a corporate font, especially for a newspaper.

For comparison, here's Egyptian Headline with the similar but less condensed Baskerville, which is an iOS system font:

Anti-aliasing on Baskerville (below) lightens quicker than Egyptian, giving a crisper look.

Usability

The main issue is what having the same font does for usability: the Guardian makes the same error as the BBC did when it relaunched news - only the headline and accompanying image is tappable. The standfirst text does nothing. There's no visual indication what what will happen when you tap on one part of the screen or the other (no affordance) so the user is expected to remember than black means tappable and dark grey doesn't. Especially as this situation is not true on subsequent pages: on those black is not tappable - blue is.

The BBC fixed this, hopefully the Guardian will too.

Images

I got caught in a low bandwidth area on my way in to work and was able to observe the way images have been made responsive on the site. Unfortunately, the responsiveness forces redraw, which is in my mind a worse sin than server-side detection.

These screenshots are from Chrome on an iPhone, so not entirely fair, but I've retested against Safari and there is still redraw.

On first load the page knows that it has to make a space for an image, but doesn't know how big:

Then the page tries to accommodate the largest scaling:

Before finally settling into the right size:

While this is happening, the actual navigable page is meandering all over the shop. 

This also leads to some weird renderings:

Matters of taste

I really don't like the section navs: they're finger sized and separated, which is good but the arrow positioning looks like the result of a float:left error.

There's another touch issue here: the word "Sport" takes you through to the section, but the grey bar it sits on doesn't. I'd favour a larger touch target.

Overall

I'll probably come to love it and moan when the next redesign comes along, but at the moment the redesign looks like a mixture of best practices (finger sized targets), overreach (responsive images) and poor usability (colours, inactive touch targets.)

Books, January

Trying to remember what I read in 2012 I realised it might be helpful if I kept a list. This years target is 100 books. I read 8 in January, which is slightly below target.

If the dead rise not & Field Grey - Philip Kerr

Two more from Kerr's Bernie Gunter detective/spy series about a mid 20th century Berlin detective who seems incapable of avoiding history's dark bits. The continuity can be a bit discontinuous, but it's a gripping series.

Gun Machine - Warren Ellis

I was hoping for something as gonzoid as Crooked Little Vein but he mostly plays it straight in this Thomas Harris-esque hunt for a serial killer in a very near future New York. So much so that when he does chuck in an Ellisian flourish the effect is jarring rather than exciting.

Dracula Cha Cha Cha - Kim Newman

Latest piece of the alternate history with Vampires series. This one genuinely quite sad, and I got the feeling I hadn't watched enough Euro horror to pick up on the references (although there are footnotes)

London Under - Peter Ackroyd

Short and poetic extension of Ackroyd's London work to cover vaults, sewers and the Tube. Left me wondering if I use the same line to commute to work as Peter Kropotkin.

House of Rumour - Jake Arnott

Arnott squishes together Scientology, the OTO, Jack Parsons, Ian Fleming, Rudolf Hess, The Blitz club and west coast sci fi. And the CIA. And Jim Jones. Could have been a lot bigger, and lost coherence towards the end as it tried to bring all the strands to some sort of conclusion, but a fantastic weave through hidden worlds. Oh and Borges gets in there.

And Pynchon.

Instant: A Cultural History of Polaroid - Christopher Bonanos

From polarised headlights to Lady Gaga. The tragedy of Edwin Land. Not a Polaroid gear porn book, and all the better for it. Sadly does not address the "42% brighter" claim.

Absurdistan - Gary Shteyngart

Shteygart's big Russian novel. Funnier and wiser than Super Sad True Love Story. 

HTML as a screen drawing API

I was talking with a colleague before Christmas about the idea that, when viewed from Javascript, HTML is just the API you call to draw to the screen[1]. Which got me thinking: if HTML is a screen API, how good is it?

Before I begin to break it down (tl;dr - it isn't a very good API) it's worth remembering that HTML has been (almost?) explicitly designed not to be a screen rendering language. The W3C values semantic description over visual representation. So this shouldn't be taken as a criticism of their competence, just their architectural choices.

The most important aspects of an API are orthogonality (it doesn't repeat itself), predictability (given an API call, I can figure out how to use it) and terseness (you don't need to perform obscure ceremonies - think Java boilerplate - to get where you want to go).

HTML-Screen's chief weakness is in orthogonality: there are so many elements that do the same thing when rendered to screen. There are specialised elements like the form controls, but the two biggest chunks of HTML consist of things that define a rectangle onscreen that can have things in it, and things that denote a range of text that can have some visual styling applied to it.

There are subtle visual differences between <p> and <div> - most user agents render <p> with a bit of extra bottom margin, but fundamentally they play the same role. HTML 5 adds yet more rectangles: <section>, <article>, <aside> etc. These all have semantic meaning, yes, but reduced to pixels, they're rectangles. The inline text markers are worse: HTML 5 even preserves the <b>, <i>, <em>, <strong> group.

Even if we're adhering to the semantic route there are simply two many options, which means that simple stereotyped content (news stories, say) on one site are guaranteed to be built in a different way on another, which means that if you want to merge or reuse content you still have to write an adaptation layer to munge them together. 

Predictability is improving - you can probably work out what the <section> and <article> elements do, but older HTML elements which are still part of the standard are cryptic - if you didn't already know there's no way you could work out what <a> is for, or <dd>, <dl> etc.

The area HTML triumphs, of course, is in its terseness. This is a valid HTML document:

<body>Hello</body>

There's very little effort required to make a page and make it it link to another page. Provided you don't care what it looks like. 

If you do care then you quickly find yourself suffering from the number one problem caused by the fact that HTML was not designed as a screen API: none of the bloody browsers agree what it should look like. The lack of a set of visual compliances for HTML means that browsers are free to interpret raw HTML however they want. To achieve a consistent look you have to specify everything in CSS (with the odd Javascript shimmy thrown in) and even then you may be defeated. 

My feeling is that the semantic project is worthy, but misleading. We've had 20 years of semantic led markup development, and reuse on the web still starts with writing a web-scraper (I've done it myself over and over). 

I'd like to have the option to forget about semantics when developing and simply concentrate on making things look the way they should, if the content I'm trying to present is free of semantic reusability (and given I work in web advertising, that's a given). But I'd like the tool I use to support that approach rather than fight it. 

1. Yes, technically it's the DOM, but HTML gets written nonetheless.

Bye Josh!

Nephew Josh, now back on his way to NZ. From my Flickr stream

On problems

I like the soft popping noise a problem makes when it gives up its mystery. It's like the  interlocking ring puzzles that come the better class of cracker. You sit on the sofa full of Christmas surrounded by adults comparing holidays with these mysteriously entwined rings, turning them and trying to squeeze one through the impossible diameter of the other until a distaff twist ... and they're separated in your lap.

I wish that programming were full of problems like this: in truth they're the exception. Coding problems fall into three categories, of which these are the nicest, best rounded. They're the Miss Marple mystery of coding problems: it had to be the Vicar, because only he could have had access to the greenhouse's poison cupboard and knew that Anaconda venom was poisonous because of his time in Peru!

The second category is the "well, I can kind of see how you get from here to there" problem. This is the majority of coding work. You know roughly what the solution will look like, but you don't know if the answer is right until you've built half of it. And by the time you've built half of it, the end is nearer so, even though it's not the best route, you carry on coding until you're halfway there again, and you can stick your head up over the maze and realise the end point is a bit over there now, so you code in that direction, and so on (at risk of ending up on a Zeno's paradox project.)

It takes a brave developer to admit that the last half-effort took them slightly off course, especially when management sees that you're making progress. We called the last one Miss Marple: this is more like plodding police procedural - you get there in the end, but it's a slog.

The last category of problem is usually reserved for bug-fixing. Instead of the problem yielding to an elegant solution (Miss Marple) or simply getting less problematic with effort (Procedural), the problem actually gets worse as you look at it. This is usually symptomatic that you (or more likely the cockeyed bastards who put your legacy code together before your time) have accrued Eurozone levels of technical debt. No solution exists without making the problem worse for the next person to come across the code. Because of the complexity of the plotting, and the jaundiced view of your fellow man that wading through brittle type hierarchies and circular dependencies can induce, I'll name this the James Ellroy category of problems.

Over my career I think I've spent about half my time doing Procedurals and very nearly the other half doing Ellroys. The Marple problems have been few and far between. Perhaps if I worked in a language where the ratio of thought to code was higher (Haskell, say) more problems would dissolve into elegant compositions of Marples. But it's the Procedurals that pay the rent, and the Ellroys that build up system knowledge.

Getting hired through Linked In

I read this piece on hiring through Linked In and a little light went on in my head. See, I used to work for Deutsche Telekom with a job title of Senior UI Designer. Vague, and not actually descriptive of what i did. What that actually meant was that I was the front end guy who knew about making HTML, CSS and JavaScript work on mobile phones. "Designer" here means technical designer  (one step below architect) not a Photoshop jockey. 

And I had a Linked In profile. Despite developing a quite absurd level of expertise in my field I think I had one approach from a recruiter via Linked Ln who wanted to know if I could do Photoshop ("designer" ambiguity at work) in the four years I was there.

Then I started at Vibrant Media. My job title is now Senior JavaScript Engineer and I now get two or three direct approaches from recruiters a week. I'm happy at Vibrant, so this flattering but not actionable. (You can breathe out now, Sash).

What this means is that no matter how you dress up your skills and aspirations it’s your job title that hooks them in. Simple SEO works wonders. Recruiters are busy people and Linked In search is a blunt instrument. This also suggests two ways of gaming the system.

One is that you should massage your Linked In job title to match the job you want, not the one you have. The other is that if you're an employer and you want to keep your ninja/rockstar devs you should contractually oblige them to refer to themselves as PL/1 programmers or Mainframe Tape Operators.

Getting around the 31 stylesheet limit in IE

Internet Explorer 9 has a bug which means it can't process more than 31 top-level stylesheets. (This actually affects 7 and 8 as well, but people are really good about updating Internet Explorer, aren't they? What's that? Oh)

The problem comes from the way IE stores CSS rules. Each rule is referenced as a 32 bit number. The first 5 bits are the ID of the top level stylesheet the rule came from, and the last 12 bits are the rule. The 15 bits in the middle are @import references. You can chain @imports three levels down (so 5 bits each again), but only from those first 31 stylesheets.

Now, it might seem quite odd to want to link 31 stylesheets, but given the way sites are built up from 3rd party code it's not that uncommon. Where I work now we provide just such a third party service  (advertising) and our styles were getting ignored by the browser because there were more than 31 stylesheets above ours (we load all our stuff on DOMContentLoaded from a Javascript tag, so there's not much chance to fix the load order.)

I came up with a (what I think is a) neat fix for this. We simply copy the CSS into a JavaScript file as a string and load that, then append the that string to the cssText property of one the existing stylesheets in the page like so:

document.styleSheets[0].cssText += ourCss;


The browser now processes the CSS, without busting its 31 stylesheet limit. You can't use this to insert an @import however as that isn't strictly cssText, it doesn't get reprocessed.