Code

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.

All of our front end JavaScript code is also written in CoffeeScript and utilizes RequireJS to make things modular and more maintainable. This is all compiled and bundled into a single minified js file at build time to reduce the overall request size and number of requests. We also use the Dust.js templates on the frontend for some of our more dynamic pages.

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?

Gardner: Our decision to use Node was made quite a while ago. The development team responsible for the Mobile website is also responsible for the NYTimes web app which is also written in Node and has proven to be quite stable. The decision to use Node on that project stemmed from the fact that we have a lot of great JavaScript developers here at The New York Times and the thought of using the same language on the frontend and backend was very attractive. Another factor in the decision was to use a cutting edge technology to keep things interesting. Either application could have been written in PHP or Java or any number of languages (especially considering Varnish is in front of it) but Node is new and interesting, which is attractive for developers.

Design

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.

Testing

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.