 The first thing you'll notice is that why did they send the completely opposite height people here? It was mainly to confuse the cameraman so they have to zoom and zoom and so we're just going to stand next to each other whole time. There's good, I don't like to call it short, I like to call it vertically challenged. There's a lot of benefits of being vertically challenged, namely that I can just fit in the trouser press at the hotel, just everything. That's why I'm dressed this way, I can just go and trouser press, Americans don't know what the trouser press is but it's a wonderful, wonderful item because I hate ironing. I'm Josiah McCann. I'm Josh Schraub. I manage the core web development team at USA Today Network and Gannett. I'm a principal developer also on the core web team and we're super happy to be in London today and we're going to kind of tell you a story. In being in the news, we're all about storytelling and we're going to tell you all our polymer story today and it's going to be really exciting. At first though, before we start, I just wanted to give another round of applause for all the speakers so far because it's been amazing and great. So everyone just, absolutely amazing. This is one of the most practical conferences that I've been to in a very long time and we've just learned so much and you'll see we're going to be taking things back to the States and implementing all sorts of things that we've learned here and I hope you will too. If you didn't already could tell that we were Americans, that kind of gives it away too. Yes, this is USA Today which is the flagship of Gannett and I was told I needed to put that on there. We wouldn't be cool. So that was a quick last slide at it. Use the platform, yay. Yes, yes, yes. We definitely use that platform and you will see. A little bit about Gannett and USA Today. National coverage through our flagship paper USA Today but we also have over 100 local newspaper brands sharing the complete same framework. We engage the entire country kind of local bubbling up to national and national spreading out to local which is really, really interesting. We scale is a big thing here. We have over 110 million users engaging in our digital platform every month. We have over 500 digital products at Gannett and our products reach 43% of the internet population and it's amazing. It's also really hard because scale and stuff. 1.1 billion page views on articles and news articles per month. There's just a little graph showing you. We also own news quests with the parent company of news quest here in the UK as well. We own a lot of different things across not just the US but the rest of the world too. Josh is going to talk about what our current platform and what our platform on web components is. Josh, take it away. So currently we have our own CMS system and that publishes out to couch base and we have like a rest API layer in front of that and then all of our products consume that rest API from native with watches and TVs, Android, iOS and also our web products. So we do adaptive delivery between two different code bases for web. So we have a desktop code base and a mobile web code base. That lets us deliver a very lightweight mobile website and a big heavy SPA for desktop. And we have some modularity kind of built into this system but it's very much limited to per kind of experience. So articles have a module system. The front pages have a module system and the module system is different between mobile and desktop. So it's not really as great as the modules that we've been hearing about all week and that's kind of what we want to move towards is better modules. Both of the web front ends they're built on Python, Django and then the front end is Backbone, jQuery and Require. So it was very modern when it was built back in 2012 but yes, but this is the 40s when we all use it. Django for the very first time. But this is 2016 and this is a very tightly coupled client server SPA. So it's not really a great experience anymore. It's a sample of what our mobile experience looks like. And so beginning of this year we started moving towards thinking about how we could kind of make this better for development and better for our users. So we started looking at implementing a new framework. And we started this planning in spring, started rebuilding a little bit in May and June. The big reasons we want to rebuild are get these new progressive web type features and get those out for our users so they have a better user experience. And it's also kind of for developers because we all like to play with new things. And it's great when they also benefit our business and they benefit the users. We also wanted the ability to support multiple sites and experiences. Like Josiah was saying, we've got lots of different properties that are local that range in size from smaller newspapers that are just for little tiny communities to bigger ones that support big cities like the Indianapolis Star and a couple other fairly large papers in Detroit, Arizona. And so they've got a very different experience between those bigger sites and the smaller sites. And there's an even bigger difference between those and the national paper USA Today. But right now they all kind of use that exact same web framework. So it makes it hard to build something very custom per site. They get a little bit, but it's not as great as it could be. We also need to be able to support multiple distributed dev teams. Those bigger papers have their own developers and they're building great things for their little local markets, but they have to kind of build into this big code base that's getting shared between everybody. So when this little module gets built for Detroit, it's also in Arizona and it's in often USA Today and other places too. We also wanted a faster, more agile development process. That code base that's been growing since 2012. Or the 1800s. Or the 1800s. Feels like the 1800s often. It gets kind of big and it becomes a little clumsy to develop on it and becomes harder to test it, harder to deploy it because the bundle just keeps getting bigger. So that's what we were trying to move towards. In June we started building the back end of our new framework, which is Go, which is really cool but we won't get into that whole part of this. And then we started building our first project on it and Josiah's going to tell you a little bit more about that. So we jumped headlong into Polymer and the first experience that we built out with Polymer ever. We said, oh maybe we'll do something small, not that big of a deal. No, we're going to build the whole Olympics experience with Polymer and that's what we did. We jumped into the fray and said, you know what, this is going to be our proof of concept is our Olympics data-driven experience. And this is kind of a summary of the project and then I have some shots of it as well. We needed to display data-driven data from the 2016 Rio Olympics. All the kind of data that's coming about the schedule, about results, as results would come in, country-specific things, medal counts and as medal rewards were coming in. And then deep dive into athlete biographies. We also, because we're a news organization, we're writing a lot about all the interesting things that happened in Rio during the Olympics. We're writing a lot of stories, generating a lot of content, photos and videos and that was also a part of sort of recirculating that through this very data-driven experience. And once again, this is something that needs to be available on the domain names of all of our different properties. So not just usda.com, but available through IndieStar, through the democratandchronical.com and the framework needs to know the context of what site it's in. One of the things we don't do right now is we don't actually have any really, it's not a responsive site, USA Today or the rest of the sites. Josh mentioned that we're doing adaptive delivery with device detection. So this is our first real big responsive experience with a focus on doing mobile best, mobile first. And we'll show you what that looks like. So here's our schedule page. And the thing about data, about the Olympics is that there's a lot of it. There's a lot of data coming in a lot of different ways, a lot of results that are not necessarily you know exactly what the results and the data types that are coming back. It's very different, especially for the different sports. We have our medal. Oh, look, America got a lot of medals on that one. And then our athlete bios, and this is just a really small snapshot of all the various data points and then filtering through and just knowing more about a country, knowing more about an athlete. And then I just, I mentioned mobile and mobile performance is key for us. And you can see just sort of that complex data here being rendered nicely in our mobile experience. A little bit more about the project. Here's the fun part. You can't move the opening ceremonies. So we had 30 days to build out this site and this experience. We tested that, let's add more manpower to a late software project. I'm sure that it will make it fine. And so we tested that in this limited real world example with, oh yeah, newly hired developers. You can see where this is going. I can tell it's the hurdle, the hurdle jump, it's a good story, it has a good ending. Strong existing web tech skills, though, based on this new team, which is an amazing team. It's full of people right out of college, actually, junior devs right out of college, but they had really, really strong web skills. The overall experience, though, there was a lot of juniors and it varied everything between juniors to principal, which that plus 30 days plus brand new Polymer framework was like, oh, this is going to be fun. So we had a lot of coffee, though, in order to fuel. We actually began roasting, like Josh was talking about earlier, we're roasting our own coffee to fuel. How many of you guys turn coffee into code here? You see some hands. How many of you turn tea into code? We'll talk later. Part of this was changing the way, not only our development team was thinking about coding, thinking about changing from this page driven way of developing to web components, but was also educating the rest of the company, the rest of our department, into thinking in web components, starting out from, you know, moving everyone from, oh, here's a page and here's what's going to page. You think about modules, you think about componentizing to making atomic elements. For our design, it was encouraging standardization. We had, at first, when we talked about modules, we had a lot of modules that basically did the same thing, but had slight variations. What we wanted to do is we said, no, let's make this work everywhere. This puzzle piece, this Lego block can fit everywhere. So let's create better standards and not, here's what a page looks here, here's what a page looks there. For UX and IA, it was grouping content based on data source. Because there was so much data and all those different components were retrieving their data from different sources and doing different business logic for that data, it was really, really important that, at least for us in our small time frame, that we group things by similar data sources. Otherwise, the context wouldn't flow right and it made it a little bit harder to develop. From our project managers, our product managers to even our QA, it was testing and planning these features, these individual modules instead of full page testing, full page QA. And just even writing tickets about the stories, about planning. So it's all modular-based, component-based and not here's this page and here's that page. And then this conference is talking to a lot of developers about thinking in web components for our development team, a big win for this and how we did spoiler deliver in 30 days. The division of labor was really important. We could have some people working in this component, some people working on that component that was able to play to developers individual strengths, meaning someone who's very, very very front-end focused could do a lot of the styling and could help others that weren't with the styling. And then we had some more data-driven individuals who were connecting all the complex pieces of data from different places all together. So that division of labor played a key role. All that looked too was there was some interns that we had for the summer. And we were able to throw them on just modules where they didn't need to really know about the Olympics and what was happening or all the complex data that was going on. They could just focus on this little one thing, here's a story, a re-circ that you're building and I can just focus on that and I don't need to all the noise that's going all around me because there was a lot of noise. That focus helped us meet the deadline with that division of labor, which was just awesome and we're able to do that beyond the way that we're doing it before, in the platform that we're doing before, but taking advantage of thinking in web components. Josh is going to talk about all the wonderful hurdles that we experienced in this wonderful project. Yeah, so like any big project, we faced a lot of hurdles. Our approach was really to just be as agile and flexible and possible with features and how we were kind of approaching the project because otherwise there was no way we were going to meet the deadline. So the first hurdle we really faced was the schedule. As we've said, 30 days to build it. So the first thing we had to kind of rethink was how we were going to do a TypeScript integration. So when we started planning out our front-end framework, we were like, oh, we really like TypeScript, we really want to use this with Polymer. So we had these great ideas for how we were going to try and do it, but getting that integrated before we started doing all this development just really wasn't going to get that developer experience where we wanted it. We ended up kind of going with a bit of a hybrid approach where some of our developers were just building plain vanilla Polymer elements and some were doing with TypeScript with kind of a code-behind approach. So we did one file for the JavaScript, one file for the Polymer element, and then just use the script tag to link over to the JS version of the TypeScript file. And that way we were able to do some coding in TypeScript and get the benefits there. But the downside was you're now coding in two different files. So you're jumping back and forth in your editors and it really wasn't a great experience. It also caused us some other problems that I'll touch on later. We also just kind of limited how much packaging and fallbacks we were doing. So it would be great to be able to say we did all this great support for legacy browsers and all these great different approaches to, you know, HB2 and whatnot. But yeah, we didn't get to that. So we just kind of limited, we focused on modern browsers, we focused on supporting the browsers that we knew that the majority of our users were on and just focused on building the best experience we could for our widest audience. We also kind of delayed this system JS and JS PM integration that we had planned. So this was another feature like the TypeScript that we had these great plans for our framework where we were like, oh, we can do all this great stuff to support third-party JS libraries that maybe somebody's going to want to use. And we realized, well, we don't need third-party JS for anything we're building in Olympics. So we don't need to build this now. Something we've put in there now in our framework that we're kind of working on, we'll touch on that a bit. But we found we really didn't need any other libraries. We were able to just use Polymer for this. So our next turtle was performance. We were very new at building Polymer. So we made some of the same mistakes that we've heard from some other companies that they made when they first started. The first one was too many components. We jumped in headfirst and we said we want to build everything as a module. So many components. Here's all your components. Yes, yes. Lots of components. Components for everybody. And that ended up with a really slow page because we had thousands of components on the page. Kind of hand-in-hand with that is our components were too complex. So we just made these gigantic components and you saw from the little video, there was a lot of data on that page and there was a lot of little variations on it. So there were a lot of DOMIF statements controlling whether it was showing a matchup or if it was something like boxing or something like a 100-meter dash where you've got 10 people competing at the same time, you're going to have little differences in how you're displaying that data. So those complex things ended up slowing us down and we had to kind of go back and watch some Polymer videos from last year's summit, figure out ways we can improve things. And after just spending a couple hours, we were able to improve the speed of some components by over 10 times. We were able to get things really good and get the performance to a place we were really happy with. But when we first built some of the very first components, we were a little nervous just because of how slow it was, but that was because we hadn't thought about performance at all. And so just kind of is saying that when you're building stuff, you do have to think about it a little bit. You can't just go out and build everything as components and build them crazy complex and expect it to be super fast. But if you do it right, they are super fast and they are awesome. The last thing was Flash of Unstyled Content, which was as things were loading in, we initially weren't doing much to do anything about it. And so the page looked really funky. So we just put some basic styles in that focused on like the navigation, the page structure, and that helped get the page to look a lot better as the content was coming in. The last hurdle we faced was testing, partly because of that schedule. We didn't really get to have a testing framework in place and we kind of pushed off a lot of the testing towards the last minute, which meant we ran into some CSS things that we probably should have caught sooner, mainly around Flexbox, because this was our first time really using Flexbox drastically across all the stuff we were doing. And so we found all these little variations between different browser manufacturers with how they implemented various features of Flexbox. And so we had some really weird looking pages at first and it took a little bit of going back through the CSS and making it standardized across browsers. Also with JavaScript compatibility, this is where the TypeScript integration kind of hurt us a little bit because we started using ES6 features that aren't cross-browser everywhere because we were using them in our TypeScript code and then you would switch back over to a plain vanilla polymer element and you'd start typing let, you'd start using arrow functions because you're so used to doing it. But then some other browser would say, hey, I don't know what let means and now you've got a compiler or a JavaScript error and your component doesn't work. So that's where like switching back and forth between TypeScript and vanilla JavaScript really wasn't a good idea. The final thing was HTTP to delivery. This was also the first time we had done anything with HTTP to and having the whole site on SSL. So we ran into some issues where we thought, okay, we've heard all these talks about how great HP2 is. Let's just throw it on, push all of our resources and things will be awesome and fast. Not always the case. There's a lot of times where you don't want to push resources and there's times where it's better to preload them. And we hadn't thought all those things through and so when we first launched, there was a lot of stuff that actually could have been faster if we weren't pushing it. We found those things out post-launch and we were able to fix it now but that was something where more testing and thinking about A.B. testing forth performance and saying, is this feature really gonna make us faster or is this actually gonna slow us down even though we've heard it's the great thing to do? So now Josiah's gonna tell us a little bit how things turned out. So, let the games begin. One of the other interesting things with onboarding basically in a new team for that matter into a new framework was the strategy for us in building out a platform on web components was not to use a monolithic JavaScript framework and keeping on anything that was frameworky, very, very light and slim and really just playing up to components. You'll notice that in that video and another one that I'm gonna show in a second that it's not really SPA driven and it's not actually using the app shell stuff which is very interesting. It's still multi-page kind of loading which I'll talk about a little bit more in a second. Thankfully deploying iteratively saved us. We've been moving away from these really, really long deployments where it took an hour to hours to really moving more to a continuous integration approach to delivering these web components and these pages that had web components on them. We're also able to launch with a subset of features because they weren't awarding any medals right away on the opening ceremony but we started with the schedule because the schedule was really, really important. So we were able to do kind of subset iterative delivery in order to meet our deadline. So we're adding additional modules as the games were going on and as the games began so you can see that over here in this quadrant up in my, this upper right hand corner that we went from sort of this just recirculation experience to adding our metal module there so we could get you to a more data-driven page and Olympic's data is just part of the difficulty. It was so tricky and very inflexible. Boxing and some of the fighting sports, they award two bronze medals. It's like, wait, wait, two, what, what? I thought everything was gold, silver, bronze, two bronze medals and then in swimming, apparently you can have three silver medals because that makes sense to a data scientist it's like, ah, so there was lots of challenges there with the data but we're able to overcome them because of doing things iteratively and just the team was working with something that was in general easy to onboard and was not difficult to work with. So back to performance because it was a hurdle. How did we do? Did we win the gold? Did we win the silver? Did we win two bronze medals? I don't know, actually I do. So how did Paul Vermer perform against our existing baseline infrastructure of USA Today.com and what we've built and what we've been using for many years now. And so the average page load roughly was equivalent to our current platform. You can go on USA Today and you can check out what that kind of speed is but keep in mind this is without any time devoted to performance tuning at all because there was no time to do performance tuning. We were up, we were 30 days and that was it. So that we just by using Polymer and building this experience out we were able to get roughly where we are with our current platform. So our audience reach. This is really, really cool. We, this and the rest of our Olympics reporting that we did actually raise USA Today network the entire network up to our number two for comm scores, news and information category across the nation. And we just had amazing numbers coming in, 116% increase from our 2012 summer games and our data-driven experience was a core part of that as long as all the interesting stories and reporting that went on during the real Olympics. So I wanna spend too much time on this because it's the e-word elections but they're coming, whether we like it or not, it's happening. But guess what we did? We did it again in another 30 days. We were like, this is insane. This was pretty insane. Let's do it again and we did it again. But what's different this time based on what we learned before, we had more thought into module composition, how we were making modules, not putting DOMIFs everywhere and using DOMIFs properly, things like that. Optimizing, this is our chance to optimize our loading, our caching, the preload and push and the HTTP two things that we were talking about earlier. And then from a mobile performance standpoint it was part of our platform is, maybe you don't need every single module loaded on your mobile experience. Maybe that's kind of a subtractive experience when you have a lighter page load delivered there. And so that experience, which is kind of a sneak preview, looks something like this. We have a nice map loaded in and we have data from key races that are going to be battleground states this year. Let's check on Google California. So let's see specific state outlooks, race ratings, poll averages and I guess we can, I mean, we could change the data to make- Yeah, they're just elements so you can go in there and tweak it. Yeah, we can make anyone win, right? That we want, right? It's not going to really change it, but I mean, you can make it whatever you want. And this is a great thing about web components. It's changing and then all of a sudden I'm winning and it's great, which might be better than some of the other options. It's all the time we have for you today, that was our 30 day and then really another 30 day march with the power of web components on our side, being able to do the impossible with a brand new team who had never worked with web components before, which says a lot about both the enterprise readiness of Polymer and about that onboarding developer experience. Thank you so much. Thanks.