Panel

• Eitan Konigsburg (twittergithub)
• Alastair Coote (twitter github blog)
• Reed Emmons (twitter)
• AJ O’Neal (twitter github blog)
• Jamison Dance (twitter github blog)
• Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up)

Discussion

02:06 - Introductions

• New York Times 03:17 - The Mobile Site 05:18 - The Desktop Site vs The Mobile Site 07:28 - Technology at the NYT 08:17 - Tooling 10:40 - Responsive Breakpoints
• Modernizr 12:41 - Incorporating JavaScript
• MVC Frameworks 15:40 - User Experience and Decisions Made for the Redesign 20:08 - Frontend/Backend 21:20 - Tracking Behavior/Performance 23:05 - Learning from the NYT Redesign
• Varnish 27:59 - Development Process 30:37 - Interactiveness
• Touch vs Keyboard & Mouse
• Big Screen vs Small Screen
• hammer.js 34:57 - Accessibility 39:10 - Performance
• Varnish 41:13 - Node.js42:49 - Open Source 44:29 - Resources
• Times Developer Network
• Code - Open Blog - NYTimes

Picks

• James Mickens: The Night Watch (Jamison)
• Ball Park Music (Jamison)
• Bacon Ipsum (Chuck)
• Audible (Chuck)
• The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses by Eric Ries (Chuck)
• Jake Archibald: JavaScript Promises (Eitan)
• High-Performance Browser Networking by Ilya Grigorik (Eitan)
• Polymer (Eitan)
• Firefox Nightly Builds (Alastair)
• Pocket (Alastair)
• Scouting NY (Alastair)
• CodePen (AJ)
• Mockingbird (AJ)

Next Week

BonsaiJS with Tobias Reiss

Transcript

[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]  [This episode is sponsored by Peer60 Incorporated. Peer60 Incorporated knows that the best JavaScript developers hone their skills by listening JavaScript Jabber podcast. If you’re looking for a frontend or full-stack development opportunity, helping Fortune 100 companies understand their customers better, email jobs@peer60.com.] [Do you wish you could be part of the discussion on JavaScript Jabber? Do you have a burning question for one of our guests? Now, you can join the action at our membership forum. You can sign up at JavaScriptJabber.com/Jabber and there you can join discussions with the regular panelists and our guests.] CHUCK:  Hey everybody and welcome to episode 93 of the JavaScript Jabber Show. This week on our panel, we have AJ O’Neal. AJ:  Coming at you live from the snow. CHUCK:  JavaScript [laughs] JavaScript. Jamison Dance. I am having a day today. JAMISON:  I like my nickname. AJ:  JavaScript. JAMISON:  Jamison “JavaScript” Dance. Hi friends. CHUCK:  I’m Charles Max Wood from DevChat.TV. And this week, we have three guests. We have Eitan Konigsburg. EITAN:  Eitan, yeah. CHUCK:  Eitan. I only slightly butchered it. EITAN:  It was close. It was a good effort. CHUCK:  We also have Alastair Coote. ALASTAIR:  Yeah, that one’s dead on. [Chuckle] CHUCK:  And Reed Emmons. REED:  Hey, guys. I’m actually going to leave all the talking to Eitan and Alastair. [Laughter] CHUCK:  Depending on what your expertise is, that may or may not be a good idea. [Laughter] CHUCK:  I think I saw Manager in your title. So I’ll leave it up to them whether or not that’s a good idea. But yeah, so do you guys want to introduce yourselves really quickly? ALASTAIR:  Sure. So yeah, my name’s Alastair Coote. I’m a developer here at the New York Times and I work on our mobile web products, which mainly consist of our mobile website and also a web app we recently launched called Today’s Paper. EITAN:  And I’m Eitan Konigsburg. I’m a frontend software architect here at the New York Times. We just completed our major redesign of NYTimes.com. CHUCK:  Awesome. JAMISON:  Which I’ve seen getting really positive reviews. I don’t think I’ve seen anyone complain about it. That seems to be the bar of success for redesigns, right? You redesign and no one freaks out. EITAN:  Yeah, that’s also I think what Slate wrote about how nobody was enraged that we redesigned our website. CHUCK:  So, Reed really is going to leave all the talking to you guys. [Laughter] CHUCK:  Which of you is going to say, “Hi I’m Reed and I’m whatever”? [Laughter] REED:  I better jump in here before I get myself in trouble. [Laughter] REED:  So yeah, my name’s Reed. I am the manager of development for the redesign here. And so we’ve been charging ahead for a long time doing this redesign stuff. That’s who I am. CHUCK:  So, when you’re talking about making it mobile-friendly, did you actually redesign it to have responsive design? Or was it more along the lines of actually reworking certain aspects of it so you hit it with a mobile device and it loads a different page or what? EITAN:  It’s actually all the same page. We have a number of break points at different sizes that apply to different devices, although we basically go down to a tablet size on the low end and very, very large widths on the high end. But it’s not fully responsive to any size. So actually, Alastair can tell you that we do serve the mobile version of our website to phone and small devices. And that’s a whole separate application. But the NewYorkTimes.com, the actual I don’t know what to call it, the desktop website does apply to tablets and it is all the same code running on different viewport widths. CHUCK:  Okay. ALASTAIR:  So yeah, the mobile website is a quite separate beast, which was done deliberately because it really allows us on the mobile end to optimize things for mobile connections, incredibly small download sizes, that kind of thing. CHUCK:  So, are you talking about making images smaller? ALASTAIR:  Not just that, although partially that. We have all sorts. We have a huge number of different automated backend systems, one of which takes every image that appears on the site and provides us with a variety of different crops and different picture sizes and all that kind of stuff so we can pick out which ones are most mobile-friendly. But also it’s just an issue of dealing with the different strengths and weaknesses of the platforms, I suppose you could say. On the mobile site, we have to deal with people coming with a browser on Blackberry 4.6 or something like that whereas on the desktop site, they’ve got to deal with old versions of Internet Explorer. So it helps us to be able to separate our concerns like that. So the mobile site has to go all the way down these very dumb phone devices that would have held back the redesign of the desktop site if they’d had to do something similar to that. CHUCK:  Okay. JAMISON:  Do you have plans to try and port some of the redesign stuff from the desktop site to the mobile site? How does that work? ALASTAIR:  Yes. It’s interesting the way everything’s set up in that both the desktop site and the mobile site are all calling the same backend. So it’s not as if they’re two completely divorced, separate things. We have extensive internal APIs for getting actual article content and sections and all of that kind of stuff, so both of them are drawing from the same source. And one of the projects we’ve got coming up soon is really integrating some of the really interesting interactive features that we have on the Times and bringing mobile and desktop parity between those two, which is going to be an interesting challenge. JAMISON:  Yeah, I wanted to ask about that. So when I think of the New York Times, one of the things I think of is all the amazing visualization features you guy do and how much of that is ported over to mobile stuff and how much of it is desktop only? ALASTAIR:  These days, most of them are done responsively. The interactives are created within the news room and they will make stuff that scales down appropriately. And often, they all live independently of both the mobile and desktop site, but that’s what I think in the future, we’re hoping to bring them in and have everything integrated in one place. So yeah, that’s our next aim. CHUCK:  So, I’m curious. We’re talking about frontend stuff. You’ve done a lot of interactive stuff. The one that comes to my mind is during the election a year or so ago. They had all these numbers and states and counties and voting districts and all this stuff and it was all colorized. And as soon as new information came in, it updated. I understand that that was all done in JavaScript. ALASTAIR:  It’s actually not something we can speak to too well because it’s done, as we said, the news room has their own set of developers, some of which are even based in the bureau in D.C. who are right there in the thick of all the action. But from what I understand, particularly dealing with high-traffic events like the elections, there’s a lot of backend processing that’s just going to spit out that files. So in that respect, it scales infinitely which is one of the big concerns that we have at times like that. CHUCK:  That makes sense. Do you have a standard toolkit that you use for stuff like that? REED:  Actually, I just wanted to jump right in there real quick was I think there are two ways to look at technology at the New York Times. There’s the news room who’s really focusing on very reactive news events. And it’s the folks upstairs, we’re part of NewYorkTimes.com, we’re really building the roads. And people like interactive news are having parades on our roads. And so I always enjoyed that analogy. And one of the neat things about this redesign that I think we hopefully accomplished was we’re having parades on our own roads now. We’re doing some really fancy things with the article redesign. But a lot of those reactive, very news events are all handled by our news rooms and we just put the tools there in place to let them go for it. JAMISON:  Do you want to talk about some of that tooling that you guys do? What kind of infrastructure do you have built up to do things like that? EITAN:  They handle most of their data concerns and they basically deliver us an application in widget form, which is a challenge in and of itself to try and integrate an entire application into another one. The other interesting thing about it is they are considered content down in the news room and a lot of their stuff has to work for as long as possible, with browsers changing and libraries and frameworks getting out of date. It’s a real challenge for us to keep these things working for as long as possible when their [inaudible] application’s embedded within another one. JAMISON:  Oh, sure. EITAN:  We basically give them full reign over. They have a free form. They can basically put any HTML or JavaScript and style sheets that they need into their own container. They have access to any of our frameworks, any jQuery, Backbone, Underscore. They can include their own if they use D3 or any other library that they need to do their visualization, they can do that as well. We communicate some of our responsive breakpoints which are all done in JavaScript, not media queries. We communicate some of that to them so they can adjust depending on the width of the viewport. It’s a lot. It was a real integration challenge but it’s something we had never done as an organization before. And it actually has been really fascinating. And they’ve actually been able to contribute to our codebase, which is another milestone that we had never really had before. CHUCK:  Oh, come on. Everybody knows that those other developers, whoever they are, they just write crap, right? [Laughter] CHUCK:  If it wasn’t written by us, it’s crap, right? [Laughter] EITAN:  It’s a different development cycle for them. If something’s happening in the news, they got to build it and ship it within a day. And we can scrum and do agile and have sprints and take months developing something. And those two different cycles means that it’s a real challenge making sure that their needs are met in a timely manner. ALASTAIR:  I think a lot of the recent developments in frontend JavaScript help a lot in that sense. The last time New York Times worked at its redesign was years and years ago. And since then, just things like RequireJS and all of that kind of really making frontend JavaScript more modular and more pluggable really helps that kind of workflow a lot. CHUCK:  Yeah, I want to hark back to something that you said earlier. You said responsive breakpoints. And we talked a little bit about that when we were talking about the mobile design and things. But then you said that you handle it all in JavaScript so it’s not media queries. How are you doing that and what’s the difference? EITAN:  Well media queries, it requires support going back to all the browsers that we have in our supported browser list. And a lot of our users come in with older browsers that didn’t have enough support for what we wanted to do. JavaScript also, it gives us a chance to use an event-based system when the viewport changes. And we also have to know what the viewport size is in order to choose the right image size because there is no great browser solution for choosing the correct image to download. And so doing it all in JavaScript basically met all of those needs. And it was more than just applying the right styles at the right size. It had to do with integrating with a lot of the features and layout considerations that we had for the page. CHUCK:  So, are you doing stuff with Modernizr for that? EITAN:  Modernizr gives us a lot. We do use it. But we don’t use any of the polyfills. We really only use it to detect the feature set of the browser. We wrote our own framework to do responsive breakpoints. And basically it also had to run outside of the rest of our RequireJS and MVC frameworks so that it was available on the window and we can actually listen to all the events and react accordingly. And it’s a pretty neat system. And we also did it in a way that it was additive. So smaller breakpoints, all the breakpoints are class names on the HTML tag and all the breakpoints that are smaller than the one that you’re currently are included as well so we can do an additive CSS as opposed to defining the entire layout for each breakpoint. CHUCK:  Okay. EITAN:  If that makes any sense. You can have sub-grids basically, because on LESS, they only care about changes at certain widths and then they can react accordingly. JAMISON:  So, you brought up a point when you were talking about all the responsive stuff that you were doing. That brought up a question in my mind which is, in my mind the New York Times is one of the classic document-based websites where you go in between resources, you click on a link, and it takes you to a page that just renders some text and stuff. Maybe there are islands of interactivity in there, but you mentioned JavaScript MVCs. How much are you doing in JavaScript and how do you balance that with what seems to me like more of a traditional page by page web application? EITAN:  So, it’s an interesting question. What we do is we have all of our news data in a CMS and it’s available over an API. So what we can actually do is we can render some static markup and cache it for a really long time because we actually do a lot of really interesting things mostly in JavaScript on our new website. And we use MVC frameworks basically to organize our widgets. This is the first time we’ve actually done anything like that. Most of the JavaScript work on our website in the old design were a bunch of independent pieces of code that repeated a lot of work and they might have embedded their own styles as a string or their own markup as a string. And what we’ve down now is we’ve created a way that we don’t repeat the same amount of work. We have a framework that can capture page-level events and pass it to all the widgets that care about it. Widgets could communicate with each other and react to state changes. So if a breaking news alert appears at the top of the article now, anything that is fixed position can actually adjust itself and make sure it’s in the right spot. And keeping it all consistent is all done through event-based messaging. So, we actually do all the personalization on the client side as well. So, if you come from the home page, we’ll show you the rest of the home page feed at the top of the page. If you come from your recommendations, we’ll show you that. All that is chosen at runtime by JavaScript, including advertisements. We layout the page in interesting ways based on what ads we get back. So, there’s a lot that we have to do on the client side because we can’t really cache personalized data very well. JAMISON:  What do you mean when you say there’s a lot you have to do because you can’t cache personalized data? EITAN:  So, if we were to write markup that was specific to an individual user, caching that in our server infrastructure wouldn’t be very efficient. Every single individual person would have their own copy of what should be the same content for everybody. JAMISON:  Oh, sure. EITAN:  So, what we do is we cache a generated page and we enhance it for that user in JavaScript later. JAMISON:  Okay, that makes sense. CHUCK:  Yeah, I think it’s really interesting. I look at this and for the most part it’s a pretty simple-looking page. Now I’ve been clicking around to the different sections and stuff and for the most part it seems like it’s just a giant CMS. But you make it sound like there’s a whole lot more to it than that. And I understand that you have the data and information in the CMS on the backend and you’re rendering a lot of this with the JavaScript. Are there things in here that people just don’t understand would be that tricky to build? EITAN:  Are you referring to the article pages? Okay, because we re-skinned the front page as well, but we didn’t actually change much in terms of functionality there. But on the article pages, I don’t think I’ve heard any specific feedback that has been really confusing to people. There’s a little bit of awkwardness I think with the two panes, with comments that people aren’t really used to. And the way scroll events work in the browser, it can get a little funny when you’re scrolling through one and the other one starts to move. But we actually discovered there’s an interesting thing that people are doing, is that they go from our home page to an article and then they’ll hit the back button to go back to the home page. And we were really surprised by this because we’ve spent a lot of time building ways to go forward from the article. There’s the, we call it ribbon at the top which is that horizontal listing of stories, usually in the feed in which you came from. So, if you were on the home page it should say home page and you can see all the stories there. At the bottom, we give you some suggestions on what comes next within the feed itself and some recommendations for you. We have related assets all over the story. The little arrows that appear on the right and left can help you navigate. You can click them or swipe. But people seem to like their dip in and then hop back out to the home page and find something else. And they do this forward back type of movement. So I think there’s a lot that users need to adjust to with this new design. We just try to enhance our content. It’s more than just a story. There’s the photography which we really like. You can actually see the really large photos which we didn’t always expose before. I believe in some cases, it was still showing up in a popup. Now we have this awesome media viewer where you can see our videos and the slides full screen. It looks really great. And the fixed nav at the top gives us some useful utilities. You used to have to scroll at the top or bottom of the article to share it. And share persists and follows you as you go around. So to search, if you want to look up or switch to a new location, the entire navigation is present instead of just that section or subsections. You get the entire taxonomy of our entire site available on the page. So we’ve tried to make the experience of being in an article not such a silo, that you can actually break out and experience the whole depth that is the New York Times just from one page, which is a challenge, a design challenge and a tech challenge. [Chuckles] JAMISON:  So, any time you have a major established product like this that has a huge user base, it seems like there’s a balance in redesigning between making things better and the cost to users of throwing away the knowledge they’ve gained already on it. So even if it’s absolutely better, because users have to relearn things, they might end up hating it and leaving it or something. How do you balance the change to make things better with maintaining familiarity? EITAN:  Maybe Reed can talk to some of the specifics on maybe how some of the decisions were made, but what we were doing, while there is a fresh skin and a new look and all these new features that people can experience, a lot of this actually happened under the hood. The website itself has gone through an enormous infrastructure and technology change. What was happening before was when I said that we could generate a static, some markup, we were actually creating a file on disk that couldn’t change unless you republish that article, using the terminology from the paper. And the problem is that those files persist forever. They’re static. And doing dynamic things has been a real challenge. If you change any of the markup or you want to add something new and you have to account for legacy. It was a huge infrastructural and difficult problem for us to solve. So what we’ve done under the hood was we have this entirely new dynamic system that allows us to make tweaks a lot faster. And this notion of a monolithic redesign is kind of moot. We can actually change in a more agile way in response that we get from our customers in addition to any boundaries or innovations we’d like to push on our own. I don’t know if Reed has anything he’d like to mention in terms of how. We did some user testing. We got some notions on how people use the site, the old site. It’s hard to get the terminology straight now. How they use the old site and what kinds of things they looked for, what kind of reader they were, and how they wanted to experience the news on the web. So there were some interesting things that we had to do to get around all that. CHUCK:  So you’re talking about a redesign and you’ve talked about some changes on the frontend and the backend. I guess line for line, how does it break down? Is there more code on the backend or the frontend? EITAN:  [Chuckles] I think we’ve written a lot of JavaScript than we have on our backend. We have our own templating framework that we use to generate the HTML, but it’s designed in a way so it’s not very repetitive at all. So we actually had to write a bunch of new JavaScript widgets from scratch. We didn’t port anything over from our old website. And so we basically started with a new framework with RequireJS and Backbone, one to give us scoping and one to give us structure. And we had to basically write everything all over again. I think most of that was done for the client side as opposed to on the server. A lot of it is, in terms of actual physical infrastructure, new hardware and caches and things like that. But in terms of what we did technology-wise is we changed the number, in our build system, in what frameworks were used. And just the entire JavaScript widget application writing for our page has completely been overhauled. CHUCK:  Yeah, there are some pretty nice widgets on here. One other question I have is you said that you were tracking behavior and performance on the old website. I’m assuming you’re doing that now on the new website so that you can continue to improve it. What kinds of things are you looking for and what tools are you using in order to measure those things? EITAN:  In terms of tracking behavior, we do try to track. We have our own analytics for events that occur on our pages just to get a sense of what things are used and how deep people go in our navigation or what widgets they interact with and in what way, what links get clicked, what doesn’t get clicked, just to have some knowledge on what features people are finding useful or just discovering or aren’t featured very well. REED:  Yeah, and just to build on that, before we even started development, there were several wireframes and several versions of what the New York Times was going to be like that was experimented with, with users. We did internal user testing, had users sit in front of it. Then we had a prototype that we put in front of New York Times users in public and randomized entry intro that prototype. So, we had a lot of learnings there before we even had the production version of the site go out, of how users were really using the site, and did A/B tests of what worked better and what people didn’t like. And so before we even launched, we had a pretty large wealth of data of how people were using the site. And that’s how we made a lot of these decisions. And so we went through several iterations of what the New York Times was before we even got to this point. So it’s been an evolving process here. JAMISON:  So, most people don’t work at the New York Times, right? It sounds dumb to say it, but it’s true. You guys are in a very unique position. Are there any things that you think developers working on other products that might have or slightly different focuses, are there any things that they can learn from your experience in doing the redesign? EITAN:  It’s hard to say. This is a personal anecdote. I found that what was our normal day to day, decisions we had made and choices we had made, I didn’t think that would apply to very many other people only because the size of this organization and its goals in terms of journalism, it’s really interesting that we have our strange workflows and we had to adapt a lot of these things for our use case. And so, I don’t know how much of it really applied to other people. I struggled personally trying to reach out, whether we should reach out to people who created some of the JS frameworks that we used to ask them if we’re using it right [chuckles] or if they had any suggestions on what we should be doing. Because it turns out that some of the normal situations that these frameworks account for may not apply to us as they were. We had to tweak and adapt things to make it the way that we needed it to be. So, I don’t know how much of that is really useful. We’ve been interested in trying to be more open in terms of the technology we’re using and some of the decisions we’ve made and what we found in our experience in terms of how we’ve used everything. And maybe that’s helpful to some people somewhere, but often it feels like every organization has to solve these things for themselves. And the best advice that we can give is to say that that’s okay and that you don’t have to use them the way that you’re told to use them. Understand the tools that you use and adapt them for your needs. REED:  One thing I think we can all learn from is with this technology we use in both the mobile web and the website is we use Varnish. And this isn’t really frontend, but Varnish is really what makes our site go really, really fast. So just having that reverse proxy there and serving pages ridiculously fast. And the mobile website, I know Varnish is a big reason why that site is fast and it’s the one site that I can read going through the Lincoln tunnel on my commute to work. So, the fact that it loads in there means that it’s certainly doing something write. So, I know Alastair can talk a little bit more into that. ALASTAIR:  Yeah. Well, the other thing I was thinking as a takeaway from both on the mobile site and the desktop site as we extensively redeveloped the mobile site last year as that this has been described as the last redesign that we’re going to do at the New York Times because this has been such a huge project. And in the future, just iterative process is the way that we’re going to try and move forward. And I feel like that’s a model that makes a lot of sense for a lot of people because tackling stuff in huge chunks ends up becoming a bigger issue than it should be. CHUCK:  That’s something that I’m curious about. So, was the old website just something that you couldn’t iterate from? EITAN:  Yeah. It was a real challenge. Like I said, we used to write those pages to disk. We wouldn’t change them unless there was actually some publish action taken on them. And that was an expensive process to do on a massive amount of articles. And so what we would be left with is as new projects evolved and new things got built, adding new HTML to pages, every time we made a change there was basically this one point in time where everything that came before had an old configuration, everything that came after had a new configuration. But we didn’t have any way to version our frontend assets. So, a lot of our code just grew and grew and grew and we couldn’t remove anything because we were unsure what would break. And there were just a number of permutations of these configurations. And it just became this massive weight that we just never tackled and we finally did in this redesign. And since everything is dynamic now, we version everything and we cache it so aggressively and we can change it really in a short amount of time. We’re actually able to not only fix bugs quickly but introduce new features on an entire category of pages that we can reason about and have an understanding of how it affects our site almost immediately. ALASTAIR:  I think a lot of the credit for that needs to go to the guys who work on our APIs, mostly internal. There are some external ones well. A few years ago, we didn’t have the means to just go to an API and say, “Hi I want to get this article content,” whereas now we have this fantastic suite of APIs where really, no matter what kind of content you might want at various points in New York Times history, it’s just a single API call away. So that frees us up from a lot of those concerns. EITAN:  Definitely. CHUCK:  So, what is your development process at the New York Times? You said you do agile but I’ve met a lot of people who say they do agile. So you want to talk about that? EITAN:  Sure, although I think Reed has a better picture of it. I’m going to defer over to him. REED:  Yeah, sure. So, the mobile web has their own process. I’ll speak more to how we’re building the desktop version of New York Times, which is tablet and up. And so we’ve had a large development team for quite a long time working on the redesign and just pretty much putting all of our resources in. We worked during redesign on two-week sprints. And now that the redesigning’s over, we’re really looking at one-week sprints now. We have a platform that we can finally be iterative on. And so, we can really change in a one-week time period. And the business needs change as quickly as technology changes. So, we’re finding that the one-week sprint works really well. And looking really at getting that minimum viable product out there in front of viewers as soon as product lets us now, and then iterating on that in development and find when the best place is to move on to the next largest priority. So, that’s what agile looks like in our organization, is one-week sprints and being able to quickly respond to other changes. JAMISON:  What was it like before it was, when it was harder to iterate quickly? REED:  We had 15 developers in 15 different projects happening at once. [Laughter] REED:  So, I think part of, at least for our team, was this redesign really allowed us to reinvent our process. And in the beginning when we started this, we felt like what worked well was theming our sprints. And so saying alright, this is, I don’t know, the platform theme, and where we focused all of our attention. Because it was so easy to get distracted. It’s such a huge site. It’s so easy to get distracted by so many different things and theming things really worked well for us. But it’s less about one person maybe being the owner for one thing and that’s who you would always go for and having an article specific team or a homepage specific team, and more about this is the web team and having smaller groups who work together collaboratively. And I wouldn’t say we’re on the pair programming level, but we’re getting to a much more developer collaborative kind of environment. CHUCK:  Very nice. Yeah, those are a lot of benefits that I see from agile. And it really does allow you to focus on what’s important. And I think that’s the core of what you’re talking about there. One thing that I want to ask about, you keep saying the desktop version is tablet and up. And Jamison thinks that’s interesting. I think it’s interesting too, but the reason I think it’s interesting is because on the tablet, I’m navigating with my finger. It’s all touch. It’s not the same version. Well it’s pretty close to the same version of WebKit and things like that on my iPad. But it’s not quite the same paradigm as keyboard and mouse. Do you find that there are mismatches or things you have to do to compensate one way or the other? EITAN:  We certainly had to account for touch and gestures and behaviors that come with tablets. We actually use a library called hammer.js to do all of our touch related stuff. Yeah, and we had to build that on top of the pages that we already had and wanted to reuse. I think really, it’s hard because we changed the nomenclatures, not mobile versus desktop. It’s tablet and up. And I find that interesting too, that we decided to go that route. But basically, I think a lot of the features on the page are really designed for a decent internet connection. I really think that tablets are more likely to be on a Wi-Fi or a faster network than a phone that’s on a radio. 3G and 4G while they’re making improvements, it’s still, we can’t deliver the same experience to something smaller than a tablet. So, I think we just drew the line at that experience. And we even had to account for two different breakpoints at the different orientations of these tablets as well. So if you’re in portrait mode, you have more vertical space, but you’re in landscape mode, then things are a little more compact but you’ve got more width to deal with. And it’s interesting programming for that, which is why also it helps to have a responsive framework in JS as well, is that we can answer the orientation change and change our breakpoint when that happens. ALASTAIR:  I think that the interesting thing is the number of variables you have. There’s touch versus keyboard and mouse, and then there’s fast connection versus slow connection, and then there’s big screen versus small screen. So, I’d say that’s the big divider between the mobile site and the tablet and up site, is the big screen versus small screen, because in terms of content, there’s a big difference there what you can do and what you can achieve with photography or maybe a map or an interactive or something. People interact with them in different ways and you’re much more constrained on a mobile screen of what you can fit on. So, it feels like a very different challenge in that way. REED:  One of the interesting things about the desktop version is we have 20 different breakpoints that we work with. And so, the article page can actually render into probably a hundred different variations because we change the experience based on the journalistic intent of the article. So if we have an article that wants a jumbo-sized image, we show the jumbo-sized image and have the content that surrounds it appear differently than if they wanted a large image, which is sized down from that. We also make a priority of our ads. So, if we have a large image but we have a directly sold ad, meaning the New York Times has worked directly with an ad vendor, we’ll give prominence to that ad and show it above the fold. However, if we didn’t have a directly sold [inaudible] and it came off an exchange, [which is] problematic here, we show the content in a much more prominent position below the fold and that would give room for the text to appear above the fold along next to the imagery. So, when you add all the breakpoints in there, you have images that are the right size for the right breakpoint factored in between 768 all the way up to 2050. There are so many different ways that you can probably see one of our articles based on all that. JAMISON:  That’s really interesting. Yeah, there’s just an incredible [inaudible]. I wanted to ask a little bit about accessibility. Did the redesign change anything to make it more accessible or did you guys already have that figured out? How does accessibility work on your site? REED:  So, accessibility is definitely one thing that is really important to us. And we definitely have a ways to go. And we’ve involved industry experts in the field. You know, accessibility’s always been a very, it’s been a new thing for us. We have these much more complex websites and how screen readers read it and parse it has really changed quite a bit. So, there’s a lot that I think what we’re going to do in the coming months to make our site more accessible just by removing the C column which we used to have, which is the right rail that used to house pretty much what people call the junk, the ads and these different modules. [Chuckles] REED:  We’ve integrated that into the body of the content to accommodate a lot of this responsiveness. So it integrates into the content at smaller breakpoints and then is more off to the side in others. And that creates a challenge for screen readers, because it might enter into those modules unexpectedly because it’s really part of the content. So, there are a lot of things that we’re working on to make our site accessible. But we’re hoping that this iterative platform really allows us to take care of that low-hanging fruit first. There are definitely readers who report some challenges. So it’s definitely been a learning experience for us trying to make the site as accessible as possible. But I think we all are learning. Our QA lab which is very much embedded into our process, this is a new territory for them. They’ve always been, “Okay now we have IE 8 and tested it on all the different Windows platforms and Mac platforms and mobile platforms.” But now the whole different devices like JAWS or whatever are now being part of that process to make accessibility part of our workflow now. JAMISON:  Sure. Yeah, I didn’t mean it in any way like an accusatory thing like, “You guys are doing a bad job. How are you going to make it suck less?” It just seemed like it was something I could learn from. REED:  No. Well, it’s been such an interesting project that when you launch a new site, like we said in the beginning, you’re bound to piss off a lot of people. [Chuckles] So it was interesting. You found that on Twitter people are raving about it and then you look on some specific posts that we’ve talked about on the New York Times and some of the comments and there are a few people with complaints. So, when you launch a site like the New York Times, you’re bound to disrupt somebody’s flow. [Chuckles] So that’s really what we’re trying to work out, is restoring some of those flows that people got used to, but maybe more adequate and really trying to make it part of that, a more integrated experience for everybody. EITAN:  It is a bit of a challenge, accessibility on the web, that a lot of the screen readers are built by third parties. And they do their own thing and they try to account for common developer practices on websites to figure out what the intent is and they do a lot of work. And that costs a lot of money and people who use them and rely on them usually pay and then W3C comes a long and they’re trying to write a spec and help make this a standard and they have an open source reader and they don’t always mesh. And it’s really hard to try and do this according to a spec but also try to deliver something to screen readers that people have paid for and are very unlikely to get rid of just because they may have put out some real money to get them. So for us, it’s not only just a challenge because we’re learning as we go and trying to figure out what we can do better in that department. But also, I think it’s just a challenge across the entire web to really get it right and follow these specs and be accessible to the largest majority, the largest share of screen readers possible. JAMISON:  that makes tons of sense. CHUCK:  So, we talked a little bit. You mentioned Varnish as one of the things that makes it tick on the backend. Are there other performance things that you have to do for a site that gets as much traffic as New York Times or do you just throw more hardware at it and crank Varnish up? ALASTAIR:  We’ve been really amazed at just how far we can push Varnish. When we relaunched the mobile website last year, it was previously done by an external company. So, we didn’t have a huge insight to exactly what their stack was at the time. So, we were quite concerned when we were going to flip the switch. Are we going to make sure that we’ve got enough? And we vastly, vastly underestimated Varnish’s capacity. But at least part of that are the structural decisions that you have to make along the way. And Eitan’s talked about this earlier. Obviously Varnish is going to cache all the content but you can’t cache the individual person’s details or anything like that so you always have to structure the site in such a way that you’ve got the really key content as cached and that’s going to be incredibly fast. And then the actual user-specific stuff can be, you use AJAX to bring that in afterwards. And as long as you’ve got that right, then it scales very well. EITAN:  Yeah, and considering that we are a news organization, our traffic can surge at times depending on what happens in the world. And if people choose to come to our site to get the information and we can talk about specific events. When the Bin Laden raid went on, we saw surging traffic that was unlike things that we had accounted for. So Varnish has proven exceptional in this way, that even with a handful of servers, it’s been able to handle load like nothing else. I think Reed was the one who tweeted that Varnish was making grilled cheese sandwiches in between serving requests because it just wasn’t, we weren’t seeing very much load on our setup, which is amazing. CHUCK:  Yeah, it is pretty impressive sometimes what you can get out of a cache. And it sounds like Varnish really does a good job for you guys. EITAN:  Oh, definitely. CHUCK:  Are the things that we didn’t know to ask about New York Times that we should have? ALASTAIR:  Well, one thing that I can sort of talk to you briefly on the mobile side of things that has the potential to be interesting in a few [inaudible] places, is probably the best way to say, is that the backend on the mobile side is all written in Node. So we do have JavaScript running on the backend and the frontend. And because we have to deal with these devices, all Blackberry browsers and all that kind of stuff where the initial development had to target low baseline. But we found actually working with JavaScript in the backend adds this great flexibility that if we want to start rendering stuff on the frontend on devices that can support it, it’s really simple for us to do that. So, in the future, and everything’s been developed in a modular way that means that when we know that we have a device like an iPhone that can handle some complicated frontend stuff, we’re just going to be able some backend code straight over to the frontend and then add to that, but then have the same stuff rendering to less capable devices. So that’s something that I’m really excited about. It’s something that I’ve not used. This is the first major site that I’ve developed using Node on the backend in that way. And it’s been a really interesting process to go through. CHUCK:  Interesting. So, have you done much of that kind of tuning where certain devices get more on the frontend and other devices just don’t? ALASTAIR:  Not yet, no. We’ve been doing lots of experiments internally, but really we got to the point of making sure that we launched with everything at this base level that’s going to work everywhere. And so now, we’ve been experimenting around with what we can start doing next. So hopefully further down the line, you should see some interesting stuff. CHUCK:  Yeah, I’d really love to see that if you make it work. JAMISON:  I was going to say that sounds really interesting too. Are you working on any open source tools or anything that other people can jump in and use or contribute with? ALASTAIR:  We haven’t got to that stage yet. I’d love to. It’s still just very early stages now, working out exactly what stuff we want to push down to the frontend that makes sense to. But certainly there’s a lot of potential I think on the mobile side of things to add interesting stuff to devices that can handle it. So yeah, I guess watch this space is the best answer I can give. [Chuckles] JAMISON:  Sounds good. EITAN:  There’s certainly an interest just in general. And the technology department here is anything that we build that we find useful. And we’re totally open to sharing any of that. And there have been very limited things that we have actually released publicly, but there is a desire to share some of the stuff that we use. And of course we want to make sure that we clean up all the things, any shortcuts we may have taken to ship. But certainly, we have a lot of interest in sharing things we’ve built. ALASTAIR:  It’s certainly worth mentioning that we do have a bunch of externally accessible APIs that you can sign up and use. They’re all JSON formatted and so on and you can get article content. It’s an incredible search facility. You can query Times content going way back. It’s really a fascinating thing to play around with. We have hack days a few times a year here in New York Times offices, invite everyone to come in and just hack on top of our APIs and make interesting content. And I’ve seen some really, really fascinating stuff come out of that. So we’ve always enjoyed every opportunity we’ve had to invite people to use the stuff that we have. So it’s definitely something that everyone wants to make sure we do in the future. JAMISON:  Is there a link to resources or is this just an invitation-only thing for special occasions? EITAN:  It’s developer.nytimes.com. ALASTAIR:  Yeah, it’s either developer or developers.nytimes.com. [Chuckles] JAMISON:  So, it’s developer. ALASTAIR:  There you go. So yeah, we’ve got all the listings of all the APIs which are completely free for anyone to use. And we also have, we call it the Times open blog where every developer here is encouraged to write a post for the open blog on whatever technology or whatever topic they’re interested in. And so that’s a really interesting resource that everyone tries to contribute to as best we can. JAMISON:  That’s super cool. I didn’t know about any of that stuff. That’s awesome. EITAN:  Yeah. The open blog is great. I think we’re really interested in talking in specific detail about some of the things that we did for the redesign in the coming months. So definitely keep an eye on, the latest one is by Reed himself [chuckles] giving a broad overview of how we did it, how we did the whole thing from a bird’s eye view. JAMISON:  That’s cool. It looks like the redesign hasn’t hit the open blog yet, though. [Chuckles] REED:  So, the blogs is a different platform. We still use WordPress for blogs unlike our own internal CMS. One of the interesting things about this redesign was it was so expansive. So, over the coming weeks and months we’re going to be bringing some of the other things onto the new technology stack. So, you’ll notice that the homepage is really just a re-skin so that’s one thing that we’re going to put on the new technology stack. And then blogs is another thing that will be inheriting a lot of the new infrastructure that we put in place as well. JAMISON:  The tagline for this blog is amazing. All the code that’s fit to printf. I like that. It’s super good. [Laughter] REED:  We also have an Easter egg in the JavaScript console for folks visiting an article page. That’s definitely a plug there. CHUCK:  Go find it folks. JAMISON:  Don’t spoil it. CHUCK:  Alright. Well, let’s go ahead and get into the picks. Jamison, do you want to start us off with picks? JAMISON:  Sure. I have two. One is an article by a guy at Microsoft Research, which is a phrase I have never thought I would utter in my life. But he writes a weekly column for this magazine and it’s like a humor column. This one’s about distributed systems. It’s called The Night Watch and it’s amazing. I don’t know. I can’t describe it in words because it would be dumber than what it is in real life. So, you should just read it. It’s amazing. And then my second pick is just a band that I found out about. It’s called Ball Park Music. It’s like popish, Americana type of stuff. I don’t know. It’s really good though. It’s been my soundtrack for this week. So, those are my two picks. CHUCK:  Awesome. I’ll go ahead and do some picks then. My first pick is one of my favorite websites, honestly. And whenever I need filler text, I use it. And that is BaconIpsum.com. Basically it’s your lorem ipsum except it is bacon ipsum instead. So, the first word is bacon and then it has the first six or seven words after that that come after lorem. And then after that, it uses meat terms to follow kind of the same cadence and sounds as lorem ipsum. So, I really enjoy that. And it’s just a nice way to add a little bit of humor to the code, especially in places where you know that the text is going to be replaced eventually. So, that’s one pick. One other pick that I want to make, I’ve been reading The Lean Startup again. And it’s such a terrific book. And these guys talked a little bit about how they were measuring things on the old website and figuring out how people used it and then they have people use the new website and things like that. And that all goes into the validated learning that they talk about with lean startup. And it’s just a terrific way to go. And I really try and encourage my clients to do that same kind of thing so that they know what their customers want and that they can make sure that they can give it to them. So yeah, I’m definitely picking that. And I’m going to pick Audible again, Audible.com. It’s a terrific service. And it’s nice because when I was driving down to California and then driving back from Las Vegas last week, I was able to just listen to books including The Lean Startup. I also listened to some fiction and some other books. And it’s just awesome. So, Audible.com. Reed, do you want to give us some picks? REED:  No, I’m leaving the picks up to Eitan and Alastair. [Laughter] CHUCK: Alright. Eitan, hit us. EITAN:  Okay. So, the first one is an article from HTML5rocks about ES 6 promises. We use a lot of promises in our code and I’m actually really excited for those to go native. It allows us to do some really, really awesome stuff in terms of making sure we synchronize all of our API calls from the frontend to animations. And I’m just really excited to see this break out of frameworks and go native in the browser. And anything Jake Archibald writes is really great. And then the other one that I had, it’s a book. It’s called High-Performance Browser Networking by Ilya Grigorik. And you can actually read it online for free courtesy of O’Reilly and Velocity [conference]. It’s probably one of the best books on web development I’ve read in the last five years, just truly understanding the web, how it works, what’s coming in the future and some really awesome capabilities like web RTC and server push and sockets and things like that. Just a really enlightening book, just really great. And if do one more, [chuckles] I’m a big fan of the Polymer project which is basically a take on web components. I think that’s a really interesting project, being able to make your own widgets and serve them as a cohesive unit. Shadow DOM is just a great idea. I actually want to see the advertising industry perhaps pursue a shadow DOM and web components and being able to just drop one tag that represents your add and it’s kind of siloed and won’t break your page. So, I’m a big fan of where these are going and people should definitely play around with web components today. So, that’s me. Those are my picks. CHUCK:  Alright. Alastair, what are your picks? ALASTAIR:  Okay. So, my first pick is actually that everybody should try out the latest Firefox Nightlies. I, like a lot of people I suspect, I’ve used Firefox once upon a time, then I switched over to Chrome and I haven’t really looked back all that much since. But we started playing around experimenting with actually getting the New York Times mobile site as a Firefox OS app, which let me to try out a lot of this stuff. I haven’t maybe looked at and given the level of attention that I should have in a while. And the latest Nightlies on the Mac at least have a brand new UI. The latest versions on Android are a lot slicker than anything that I’ve seen previously. So, I’m using them day to day now or partly if it’s as an experiment. But I’ve been really, really happy with it. So, I recommend everyone just gives them a try. And second recommendation is an app that maybe people have already heard of called Pocket that somehow passed me by until recently. It’s a mobile app that also has extensions for every single browser that just allows you to save articles and then they’ll automatically download to the phone. And for people like me who have long commutes underground where you have no internet connection, it’s really great. Because during the day, I’ll see numerous links on Reddit, on Hacker News, wherever, and not have the time to be able to read them. I just click the button that saves it. It’s on my phone. So without thinking about it, when I jump on the subway train I just open it up and I’ve got everything I want to read that are waiting for me, which is fantastic. On the non tech side, I’m picking a site called Scouting NY which might not be that interesting for people that don’t live in New York. But it’s basically a blog of this guy who is a film location scout who travels around New York city and keeps uncovering these really interesting buildings that people have not seen in about 50 years, so there’s crazy art deco design, so it’s interesting stuff. It’s just a fascinating guide to New York that you don’t often see, I don’t think. CHUCK:  Awesome. AJ, you have some picks for us now? AJ:  I do have some picks for us now. So, I want to pick CodePen.io. That is just a really cool place to create little mini test gizmos. I think it’s maybe more interesting for things that are visual than JSFiddle which is what a lot of people put their code snippets on. And there’s a sharing option where you can be live coding with someone else. I think you have to have the pro version for that, but that’s really fun. It’s got a couple of glitches in it. Sometimes you have to refresh the page or whatever. But it is nice to be able to have somebody doing HTML and CSS and then me doing JavaScript to demonstrate some little bit of awesomeness together. Also I’m going to pick GoMockingbird.com. I think I might have picked this before. But it’s a mockup site where you can draw wireframes and add links to objects that you’ve drawn so that you can click back and forth through a user interface experience and be able to see and talk about what that experience is going to be. And I found it to be really helpful in clarifying conversations rather than just having specifications listed out in bulleted list form to really go through and put them together in a wireframe. CHUCK:  Cool. Alright. Well, I think that’s all we’ve got. So, I want to thank you guys for coming. It was really interesting to talk about and hopefully we’ll see some other great things coming out of the New York Times. EITAN:  Thanks for having us. ALASTAIR:  Yeah, thanks.