12 things I learnt from our developer’s blog about building Ampp3d

A while back Ampp3d’s developer William Turrell posted a long technical look at how we built the site in just eight weeks a long ongoing process of technical refinement over six months and counting.

It is essential reading if you work in web product management or design. Or want to. Here are the key points I took from it…

1. Mobile-optimised development is even harder than I thought

It’s tough making all of Ampp3d work on the phone, both editorially and technically. Screen-sizes. Orientation. Pixel aspect-ratio. Pixel density. Testing across multiple browser and in-app across multiple operating systems on multiple devices. A pox on all your houses, sir. A pox on all your houses.

2. Infinite scroll is harder still

Will reckons we’ve made more effort than probably anybody else in insisting that everything, including our interactives, work as part of a continuous scroll experience. Unless something has gone badly wrong, you should never see pagination on Ampp3d. But blimey, he reveals that has been hard work behind the scenes.

3. I realised that Will and I only met twice during the project

Compare that to how many meetings YOU have. But – big caveat – there’s a huge amount of trust that has grown between us. I don’t need to check in on him because the stuff has always been good. He doesn’t need to constantly meet me because I’ve tried to devolve technical decision-making as much as possible, and not be an annoying stakeholder with technical “opinions”. Unless, y’know, I have to because REASONS.

4. Ampp3d was a really bad name choice

Development got delayed briefly at one point because Will had mistyped it in a server config. If I could have my time over again…

5. #YourBossIsAnIdiot

This is a joke hashtag internally we have to reference every time I’ve done something disorganised or stupid on the project.

Or broken my arm.

Or when I’ve commissioned a massive relational database to put in any sort of number we’ve ever used. And then never used it. See Will’s estimate of the number of numbers stored in “the great big database of numbers.”

6. We used some open source stuff from the FT

Thanks FT Labs!

7. If we put “Do not publish” in a headline…

…Will has customised WordPress so that the publish button is deactivated. It’s genius.

On some other CMS interfaces, you’ll find the “Publish” button is right next to “Preview”. That most certainly isn’t genius.

8. Burn all ads

The performance of ad-servers, especially on mobile, is a drag on site performance. That basically makes Will howl into the void in despair. I’d love to be able to quantify “tiny amount of incremental revenue” versus “people who hit back button because ad-loading JavaScript zzzzzzzzzzzzz”. Sorry ad-ops folks.

9. We are still all rubbish about accessibility

Will’s section on what happens to the site if JavaScript isn’t running has made me feel ashamed that we’ve put up some totally inaccessible types of story-telling during the project so far. And alt-tags, <noscript> etc are unfairly the first casualties of “production in a hurry.”

10. We’ve been very happy with Bytemark’s hosting

Thanks Bytemark.

11. 1,000x this

Will absolutely nails every product manager’s experience:

“Despite my pride in what we’ve made I still can’t look at the site without noticing all it’s flaws or thinking about the many compromises we’ve had to make.”

12. Oh how I wish I had more of these

Imagine if you, as an editor or product person, got feedback like Will’s blog post on every product you’ve ever worked on. I’ve been in this game for 15 years now, and I still make editorial and design decisions with massive technical implications almost without realising it. Will’s post is a key reminder that PERFORMANCE is just as much part of the user experience as DESIGN and CONTENT.

13. Don’t take my word for it

Put the time aside to read Will’s post. Seriously. If you’ve got any kind of job in design, editorial or product for the web, you’ll learn something.