Twenty Years of Mobile First, and I Built Mobile Last

Altitude: learning from my mistakes

Someone used the Atlantikwall archive on their phone, didn't get on with it, and asked whether we could put the old site back for mobile.

Not a bug report. Not "this bit is broken". A request to roll back to the thing I had spent months replacing, for the device most people would actually use it on.

What I have been telling people for years

Design for the small screen first. Not because phones matter more, though they do, but because the constraint is useful. A narrow screen forces you to decide what the page is actually for. You can't defer the hard call about hierarchy when there's only room for one thing at a time. Start wide and you never have to choose; you just keep adding, and the phone gets whatever survives the squeeze.

I have said that in workshops, in design reviews, in kickoffs. I have pushed back on comps that opened at 1440. I have been, on this specific point, slightly tiresome for a very long time.

Then I built my own site. I built the desktop layout, made it responsive, and let mobile fall out of the process.

Responsive isn't a design

That's the sentence I'd been quietly relying on without examining it. Responsive is a rendering behaviour. It means the layout doesn't break when the viewport narrows. It says nothing about whether anyone decided what the page should be at that width.

I ran a proper mobile review in early September and wrote up everything I found. Reading it back, it isn't a list of separate problems. It's one problem, presenting over and over.

The browse page carried two competing navigation systems stacked vertically: a collapsed accordion holding the country and region tree, then immediately beneath it an unrelated row of All, Recently Added, Recently Updated, Popular. Two ways of narrowing the same set, shown as siblings, with no hierarchy between them and neither reading as interactive. A visitor had to work out from typography alone that one was a place hierarchy and the other a sort order. At the top level the page showed no locations at all. Below that, results stopped dead at twenty-five.

The hero band dominated every page. The tab bar was missing on most routes. Images weren't responsive, so phones pulled desktop-sized files. Tapping an input on iOS zoomed the viewport and broke the layout. The newsletter signup couldn't be dismissed. The map fought the page for scroll.

My own ticket for the rework puts it more plainly than I would have dared: the mobile branch is a reflow of a desktop layout rather than a mobile design.

Every one of those is what happens when nobody makes a decision at 375 pixels. The accordion and the tab row don't compete on a wide screen because there's room for both. Oversized images don't hurt on a laptop on home broadband. None of it was a mistake exactly. It was the absence of the choice I'd spent years telling other people to make.

Why knowing better wasn't enough

It would be comfortable to call this an oversight, and it isn't. I knew the principle, I could have recited the argument for it, and I had personally corrected other people for the same thing.

Two things I think were actually going on.

The first is that advice you give costs nothing and advice you take costs a fortnight. Telling a team to start at the small screen is free. Doing it yourself means building the hardest version first, when you're least sure what the product is and most want the reassurance of something that looks finished. Desktop gives you that reassurance faster. I took it.

The second is that working alone removes the person who would have said something. On any team I've run, someone opens the thing on their phone in the first week and mentions it in a standup, and that is the entire mechanism. It isn't a process, it's just other people having phones. Solo, the first person to open it on a phone was a user, and what they said was: can we have the old one back.

There's a version of this post that blames the tooling, and it would be partly true. Everything I built and tested and demoed was on a laptop. But the tooling only ever reflected the decision, which was mine, and which I'd made by not making it.

What I'm doing about it

The browse rework has shipped. The rest is working through, and there's plenty of it.

The correction isn't the tickets though. It's that mobile has to be the surface I build in rather than the one I check afterwards, which means the default viewport for building, reviewing and screenshotting is the phone, and the wide layout is the adaptation. That's the thing I've been advocating since before responsive design had a name, applied for the first time to a project where nobody else was going to make me.

The performance side is its own reckoning and I'll write about that separately. But it's worth noting that a location page was taking 12.8 seconds to render its main content in a mobile lab test. The person who asked for the old site back wasn't making an aesthetic complaint. They were describing something that genuinely didn't work.

They were also right, in the narrow sense that mattered to them on that day. The old site was better on a phone. It was worse in every other respect, and it was better at the only moment that counts, which is when someone is actually trying to use it.