Under the Surface of the NYT Mobile Redesign
A new semi-responsive design, Node.js, and more
Last week, the New York Times released a new mobile version of its website with a clean, quiet reading interface and a typographic style that’s increasingly visually connected to other incarnations of the Times. A member of the team also hinted in a handful of tweets that the new site included plenty of interesting code choices as well:
@yurivictor in all honesty, it’s probably the Varnish caching that’s the biggest speed benefit. But node doesn’t hurt, either…— Alastair Coote (@_alastair) May 1, 2013
We spoke with three members of the project team via email to learn what’s going on under the hood, how they selected and tested their front-end technology, and how they made the design decisions underlying the new view.
Q. What’s the mobile site made of? Various tweets suggest you have Node.js in there, and that you’re using CoffeeScript, LESS, Redis, and Varnish. Can you talk us through the whole recipe and how it all comes together?
Ian Gardner (Development Manager, Emerging Technologies): The tweets are very accurate. The core application runs on Node.js using the Express framework and dust.js templates to render the HTML. All code is written in CoffeeScript as it offers a slightly cleaner syntax that our developers prefer, and we use LESS for CSS. On the backend, we use Redis as a caching buffer between our node servers and the internal APIs that provide the content of our articles, slideshows, etc.
Finally, we have Varnish in front of everything. The main philosophy of the new mobile web was to be as fast as possible and this means caching as much as we possibly can. Node.js can be very fast but with some of our complex business logic, it will never be as fast as Varnish serving cached pages. Varnish caches the full html pages generated by the Node.js app and we use Ajax to add any user-specific details to the page. This allows us to not only drastically reduce the load on our Node.js servers but also allows us to set cache headers so proxies can cache the pages and reduce the distance a user’s request has to travel.
Q. It’s nice to see Node used well in such a high-profile project. What helped you guys make the decision to go with it? Did you take inspiration from any existing projects?
Q. Let’s talk about responsive design for a minute. How did you pick the breakpoints you’re using?
Andrei Kallaur (Mobile Designer): We designed and optimized the mobile site for the vast array of phones with varying screen sizes and pixel densities. We wanted it to still be a comprehensive reading experience if you happen to view it on a tablet or desktop. The max-width is 600px, which maintains a desirable number of words per line. Allowing the site to flow beyond that width would not be ideal for reading. The optimal browser experience for tablets and desktops will still be nytimes.com.
Q. Over at NiemanLab, Josh Benton noted that the typography and overall visual design of the new mobile site is feeling quite a lot like the Times’ mobile apps. Can you talk about the design choices you’ve made the and trade-offs behind them?
Kallaur: We did not intentionally make it resemble the iPhone app, but we did want to bring the mobile site in line with our other mobile products. Abandoning the blue link color on headlines, simplifying the layouts, and making everything visually stronger and crisper overall were some of our main goals. Soon we’ll be adding our typefaces, Cheltenham and Franklin Gothic, to the mobile site which will further strengthen the connection to our other products.
Q. Can you tell us what kind of testing (user, performance, device, etc.) you threw at the project during its various phases?
Michael Behr (Product Manager, Mobile): On the technical end, we did a lot of load testing, and took peak traffic days to make sure our site can handle breaking news events. We have an extensive unit testing framework consisting of several hundred tests. These tests are run on a continuous integration environment after every commit to ensure our codebase remains as defect-free as possible. We’ve also had an embedded QA team during the whole development process. Our QA tested against multiple devices—including Android, iOS, Blackberry, and Windows.
On the user front, we used quantitative and qualitative data from our current Mobile Website, other NYT mobile products, and in-depth user / persona research, which led us to prioritize speed, ease of use, and a cleaner news presentation.
Mobile Product Manager at The New York Times.
Development Manager, Emerging Technologies for the New York Times.
Digital Designer at The New York Times. Appreciator of @LaurenAWaterman, all things internet, cycling, skateboarding, trains, NYC, art & design.
Editor, Source, 2012-2018.