 Welcome everybody. We're going to be doing the Weather Channel case study. I know you're all very excited about it. I'm doing a quick head count. I count about 12 people. They're all lame jokes. That's all I've got. I'm just setting it up. If I lower the bar an hour, there's nowhere to go but up. Yikes. It's going to be a long hour. So yeah, we're going to talk a little about the Weather Channel, what we did, where we're going and that sort of thing, but first some introductions. I want to introduce one of the more brilliant web technologists I know. My name is Jason. This is also Chris. My name is Chris Hill, Vice President of Web Development at the Weather Channel. It's great to be here. And I'm Jason Smith, Enterprise Solutions Architect with MediaCurrent. MediaCurrent folks are spread out throughout the audience, so they'll overhear every word. Nothing? They can't all be winners. You guys are not going to get used to it. I'm sorry. I've been living it for a long time. So we're going to start with talking about who the Weather Channel is. Chris will introduce the company, what some of the challenges they deal with on a regular basis are. We're going to talk about what the selection process was, how we arrived at Drupal, why it was a good choice. Talk about what we did for the Drupal project. I have slides that go into deep technical detail, but we're probably not going to have time to go into them. If there's a lot of interest, I'll try to do it during the QA. Or if we have extra time, I'll spend some time on them. Next we're going to talk about where we're going next and hopefully have some time for QA. I apologize if I'm nervous because my boss is sitting in the front row and he's going to be grading me every minute of the way, I'm sure. First I want to tell you guys a little bit about the Weather Channel. I know most people have heard about the Weather Channel, but it's an amazing company, been there for 14 years. We really care about people and trying to keep people safe, trying to make sure that everybody's got the latest weather for where they are and what they're doing. We do this through the use of what we call our four S's. The four S's are science, stories, services, and safety. So through stories, we try to tell stories that are inspiring and illuminating to our viewers and our customers. We use the best in science to try to make our forecast local and appropriate for where you are and what you're doing. Services so that you can receive important information that makes your family safe even if you're not on our website or not using our mobile apps. We can send you alerts. We can do things to try to keep you safe even when you're not tightly engaged with us. And again, safety kind of already covered that, but safety is extremely important to us. We want to be there for you when there's severe weather. We invest a lot of money and time, a lot of highly dedicated people, trying to make sure that we are bringing you accurate and relevant information so that you stay safe and your family is safe when there's severe weather and when you're just concerned about the pollen being high. And overall, we like to remind our customers that it's amazing out there. So just some, and I cannot even read this screen because it's too small, but just some basic metrics about our site. On a daily basis, we have about 50 million page views. About half of those come back to our origin, back to our actual servers. We have about 30 million unique visitors a month. We all host that through three data centers with about 144 servers. And we have approximately 17,000 articles that our content team has been curating over a number of years, some that they reuse, some that they don't reuse. And I can't see what the other things are. And also another important thing that we provide is dynamic weather maps. We have some map generation software that we use on our website. We use it on our television channel. There's lots and lots of weather maps, radar, satellite shields that show temperatures, cold fronts, warm fronts, things like that. So a lot of very engaging weather maps. So one thing that was really kind of a crucial point for us in October 2012 was Superstorm Sandy. I think most people that were familiar with Superstorm Sandy, it's our Super Bowl. We heard it talk last night from a guy from Turner and he was describing their Super Bowl is when they were handling March Madness. For us, our Super Bowl comes multiple times a year when we have tornadoes and hurricanes and severe weather. Superstorm Sandy was a special condition where we did 300 million page views on one day. Now granted, all 300 million were, a lot of them were highly cashable, but it goes to the point that we desperately have to have a highly cashable environment for the site that we present. But we got tons and tons of traffic on that day. Over that week of the storm, we handled about a billion requests to our site and we presented over 170 million videos, video streams. And video streams are not a big deal because everybody knows that videos are cashed, but nonetheless, the engagement is important. It's the important thing to recognize that when severe weather happens, people come to us and they rely on us and we have to make sure that our systems are there and ready to serve. So I wanted to take the opportunity to point something out while we're on the same subject. This is an omnitra report from the day of the Superstorm Sandy or the week of the Superstorm Sandy. You'll see that their nominal traffic was about 100 million page views and in one day it jumped to three times that number. Topic of scalability is something comes up a lot. It's a very important topic, but it's a topic that causes enough pain. It causes a bit of topical depression. Yikes. You're welcome for that one. But the point I was trying to make with this slide is actually that the way that current architecture is built, you have to build in capacity for this spike. So we have servers that are there ready at L times to handle this spike. What we'd like to do is move to a system of platform, a framework, insert other word here, that'll allow you to scale up on demand. We want to move to the cloud rather than having all of these servers ready all the time. Ninety percent of the time we've got servers that are just sitting idle. What would be really nice if we could scale up when something like that happens? All right. So in October, in 2012, we decided that we made the decision that we wanted to rebuild our digital infrastructure. We have a solid system that works. It's there, it delivers, but we knew it didn't give us the feature velocity that we needed to move forward in the next 15 years. So we created this, we established a project and sold it. We call it the digital infrastructure reboot, basically going through and cleaning house, rebuilding everything from scratch. Two main components of that digital infrastructure reboot. First was our data services layer, providing the best in data services to our products. We'll talk a little bit more about that later. But then the content management system, which is why you're here today. So as we went through to determine what the content management system was that the weather channel needed, we developed an objective scorecard that had about 20 criteria on it. And in some of those criteria, the main ones, feature velocity, being able to having a system that allowed us to rapidly create content, create products and deploy them to the site, the reuse of content so I can take a module or something that I build on big web and I can reuse it on mobile web or perhaps even a mobile app. Scalability, Jason already mentioned, our servers sit idle, you know, 80% of the time, a lot of them do. So we want to have a situation where we run with what we need until we need more and then we can scale up by utilizing the cloud. Maintainability, trying to have a set of tools and set of software products that we build that are easy to maintain, you know, ideally easy to build and easy to maintain over time. And publishing capabilities, you know, we're a rapid publishing environment, we publish lots of content around the clock, especially when we have severe weather pages, page changes, we have a lot of content that we that we're rapidly publishing on the site. So we went through and, you know, we looked at multiple products, we looked at Adobe CQ, we looked at, we looked at the, you know, the big gorillas in the marketplace, we, WCQ, SDL Tritian, Open Text, we even looked at WordPress and, you know, psychotically we even looked at .NET Nougue for about five minutes. Because someone wanted to look at it so we did it. And, you know, after we filled out the scorecard, you know, Drupal was a resounding winner. It blew everything out of the water. So we ended up choosing Drupal as our content management system, which would have been awkward if we had not chosen it and I'm here today, but anyway. So the next step was to figure out how we're going to build this thing. So when we evaluated, yeah, so we evaluated vendors because we needed to figure out how we're going to go ahead about building this thing. So we, you know, looked out to, you know, the players that are out there and ended up choosing Media Current as our development partner. To my dismay. Just kidding, Dave Terry. So the approach we took was, I'm sorry, this is your slide. Not bad. So we, Aquia and Media Current came to the table. We did a little series of mini discoveries, which in this context you might call a series of lightning talks. All right. That's the last one. Fine. It's funny that the non-jokes get more laugh than the jokes. What we got out of that was a good idea of what it is they were trying to accomplish in the aggregate and from those discussions we developed a series of proofs of concept and those proofs of concept were things that like building a Drupal site that would allow page building under their particular requirements or rewriting the page in the browser to meet, you know, whatever scalability needs they have. Then after we were brought into the project we did a deep dive, which is we spent time getting to know every part of the project. We learned how video was managed. We learned how images were managed. We learned how slideshows were managed. We took a nap. We learned how all the rest of the site was managed. We also learned how the team dynamics worked. We learned what their processes were. We figured out what, where we would fit into the group as a whole so that we would assign the right resources so that we could provide the most benefit, the most return on investment. All right, so the engagement. So, you know, we jumped ahead. I had already announced that we picked you guys. Could we back up everybody? Yeah, so forget the last two minutes. So the way the weather channel works, when we have a problem, we attack it aggressively. We will go hire some contractors, put them in a room for a raw meat in there and build what we need built. So when we decided to go with Drupal, we went out and we interviewed Drupal developers. One of the key components for choosing CMS was to have a CMS that had availability of resources in the marketplace. And, you know, we looked and we found some really good people. We found some great developers, but we didn't feel like we could find a cohesive team that we felt could take us to the end zone, could help us build this big thing. So then we ended up looking, you know, we were in contact with Acquia and Media Current and ended up choosing Media Current because they were able to deliver a large team that could be there for us and cover all the different aspects of Drupal, things that we didn't have the skills to do and didn't really have, you know, frankly, have time to learn ourselves. So we established that team and then we had to have a kick-ass Drupal architect. And luckily, we found Jason. And, oh, thanks. And then we also have an internal team. So, you know, Media Current is kind of the Drupal arm for the project. And we established an internal team of about seven or eight people that help identify all the different pieces and parts of the current infrastructure that we need to replace and help bridge the gap for data migrations and, you know, new functionality that we want to build. And largely work closely with Media Current on a daily basis, even when they're not in my office, which is another problem, but that's okay. And through that relationship between the two teams, we've been very successful and made a lot of progress. And then we just start building. So what made Drupal a better fit for us? You know, open source rocks. I think most of you would all agree with that. The Weather Channel has longly been, long time been a supporter of open source. Our entire current infrastructure that we use today for web serving is open source, except ironically for the part that we most want to replace our content management system, which is not. So going with an open source solution was extremely, you know, attractive to us because we've got a lot of experience with open source. We know what open source can bring to the table. We know that there's a community behind it. We know that it's going to be there and it's going to grow. And if for some reason the community abandons it, we can grow it ourselves. At least our investment is always going to be secured. The fact that Media Current is local was a big help. You know, Media Current operates on a model where, you know, folks are scattered around the country so they can best attract their different customers as best they can. And we've got, in Atlanta, they've got a large group of people that are, you know, very accessible to us and spend a lot of time with us. So having a local vendor was really, really helpful. We didn't want to engage a company that was 500 miles away that we never got to see them. And, you know, Google Hangouts are great, but seriously, I need some bodies in front of me that I can touch and feel. Not inappropriately, though. The scorecard screamed Drupal to us. I mean, when we already mentioned it, the scorecard said, Drupal's your choice. That's what you've got to use and that's what we used. And what the hell? Drupal's free, so why not use it? I mean, some of the other products we looked at, half a million dollars, a million dollar license fees. I mean, Drupal hasn't been free to implement because we still have to build it, but even if we were to choose one of these third-party tools, we'd still have to spend a million dollars on building the product to our needs. So, big benefits there. So, test drive. Somewhere along the lines, we decided that, you know, our content entry solution was painful. Our VP of content entry was complaining constantly about problems that we're having entering article content. Jason will go into more details of some of the pains that they suffered. So, we decided that we would try to implement, take Drupal and do a side project and implement content entry on Drupal to plug into our current web delivery hardware or web delivery framework. And we called that project DICE, Drupal Interim Content Entry. It's been live since May of last year. It's been extremely successful. From the day that we launched it, content velocity has gone through the roof. Multiple tools consolidated into a single tool. The users are happy. As happy as a content entry team could actually be, they were happy. And our support went to almost nil. I mean, our current content management system and our implementation, constant problems, lots of inflexibility, lots of maintenance problems and drag on our team, keeping us from actually building new things. So, support went to nothing. So, it was a big, big, big win. And the side effect was it gave us some early unexpected validation that Drupal was, in fact, the right choice. So, what will be the impact of the introduction to Drupal? I already mentioned consolidating multiple systems into the Drupal framework. Image management, Jason will talk about that in a minute. Image management was always a big issue for us. We were able to consolidate that tightly into Drupal, slideshows and image uploads. Amazing increase in velocity by the team. Tight integration of page building and page serving. At one point we thought that was a bad thing. And we're still going to be slightly segregated because of our use of VSI and cash ability. And Jason will talk about that in a minute. But we feel really comfortable with the way Drupal handles pages and consolidates that in its web framework. And ultimately gives us more agility and creating solutions. We can build products faster with some of the technology we're going to talk about in a minute. So, we can rapidly build products, make quick changes as the needs of our product, as our product team, you know, frequently changes. Right, Krista? Also, and then we already mentioned stability, you know, much, much more stability, which ultimately gives us more time to actually build new things. So, the advantage is Drupal brought to the things that we just talked about. Drupal uses a standard stack. That means that we are not supporting the Java here. We're not supporting scale there. We're not supporting, you know, this environment, that environment, six environments. We're all on a single stack for every integrated portion of the site that they actually want to use. It's got a robust API. So, when it comes to changing requirements, which by the way, just like the weather, the only thing you can count on changing is requirements. But um, yeah, I'm going to get a really terrible audience. Because of the robust API, when things did change, when there was a pivot in requirements, we didn't have to, you know, go right back to the drawing board. We were able to, you know, re-adapt. We, when we architected, we architected in a way that it was easy to take this piece, replace it with that piece, take this piece, replace it with that. Drupal made that process a lot simpler. So, um, the, excuse me, the number one challenge that we were faced with was retiring or integrating, if possible, a lot of the legacy platforms. There's also a transitional period that has to be addressed for which we have to support both. We needed to simplify the content entry and we needed to increase feature velocity. So let's talk about how we do that a bit. So we, under the legacy platform, we had an article management system, an image management system and a slideshow management system. They were written by three different people at three different times and do not integrate very well at all. When somebody wanted to create an article, they'd open up the article platform, write a few paragraphs, close it, load up the image system, create a couple of assets, save the asset IDs to a notepad, close the image system, open the slideshow system, copy the asset IDs out of the notepad into the slideshow system, close the slideshow system, open the article, take out a notepad, all the asset IDs posted in there, publish the article, save the article, deploy the article. Can you go through that again, please? Yes. Later. What we were able to do was, yeah, the launch went that well too. Bam. Yeah, bam. So we were able to integrate the image management system, the article management system and the slideshow management system with off-the-shelf components for the most part. The legacy migration content that was just basically after Save Hooks that we implemented that updated the legacy platform so we could migrate easily. The systems we weren't able to integrate directly into Drupal, such as video management, because of the timeline it was too complex, we abstracted them through a web services interface so that when it's retired at a later time, we just match the RESTful interface and everything works as before. It's transparent. So Drupal's good at this kind of thing. This is a kind of diagram I bring up to tell you how good Drupal is at wrapping other services. The canonical example is when Facebook released their API, within 24 hours Drupal had a Facebook module that allowed you to wrap and put Facebook content on your site. Media Current in particular is a big contributor to the open source and modules. I think that most, oops, almost all of these marketing automation modules are created by Media Current in particular. Sounds like you might be bragging a little. Hala. So some of the, we already mentioned earlier some of the problems we've got caching was one of the top problems. With caching, low cash efficiency equals more hits back to your origin servers. When more traffic comes back to origin, you need more servers. More servers equals higher costs to operate and maintain, which is generally a bad thing. Without good cashability, you have to highly anticipate the traffic spikes and be fully scaled or highly scaled at all times, which is what we're doing today. So traditionally, when you're dealing with a lot of traffic from various places around the world, you just let it hit origin and that's not a problem. But when you get a lot of traffic, the server can't keep up. So what you'll do is you'll just introduce a caching layer, something like Akamai. And so when the first request comes through, it hits Akamai, Akamai gets it, saves it, and every future request just goes to Akamai. Origin is happy, sitting there idle and you're not paying huge operational costs for a whole room full of servers. However, whether or channel poses some unique challenges. This is what you might see if you visited from Austin, Texas. You'll get that forecast. But if you're just a couple miles away or three hours as I am intimately familiar with the drive, you will get a different forecast, which means on a regional basis you're getting completely different pages, which means your cashability breaks down on regional lines. And we're talking about zip codes and even smaller subdivisions. If you have a large enough yard, you could be in the front in the backyard and get two completely different pages. So how did we address this particular challenge? What we do, we break the page up into pieces and then we move to a service oriented architecture and we use client side rendering. I'll talk more about what that means. We also use edge side includes to rewrite the page at the edge. And all these things together let us improve our cash efficiency. That means that we can hopefully deliver one page and have it appear differently for everybody who visits. So here's how we did it. I'm going to explain what Akamai and edge side includes are. I apologize for what you're getting ready to see. Let's say you're a veterinary office and one of the services you perform for the community is you post lost dog posters. So what you'll be doing is somebody will bring you a photo of their dog, you'll go all the way to the large format printer, get the large format printed versions of it, come back to your office and give them the poster and you'll do this over and over and over and over again. So 90 percent of your time is spent going back to the printing office and coming back. You don't have to do it that way. What might make more sense is to take the reusable portions of the page, go to the large format printer and print say 10,000 copies and put them in a literal cache in the corner. This is what Akamai does for us. So that blank spot, we have a regular printer in our office that can print photos that size. So that means we don't have to go anywhere. We can spend more of our time doing the stuff we're efficient at. So we take the photo, we paste it in there and then we deploy them all over the office. That blank space that we fill, that's the equivalent of what edge side includes do for us. So you can see how that might come in handy when we're building the page. So what we do is we divide the pages up into the pieces that align with those buckets that we just described. First, they're the heavy services, page layout, asset metadata, such as image URL, article body, things like that. Things that don't change very often but are very heavy to get. Drupal, despite all of its benefits, is a little bit heavy as an app server. So then we've got the heavy services that are actually reused fairly frequently. Related content, featured content, menus, things like the title menu that appears at the top of the page. You got 60,000 assets out there, articles, and you want to make a change to the header menu. You don't want to invalidate the cache for all 60k. So you put it in an edge side include and spit it out. Thin services, these are things that change very rapidly and are very unique on a per user basis. These are the things that you might use a caching layer or a services layer for, that we would have something other than Drupal that is thinner and a lot easier to scale. We're talking about using Drupal for the heavy services. We'll just deliver the base page outright. We'll use Angular and ESI to deliver some of these moderately dynamic pages and we'll use Angular and a data caching layer to deliver the thin services. So again, what we do is we take the page, look at the parts that change, turn those into modules, and then we create a system that will render those modules based on our particular needs. TTL of five days at the top, let's make that an ESI. TTL of one minute for the forecast, let's make that an Angular module. So just to summarize, we take the page, deliver the base page with the placeholders for the widgets, put the information that's relevant to on a per user basis into our data services cache. We use ESI and Angular to rewrite the page as it goes out to the user's browser, and so the user from Houston and the user from Texas can get personalized pages, but Drupal only ever delivers one. So from this perspective, the app server does very little work. All the rest of the magic is happening at Akamai and in the thin services, which are far easier to scale. So we've already mentioned the data services layer a couple times, specifically as one of the critical components of the overall infrastructure reboot. The data services, when we decided we needed to build that, we knew we were going to need something that had, you know, thin services, a thin, restful API, one that was easily adaptable, easily that could track with the feature requests that are created from the company. So as new features are requested, we need new data, we need data to provide those features. We have to build the front end functionality to present it, but we got to get the data first. So we needed a system that we could work closely with, the teams could work closely with, so that we could be working in unison, building these products. You know, we built it using MongoDB and Scala, functional language, state-of-the-art type technology, delivering data through JSON, key value type data. It's been live for quite some time. We're already using it on our mobile apps. If you've downloaded our new mobile app, if you haven't yet, you need to go ahead and do that. The mobile app is using our data services layer live today, and we are building on top of that with Drupal. So in support of the needing high cashability, we're moving to a client side model. So we mentioned earlier that we've got about 144 servers running our site. Our current plan is to run them, to run our site with about 15 or 16 servers in the cloud, so that we can ramp up if we need it, but hopefully with our cashability and the cash rates that we're going to be getting out of our different cash layers and with Akamai, we hope that we can operate at that level. But the client side model is based on AngularJS. If those of you are not familiar with AngularJS, it's a JavaScript framework created by Google. If you haven't heard of AngularJS, I'm sure you've heard of jQuery, same kind of thing. But it's a model view controller and NBC type product, allows separation of presentation and data access, gives great flexibility in building functionality for the web. We use it with our mechanism for building AngularJS modules. We try to build our directive, my boss's directive, is to build modules that are completely responsive where it makes sense. So I can build a module, a current conditions module that works on a big web page and a mobile web page. But if I have to go through great links to make it responsive, to make it worth the cross post, then we may build two modules. But AngularJS gives us that granularity or that flexibility to be able to build in the way that we need to build it. The client side model also, the cornerstone of it, is highly cashable templates. Jason's already mentioned the templates previously that had the blue boxes. Drupal publishes the base page one time. It gets cash for maybe whatever that TTL might be. And the AngularJS, the modules that are on the page dynamically pull data and push that load down to the browser so that we have fewer hits back to origin. The AngularJS, we already talked about this, already calls our data services layer. And within the data services layer, I'm sorry, within the Angular module, the data component of the Angular module, we also cash the data there as well. So if you're cruising through six web pages on our site and in one page, you make a call to the data services layer and get current condition data or forecast data, we'll cash that in the browser, we'll cash that in the model of the Angular, so we don't have to go back to the data services layer to get refreshed data when we know that that data has not expired. So it makes the pages very quick, it makes the modules very fast to load. So additionally, we already talked a little bit about content entry. Content entry has always been a big problem because we're trying to become, you know, one of our forests is a storytelling and we do a lot of that storytelling through writing compelling articles that have some meaning to a wide variety of people. In order to do that, you've got to be able to rapidly create those articles and you need to be able to create those articles that have some something that's more engaging than just a wall of text. So we try to build the articles as much as possible including rich media, videos, imagery, slideshows, YouTube videos, we can insert Twitter feeds, we can do, there's like 13 different types of rich media that we can bring into an article to make it less boring as if it were not there. But ultimately we have to do it in a way that articles cross-platform. We can build an article, we can write an article that works on big web all day long, that's awesome, but the guy that's on the mobile website, if he can't see that article then you know we're not covering all of our bases. So the articles have to be written and created in such a way that it works across all our sites, our mobile web, our big web, our mobile web and our mobile apps. So here's an example of what this looks like. Again what we're trying to do is make it so that the front-end team doesn't have to write HTML or JavaScript to put rich media in the page. We also don't want to copy and paste some embed code from some other site that may work today but not work tomorrow. We want to retain control over that because not only do we want to make sure that whatever is being used is up to date, but we want to make sure that it maintains a look and feel appropriate for whatever device it's going towards. So what we've done is we use the WYSIWYG editor which you may be familiar with using in Drupal and we have added a couple of buttons here dynamically. These buttons represent the types of weather nodes that they're able to add to the body. So in this case we've got an image weather node and a video weather node. Now of course those aren't the actual image that just represents the placeholder for it. When you click the button bar you'll get a pop-up. This one's for say YouTube I think. So in this case they're adding a video of fish with teeth relevant to the weather. And what we've simplified the interface so that the the user only sees what they're supposed to see. This is also limited by user role. So an administrator may see more options than a regular content editor. So one of the ways that we were able to get this flexibility is because this model that you see here this is actually a content type create form. This is an actual node. So for those of you familiar with Drupal. So this is actually a weather node YouTube content type. So after the user creates this it just goes ahead and dumps it in the article body. Right so then in the screen to my left you see four basic presentations. You see a big web presentation, a tablet presentation, a mobile web presentation and a data feed. Down below the bottom you see the raw article body. It should look somewhat familiar as the WYSIWYG article editor for Drupal. What are you seeing? No I want to see how much time I have. Okay we have about 10 minutes. Down below you see the actual article body. And then we insert a in this case we insert a YouTube weather node, Wix node as Jason calls it, into the article body and above you see the different presentations of the different platforms. On big web you might see a immersive type embed player for the YouTube video. On the tablet you might see something a little bit different maybe something that's a little more of an embed type placement. And on mobile web you see maybe a smaller version of that, a smaller image. And over on the right in the data feed you might see an XML excerpt that some platform that would be consuming that data would then take that XML data to use to present that weather node that that YouTube video and their platform in the way it's appropriate for their platform. So as I said before the weather nodes, they are full-featured nodes, they're first-class entities. They're really nodes with benefits because these are nodes that can be used within the button bar. What is it? They're trackable. There must be some insinuation from that that I don't get. They're trackable, flexible so you can use them in multiple places. They can stand alone as full-first-class entities. That YouTube video exists on the site. You can use it for a number of things. You might just drop it into a feed somewhere as it is. So to kind of drive home the point here's that button bar again. You can see the YouTube one. There's an external image, internal image, Twitter, and here are the content types that represent them. Now this is where I can really go off the rails in terms of deep technical detail. Do not go off the rails. I've decided I'm not going to go off the rails on deep technical detail. Good call. Right then. So we have Wix node entities, the first-class entities. Those are nodes. We have tokens in the article body as you saw represented by those little short images. And we want to manage the presentations of them. We want to have it present differently whether you're viewing on the big web, mobile, desktop, iPhone lab landscape, or maybe even in an XML feed. So what we did for that, skipping technical details. Alright so one of the critical parts of actually carrying out the page serving is the creation of the presentation framework. And Jason architected the presentation framework. Basically it's a mechanism for allowing us to put modules on a page. Those modules can be angular modules, they can be PHP modules, they can be inline code, but effectively gives us the ability to serve them either statically being served by Drupal or being served by an ESI depending on what the use case is and what the hit is back to origin. One of the main benefits is simplifying the creation of modules for the functionality that we're trying to build rapidly. If our developers are, their core language is AngularJS and their focus is building on AngularJS modules. They can build their AngularJS, talking to our data services layer, they can build it rapidly in their own environment, in their test environment, and they can do it without knowing a whole lot about Drupal. So we can leverage, we're able to leverage a lot of our existing talent because we have a lot of strong JavaScript, HGML, and CSS people. So it's simplified a little bit of the creation process because we didn't have to go hard a bunch of PHP developers, not that there's anything wrong with that. It's just we didn't have any of them. So AngularJS makes that easier for us and the presentation framework supports that natively. So again I just wanted to summarize what we've all gone through. We have little panels, those little widgets we talked about. These are these widgets that are on this page, they're outlined in blue and red. These are actually presentation framework modules. The presentation framework system was built to serve these. So it basically creates panel panes that are also just independently renderable. They're reusable, exportable, that is to say you can deploy them and get them. So as part of the panel, when you're doing your layouts, you build a seasonal page say, you can export that as a feature, reuse it next year. So each of them is independent, so that means they all have their own configuration. So a panel serializes it with it so it goes out with the feature. And their version. So if it happens that, and this is a point I'm not sure we made very clearly, but the development team that's actually creating the presentation framework modules, that's the weather channel team and they're doing this using straight HTML, JavaScript and an info file in JSON. So these are really straightforward modules to build and they want to be able to build a lot of them. So they're independently versioned because let's say that there's a forecast module that we later on decide we want to add a title to, well all the extant versions need to be updated or we have to write code that acknowledges that the old versions exist. So we track where all the modules are used, we have a thing that tells you how often some things used to kind of get popularity and maybe feed into metrics. So last slide before I skip ahead again, but each of the modules are just a single folder that contains details about how the system works. The JSON file indicates whether or not this particular module is going to be delivering using ESI or if it's going to be using Angular or if it's going to be just displayed static. The template files, the tipple flips, can be PHP template so you can put code in there though it's strongly discouraged for obvious reasons. So just to summarize, we have the article body, they click a button, they get a pop-up that allows them to choose a YouTube video say, enter a little bit of details, they save it, enters the article body and it's available for presentation differently on all the various outputs that we have. All right, so page building is big. Before we can actually, you know, present something to our end users, we have to have a page and today our current page building process is not horrible. It's similar to how we do it with Drupal in that there's modules, we put modules on the page, but it's not near as flexible and not quite, doesn't support the rapid page building that we need. Currently our system doesn't really handle the many templates that we have, they're hard to track, they're hard to, they're hard to find, they're hard to reuse, it's just not a very efficient system for, you know, a highly optimized team. We need URL parity across all of our platforms, we don't have that today. Partly because of our current content management system, but partly because of the legacy technical debt that we have that we're trying to get rid of. Drupal gives that to us, it provides a mechanism to give us URL parity across big web, mobile web, and even when we bring our international properties into our Drupal, we should be able to do the same. And then our current environment, it's an inflexible layout, it's an inflexible layout, the, what happens when you try to drag a module and you need to configure it, the configurability of it is really painful and you have little to no control over setting parameters, controlling how that module is going to behave on the page. So we wanted to have a mechanism that we could easily configure a module, we could use a single module for a current condition module in three places and make that module behave differently in those three places, and in all three places without having to have three different modules. And we need a flexibility in how those modules are configured. And Drupal gives us a lot of flexibility in how we do that where our current system does not. So one of the ways we address all those requirements, we use a system called panels, a lot of you probably familiar with it, familiar with Drupal. It is a very intimidating system at first, but once you get through the training, it is a very powerful and flexible framework. And what we are using for in our case is it allows us to group a lot of the related variants of a page. So for example, we are talking about a forecast page, there may be a variant that exists for big web, there may be a variant for mobile web, it may have a different layout if the site is in severe mode versus not. There may also be a situation where we deliver a 404 page with a specific type of layout. So that gives us simpler management of those various aspects. In the past, you would have had to go to a completely different place, maybe search for the page layout, maybe edit it in HTML or JSP. We don't necessarily want to expose people to that pain. The other thing is we get to better reuse those variants. Once we built something once, we can clone it and reuse it on other pages. So let me give you an example of the type of layout we have available to us. Wow, nothing guys. You are already asleep. So we gave the Weather Channel a series of layouts. These are basically nine layouts that we gave them. And this might be considered inflexible if we didn't give them also the ability to modify the layout within it. So you can see here, this is something to break from what you might get a normal panels interface. We have a single row, but we have two widgets side by side. The way we did that, we introduced a module called Classy Panels. And what Classy Panels does is it allows you to change settings by saying that for this particular pain, we want it to be 50% width or 33% width, and it will automatically acclimate to the size of the container. So here's an example of it in use. Go ahead and set that to 33% width, and boom, we can drag it from one section to another, and then instant layout happiness. So variance. One of the benefits of panels is it gives us the ability to choose variance. So largely provides our capability for doing URL parity, but also providing different pages for the same URL for different conditions, different contexts. That context might be a different device. It could be mobile web over big web. It could be a severe weather situation versus a non-severe situation. But other types of rule, any type of rule that we might need to configure in the future, a sponsorship maybe, can allow us for that same URL to show a different page variant, which creates an extremely flexible solution for presenting pages to the user. So the context to what they're doing and where they're at, and the conditions that are going on and where they're at, is highly taken into consideration. All right, so we're able to use selection rules in panels and what those selection rules are. They're basically UI-driven, well, selection rules. They allow you to choose what basis particular variants are chosen. So here's a use case. We have these six layouts for, say, a forecast page. If we are looking at the forecast page for a location we know exists, we don't need the 404 versions of it. And if we're visiting from a big web versus a mobile browser, we don't need the mobile variants. And if we know the weather is in severe mode, we'll use the severe variant. And so the selection rules drive which layout is actually delivered, and then Drupal has made the page generation process simpler. So what's next? Jason's been promising me a continuous integration environment for a while, so I think we're getting close to getting that in place. Right, Jason? I'm continuously promising it. Yeah. Performance testing. We're a long way into the project. We hope to have a launch this year. If we don't, we're all fired. But performance testing is really big and we hope to get in that in the next couple of months. Still have some functionality to build, but we feel confident that we can take care of it this year. So a number of contrib modules have come out of this. These are the ones that are probably worth the most attention. We discussed these modules during the presentation. Custom or classy panel styles, that was one we developed, that allowed you to change the way the layout worked within the pre-existing layouts. There's actually going to be a power session on this a little bit later. Derek Drafts and Kendall Tottener delivering it together. It'll be at the media current booth. Wixnode framework, that is to say the one that allowed you to drop rich media elements into the article body, that's becoming Wizzy Field, and that's already in Sandbox. That'll be made available soon. I'll put it in the presentation notes. I didn't have the Sandbox URL available to me. And the presentation framework has a little bit more work to be done before it's rounded out enough to be a generic module. There are too many weather channel specific things in there. So that one's coming up as well. And these will be really great additions to the Drupal community. Thank you. Before we take any questions, I do want to thank, I give them a hard time, but we've really enjoyed our relationship with media current. And I want to thank Jason and Dave and all the other media current guys and also Acquia. Acquia has been a great partner with us from the day that we started this, helping us with high level architectural decisions and really guiding us through this. So thanks to both media current and Acquia for their guidance along the way. Also, our friends at NBCU, big help in mentoring us early on to kind of push us in this direction and make sure that we're validating again that we're making the right decision. So we have a mic in the back if there's any questions. What is your content deployment strategy going to be like with so many different articles? Are you deploying from stage to prod? Are your people directly on production? Could you talk about that for a little bit? One of you. Yeah, the article of creation is actually going to happen on a production instance. So the articles will be made available. The reason for this is that the delay between that comes from moving from a staging environment to production environment and the benefits that they get from it was not worth the effort. The articles are also fairly volatile. It's okay if we lose one or two. The ones that are evergreen, those are stored. Do you have any concerns about having a cold cash when you do clear the cash on production? No. How come? Part of our process is we are going to be writing some, what do you call it? The cash crawler? The six-primer. No, no, no. Where were you prime the cash? Cash primers? Yeah, cash primers. So yeah, and the cash priming will be easier because, of course, Drupal manages all the assets and we're going to have a system set up that parallelizes the priming. So, thank you. For the section you're embedding the information, the rich media, are you actually embedding some sort of token into the body field? How is that? Yeah, it is actually, it is a token, but it's not a token API token. And the reason for that is that token API does some things that we wanted to do a little bit differently. We wanted more control over the end to end. And so we use our own token. We use hook filter info to declare a filter processor and we process it on presentation. Does that answer the question? Yeah. A question for Chris. Do you have any colleagues in media or in tech who questioned or continue to question your decision for Drupal? Not really. Yeah, just me. No, not really. I mean, we, like I said, we've at least in, you know, inside the Weather Channel, surprisingly, we were not questioned at all, largely because of our supportive open source for a long time. Outside of the Weather Channel, I've not read, we've not really, you know, broadcasted what we're doing, so to speak. So there's not really been, I guess, an avenue for people to tell us that we're crazy for going that route. But we have a tendency to do what we want anyway, so we really don't care. But no, to answer your question, we've not heard any negatives about this decision. So I saw you had sort of preview images, maybe just on your slides between the different, like big web mobile layouts and so on. Do you have any sort of preview tool for content editors to see what it's going to look like in different contexts? So we're using publication status and the ability to view unpublished versus published articles and the way that the firewalls are basically built up to do previewing. We started on a process of enhancing the built in panels preview system. But given the amount of effort it looked like that was going to take, we stuck with the presentation. So with how you use an Angular, it seems like you've probably got a few round trips before all your contents fully loaded. Have you guys had difficulties or seen complaints around that? No, we've done a couple of tests. But the key thing that I think of what you're getting at is that every one of the Angular modules is going to do its own request. And in actual fact, the many of the requests are of a similar type and the queries are built to be aggregatable. So you can do a single query and get aggregate results. So there's an abstraction layer between the Angular modules and the service calls. And that manages how many calls actually get made. So if you're requesting six articles, it requests all six from a single request rather than six round trips. Now that is that there still are a number of round trips that happen in Angular. But the way the page is built we're minimizing the impact of it. Again, it all goes back to the cacheability, cacheability of the data in the browser itself on the client, cacheability of the data, the data services layer at Akamai, caching of the page template. There's so much caching involved that we obviously wanted to reduce as much as possible the hits back on Drupal. Because we don't want to have to load every page that comes to our site loaded out of a database. By the different layers of cacheability, we're confident that it will give us the performance that we need. Even though you're right, there are a lot of hits outside that on that page going to our data services layer. But the testing we've done has shown that it will be performant. When you talk about the data services layer, is that completely external from Drupal and then you just bring in that data at the time of rendering? Yeah, it's a completely separate system that was built with Scala on MongoDB. And it's kind of a, almost a data warehouse of data that comes from multiple sources, disparate sources from our weather forecasting data. We push all of our article content into it. And it basically pushes it out of the cloud. RESTful API into that has no touch points with Drupal whatsoever other than the calls that we make to it. And Drupal pushes content into it? Yeah, Drupal pushes the article content into it, for sure. Yeah, the idea behind the data services layers that it's, basically it's a really powerful key value store. And as you know, key value stores are very easy to scale. So this took the most traffic demanding part of the entire equation and made it a lot simpler to manage. And the group that works on that data services layer just go a little bit deeper since you asked about it. We sit right beside them. We've got web developers, our core reboot team, and the group that builds that data services layer. So we're all, we could reach out and again touch each other. So we're very close. And though we're not in production with this platform yet, the idea is that once we go into production as new products are requested by our product teams and the developers decide, work with that backend data services group to figure out what data we need. We work closely together to provide the services that we need if they don't already exist. A lot of cases they might not already exist. So we feel it'll be a very rapid type relationship. Any other questions? I go use the mic when I'm really lazy. Did you have any problems with data migration and any challenges that you could speak about? What he said was that he was really lazy and he thoroughly enjoyed the presentation. Thank you. Yeah, we have had a lot of data migration problems, not necessarily because of data migration problems, but because we've changed our minds several times on how, you know, what we want the data to look like. Specifically, one of the areas that was kind of a pain was on the weather nodes. We changed a lot of the formats and how we wanted them to work. So they could, when they originally built, they were built to work with our website. And that's it. They weren't built to work with our mobile website and how they were structured and the way the fields were named and all that. We also have a lot of data with images and videos and just lots and lots and lots of data. And trying to make sure that we do the right things with that data, bring it over in the right way that fully maximizes SEO, cagarization. It's been a real pain. And frankly, one of the harder things that we've done on this project. So great question. But yeah, it was, it's, we're not 100% there yet. We've made, you know, we're probably 80%, 80, 85% done with our data migrations. We had to do some data migrations when we did our original Drupal content entry solution because we had to bring a bunch of data over. But we're rebuilding all that with our reboot project. We've got most of it done, but it has been kind of painful. Any other questions? All right, thank you. You mentioned SEO. Moving to client-side rendering, since we're offering SEO for SEO strategy, exactly what you're using for the content that's molded with SEO? Yeah, the strategy primarily revolves around Phantom.js. So we're doing Phantom.js to help provide a lot of that. And just in case it wasn't captured, the question is what was our response to SEO problems rising from rewriting the page in JavaScript. Yeah. And just, you know, anecdotally, I don't know if anyone's read the article, but Google now has announced that they're gonna start, when they're doing their crawling, they're gonna start rendering the page more like a browser and actually executing the JavaScript. We're not 100% sure if that's gonna give us the SEO lift that we need, but potentially could drastically reduce our need for Phantom.js. This literally happened last week or week before last. So it's late-breaking news, but good news nonetheless. So the question was, can we talk a little bit more about how we're managing images? You want me to take this one or two? I'll handle it. So we're doing it differently today. The way we're doing it with, if I'll leave anything up, you can fill in. The way we're handling images today with our interim content entry solution is different than the way we're doing it in our new platform. Today, in our current platform, since it has to work with our existing web-serving practical platform, we're storing, we're using the same images that have always been there. We just import the metadata and we're tracking them in Drupal after we did the data imports. In the future, what's happening is images will get loaded into Drupal through normal upload functionality, just like we're doing today. And we're storing the metadata for those images, pushing those mezzanine images to S3 and AWS. And our data services engine has a mechanism, a service that will provide image cutting for us. So once we push those mezzanine images into the data services layer, as the different clients need images for pages or articles or whatever, they can make a call and grab that image. I don't think we need it, right? Does that answer the question? We're managing the metadata. So the searching and applying images to articles and using images in our media modules and content surfacing inside Drupal through that interface is using that image metadata, but Drupal is not housing the actual images. Well, the mezzanines it is, sort of. So we're using a media module, StorageAPI, and the images are stored as file entities. StorageAPI is delivering them in S3, including the mezzanines. So it basically keeps track of where they're being stored. When they're requested, they're actually pulled from S3, re-sliced and delivered locally. But in the case of things, and then cached. And then cached, yeah. Thank you. Thank you.