 Hey, how's it going, folks? My name is Alex Ogheb. And for the last eight years, I've been working with EA as a technical director. And I'm here today to share a story of how web components and Polymer has really facilitated a monumental transformation of web at EA, from the dark ages of building one-off pages and transient sites to the blissful world of reusable components and a rich, engaging player experiences. So before we dig in, I'd like to set the stage briefly about EA's place in the world. We are a gaming company that is driven by our core purpose and values to inspire the world to play and to be the world's greatest games company. We deliver on this purpose by being organized into this concept of studios, such as Bioware, DICE, and EA Sports, to name a few. These 22 studios are comprised of approximately 10,000 people in 30 locations worldwide. Each studio has one or more franchises. And a franchise is kind of like a movie series. Each game in a franchise is usually a bit of a different story, characters, et cetera, but generally follows some consistent thematic elements or overall base fiction. Many of you have heard of franchises such as Dragon Age, Mass Effect, Battlefield, and FIFA. EA's player-facing web is managed and delivered for the most part in a centralized model by about the 100-person team that I work with, Pulse. Through this centralization model, we can achieve efficiency through economy of scale and our efforts, and overall just ensure an engaging and consistent experience across that diverse EA ecosystem. This means that our group must meet the needs of those 22 studios totaling over 50 franchises that release 20-plus games to our players every year. So today I'd like to go over three topics. First, our journey and decision-making process of kind of how we ended up with web components and Polymer. Second, an overview of the design system and component library we've created over the last two years. And last, some highlights of how we've been applying this design system and how it's been a huge win for EA and our players. So let's start with the story of how we landed with web components. So we need to go back about two and a half years, so basically a decade in front-end world, to February 2015 when we really started our journey with web components and Polymer. EA's approach to web was very different back then. We embodied Conway's law to the fullest in how we delivered our disjointed web ecosystem. And for the most part, we designed and developed EA's web more like an internal agency, one project, one site at a time. This siloed and disjointed web was really a sad place for our players. And equally a sad place for our designers and developers, too. We were spending 80% of our time on commodity web, such as navigation, footers, news articles, media galleries, video player, pre-order and by-page, leaving only a fraction of our time to innovate, excite, and engage our players with custom game-specific experiences. So naturally, in the world we wanted to live in, we would flip this allocation of time and focus around and spend the majority of our time on the fine-engaging stuff instead. So we started really thinking and talking about, OK, how do we get from this 80-20 bad to this 80-20 good? And voila, the network design system project was born. Project name aside, this is really about applying well-known concepts of a design system, a pattern library, or a UI framework to how we did web. The idea was that by having all of our team members, from product managers, to designers, to developers, to QA, embracing the complexity of the web with a component-based approach, we could drive efficiency and make our commodity core web features turnkey. But before we started to hit the keyboard, we took an introspective look at ourselves. What other requirements, needs, wants did we have beyond those of a standard component-based design system? What special challenges did our contacts bring to the table? In the end, our special needs and wants for the NDS distilled down to these four items. Number one, to facilitate deep theming capabilities, to work with any language and any framework, to support our micro-site architecture, and to deliver user interface as a service. So let's look at these each in more detail, starting with facilitating deep theming capabilities. Now ideally, we would have a solution that worked with our entire spectrum of branding and theming needs, from one extreme being the broad out-of-the-box kind of EA corporate brand, to the opposing extreme, being one that is heavily themed in a very focused and specific manner for a single game. And in some cases, meeting the very stringent style guide requirements and approvals from a licensor, such as the cases with Lucasfilm for the Star Wars franchise. OK, number two, let's talk about our desire for this solution to be language and framework agnostic. Recall, this is early 2015 still. And our group at that time was the result of several internal team mergers and reshuffles. And as an outcome, we had a plethora of technologies, languages, and paradigms in play, from frameworks and libraries, such as Drupal, Symphony, Grail, Spring, Angular, DropWizard, and even JQuery, to languages including PHP, Java, and Groovy. And content management systems, such as Adobe Experience Manager, Vignette, and El Fresco. We had technology divergence. So unsure where we would end up with our stack in the future, we didn't want to get locked in with any one particular back end or front end framework and language. This must work for the unknown future us as well as the rest of EA. So all right, number three, our micro site architecture. We had, and to some extent still have, many discrete web applications that have their own lifecycle, teams, budgets, et cetera, but are assembled together to be perceived as kind of one single cohesive player experience. What this means is that some design elements, such as global navigation, responsive UI breakpoints and grid, login flow, pre-order page, need to be centrally controlled and consistent across all of our sites, whilst other design elements can be more customized for each site. OK, last up, number four, user interface as a service. So given this micro site architecture, how do we avoid projects that aren't being actively developed from falling behind and getting out of sync with the rest of the EA ecosystem? How do we keep all the projects pointing to the latest version of this design system with minimal effort by delivering our UI conceptually as a live service? We hope to address these issues and really embody the mindset of leave no site behind. OK, so given our goals to build this component-based network design system coupled with our four special needs, where do we start? I mean, what's the approach? The architecture, the systems, the tech, the tools. I mean, there's a lot of questions. So just like the purple pattern states, unlike any developer should be, I am lazy. There's so much out there, and there's so many people to learn and leverage from. So we begun reading, listening, experimenting with, and consuming anything and everything we could possibly get our eyeballs, ears, and hands on in regards to the topic of style guides, design systems, and UI frameworks. Serendipitously, a new podcast from styleguides.io was out and posting fresh episodes on this topic right around the time of really 2015. What a bonus. So I'd like to talk about three particular paradigms and systems that were quite inspirational and key to our path to web components. Bootstrap and friends, Lonely Planet, and the government of the UK. Starting with the ever-popular Bootstrap and more generally UI frameworks that follow the same approach. So here's a simplified example of what integration of a Bootstrap-like component library might look like. You include a pre-bundled CSS and JavaScript file from some CDN location. And off you go, using the components the system provides. Seems easy, seems awesome, seems good, right? So let's use this pagination component as an example. It's a good one because it has some reasonably complex UI, different states, some brains inside, and it really needs to interact with other components and code to actually do something that's meaningful. So let's see how we integrate this component. We start by going to the documentation for the paginator, find the sample HTML snippet, then we copy and paste this large chunk of code into our application. OK. Now, it's obviously not good from a reusability and upgradeability standpoint, as we have essentially forked this chunk of code and will now need to manually merge those updates as they come along. Additionally, there's little to no encapsulation. All of the internal structure and all the style are exposed to me as an integrator. I mean, what really is the public API? Is it all of it? So we're not done. We still need to hook up some behavior now to this pager by means of JavaScript. And this is generally completed by grabbing a reference to the root element of the component and passing it to some factory or constructor as shown here. OK, so the Bootstrap model shows us one way to do it. Let's move on to Lonely Planet and see their approach. Much like us, Lonely Planet had a microsite architecture comprised of many sites, each with their own stack and team around them, that need to work together to provide a single cohesive user experience. Their initial approach was to create a shared UI layer following the Bootstrap-like model we just explored. And in this diagram, taken out of a talk by Ian Feather of Lonely Planet, you can see the two core problems around risk and reuse depicted. The shared layer has the most reuse, but as changes here can affect all the applications that use it, risk is high when making modifications, especially without a clear API boundary. Due to this lack of API, you really don't know what people are doing with your component. So over time, engineers naturally will shy away from making changes and doing things in the shared layer because they're afraid of breaking stuff. So the shared layer shrinks and atrophies while the site-specific layers grow, basically the anti-vision of any shared component UI system. So what Lonely Planet did with their design system, dubbed RISO, was move away from the copy-paste approach by encapsulating each component into a Ruby and Rails helper that took two parameters, one being the name of the component and the second parameter being the clean and minimal set of data that that component needed to render. This is much, much better. So by implementing this component layer and API between the shared layer and the specific sites, they're able to reduce or remove the risk of making changes to those components, as well as really ease overall integration efforts significantly. So the Lonely Planet's folks really plus one the Bootstrap model with their RISO system. Naturally, this is my face after coming across RISO, so excited and essentially ready to lock in and go with this approach. But not so fast. Sometime after RISO had been humming along in production, Ian Feather put up a blog post titled What We Would Change About RISO. First, the solution was tied very tightly to Ruby on Rails and ERB templates, and hence was not portable or usable by applications that employed different languages or frameworks. He hypothesized about using mustache templates or similar to sort of mitigate that issue. Second, all of that CSS, HTML, JavaScript, and Ruby that made up RISO was bundled and integrated into each site via a Ruby gem. So each update to RISO meant you had to go through a dependency update, build, test, and release cycle to each of their 10-plus integrating sites. OK, so Lonely Planet's RISO was an excellent overall approach, clean API data-driven components. But before we move on, being Canadian all, we figured it would be a good idea to check in with the Queen over at the government of the UK. Inspired by the Lonely Planet approach, Ed Sodin, working with the government of the UK, really wanted to resolve that issue of the effort and cost of propagating those changes from the component UI layer into those integrating sites. So building on the core approach of RISO, they added the concept of a template resolver. Whereas all those ERB templates were moved out of the gem into some shared network location. And then they're lazy loaded from this location and cashed locally for a short period of time. This, combined with pre-bundling the CSS and JavaScript onto that CDN location, allowed for changes to be propagated with minimal effort to all of their apps. As you can see, the WK folks really took the already awesome Lonely Planet approach. And plus one did, big time, with the addition of that template resolver. Now, we got quite excited about this approach. It really felt like a viable option for us to start heading down. But before we dove in too deep, we went back to our four special needs just to make sure and see how things measure up. So number one, deep theming capabilities. Now, reminder, this is still early 2015. So CSS custom properties were only available in about 10% of users' browsers. OK, so I'm not sure how we can do this exactly. I guess we can figure something out. Perhaps each site can build their own CSS override file that just has the CSS rule sets that need to be modified to theme those components. OK, but what happens when we refactor some CSS or reintroduce a new component? I guess we'll need to rebuild those override files. OK, well, I mean, we've got some tools to build. I've got a process of documents and people to train. All right, number two, let's see. Working with any language, any framework. Well, I mean, we could just use mustache templates, coupled with the same WK template resolver approach. That would do the trick. We just need to build client libraries now for every language that we need to support. OK, so that's like PHP, Java, JavaScript, at minimum. And then ideally, we'd have first class integration into the front and back of frameworks that we might use. So let's see, that's at least four frameworks. Oh boy, now there's already a lot of open questions, plumbing and miscellaneous pieces to worry about here already. Now remember, I am a lazy developer. I don't want to write and maintain code if I don't have to. I really wish that there was just an off the shelf solution that I could just grab, read some docs, gives me everything I need, and one nice cohesive package. OK, so back to the drawing board. What else? What else? What else? I mean, we have designs for all our components now. We need to start getting on some code really soon. So I remember this hipster tech that was brewing for what feels like years now. Sounds cool on paper, web components, and Google Polymer, I think it was. Oh yeah, that's right. I remember there was a talk at Google I.O. in 2013. Oh yes, now I remember. A fun looking toy, terrible performance due to some nasty invasive DOM polyfills. Basically, Chrome only. I mean, way too hipster for this job. I mean, this is all of EA's web hinging on the decision. I need a solution that is ready for production at EA's scale, like today. But wait, what is this? Polymer 1.0, just released, like now. Production ready web components. Really, all right. Sounds good on first glance, backed by Google, focused around components, and not full blown applications. All right, chill out, Alex. Back to our special needs first, and let's see how things measure up. So number one, deep theming capabilities. Well, we get theming right out of the box using CSS custom properties and mixins with a shim that works everywhere. Cool. We can theme these components at runtime, too. No build step necessary. That's pretty awesome. All right, number two, working with any language, any framework. Well, I mean, it's really just an HTML element at the end of the day, and almost standard DOM interface. So hypothetically, anybody or anything that can put an HTML tag into a document could technically use our components built with Polymer. Oh, and all the CSS, HTML, and JavaScript is bundled up together into an HTML import for client-side inclusion, so no tie-in to any specific back-end or front-end language or framework. Needed, awesome. This is, like, sounding really good. All right, number three, support our microsite architecture. Well, it seems that we can control the API, however we want, on a per-component basis. So that should work well. And last up, user interface as a service. Well, it's just client-side integration. HTML import seems like it has some of the basic working pieces to make this happen. So yeah, this is looking really good. So my mind is blown at this point. An off-the-shelf solution that meets all of our special needs and lots more, tooling, docs, et cetera. Less code from my team to write makes me very happy. And bonus is that most of the gnarly parts of Polymer are promised to be native web platform primitives sometime soon, too. I mean, a framework's roadmap that states that it wants to get smaller, do less over time, and eventually may not even need to exist. I mean, that's amazing. So with Polymer, this hipster web components thing just became our top contender. So compared with the already awesome approaches of Lonely Planet and the government of the UK, web components in Polymer 1.0 was like a plus 100. So in September of 2015, we decided to officially lock in with web components and Polymer as the core technology for the network design system. Now let's fast forward two years later down our journey with web components, Polymer and the NDS. And what did we end up building? How did our four special needs sort of hold up in real life? Did web components in Polymer meet my mind blown expectations? I'm pleased to say that we have approximately 75 components that are arranged into one of six component families, which are just logical groupings of components based on their purpose. Let's look at a few examples. Starting with our most commonly used component, our call to action or button component. It's quite polymorphic and it supports different types for text, text with icons, images, and so on. And this component also comes with Google Analytics tracking out of the box, ensuring that every button on every site sends consistent and meaningful data. Next up is our pagination component, something with quite a bit more logic and state than a button. To me, this paginator really showcases the power of web components. All of that complex structure, style, and behavior are nicely encapsulated away behind this minimal, clean, declarative, and imperative API. In this example, we just simply listen to that page change event and do what we need to do with the data. We also have some very high level components that are almost like encapsulated in many applications all on their own. This newsletter sign up has various states for anonymous users, authenticated user, already signed up, as well as it provides a multi-step flow complete with error handling, localization, and integration with a few external service APIs. All right, so now with that sample of components in mind, let's review our special needs again and see how we've applied web components in Polymer to bring these two fruition. Starting with facilitating that broad spectrum of brand specificity and fidelity that we needed. Now we have about 300 CSS custom properties that are set at the system-wide level that are there to mostly control color and typography. We love that even back in 2015, when CSS custom properties were not widely available, the shim that came with Polymer 1.0 allowed us to use this powerful tool to theme dynamically at runtime with no build necessary. In fact, we now control these primarily through our content management system. So a designer and a product manager can spin up a site and theme it without any developers involved. We also have many CSS custom properties that are used as internal design tokens and are really there just to keep things dry from a development standpoint. But they should not really ever be exposed or altered by our integrators in any way. And so, you know, these are rules such as our responsive grid, gutter, and column widths. So what we do is at a build time using post-CSS, we substitute and compile in the static values for these design tokens, making them essentially immutable and leaving only the themeable CSS custom properties exposed. So this is our tile or our card component. And it's used in most places where we have a list of items to display, such as a news article, videos, characters, or weapons. And although CSS custom properties are great for granular CSS level control, using HTML attributes as another way to theme and control a component has deemed to be very powerful. The example that illustrates as well is the type attribute on this tile that has two possible values, horizontal and vertical. Using the host pseudo selector, we can have that single HTML attribute impact the entire presentation of the component from placement and size of the media asset, from margins and padding, to different layouts completely, that mobile versus desktop. All by letting CSS and the browser do all the hard work, no imperative JavaScript needed. So just by using those system-wide theme, themeable CSS custom properties, and the per-component HTML attributes, we can deliver all four of these tiles using the exact same component, all themed at runtime to boot. Okay, number two, let's talk about how the need-to-be language and framework agnostic has gone. Here's a very simplified view of our overall stack today. We have Adobe Experience Manager as our CMS in the backend, Lightben's play framework as our middleware, and of course, Polymer in the front end. Now, we have taken the approach that when we think about a component, we think about how it manifests across this entire stack, not just in the front end, ensuring that we can drag and drop a component onto a page in the CMS, pull that component into the middleware, and serve out the custom element for Polymer to then render. So for our stack, each component has first-class integration top to bottom, as an example of a button. But this does not mean that integrators must use our full stack to get the benefit of the network design system. As each layer of the stack is loosely coupled and has clear API boundaries, it's really easy to just use that front end Polymer component all on its own. No gem, no template service, client library, just a simple HTML import. Okay, so number three, our micro site architecture. So recall that some components need to be centrally controlled and consistent whilst others can be more customizable. Web Components of Polymer makes this really easy as we get to control how narrow or how broad the API is on a per-component basis. Components that we really need to be nearly 100% consistent across all sites, we just simply severely restrict the API into that component. And others that are meant to be super flexible have all sorts of knobs and switches in the form of CSS custom properties, HTML attributes, and use of slot-based composition. So our pre-order by-widget, newsletter signup, footer, network navigation are all examples of where we really keep that API minimal. Okay, last up, number four, user interface as a service. Now we apply semver very, very diligently, being super careful to keep the NDS backwards and forwards compatible with a strong focus on not bumping our major version number for as long as possible, sticking to backwards compatible changes resulting in minor version bumps only. So this mindset has worked really well as we are currently at version 1.31.0. And in practice, we could update a site from 1.2.0 to 1.31.0 without any code changes or issues. Currently, we deploy a pre-built version of the NDS to a CDN location using a naming convention as shown here. So this gives the URL meaning as to the version, the artifact type, and the artifact that's being referenced. By supporting a fuzzy version mask on the major release version, means that the site can ask for a 1.star, a 1.x, and get back a 302 that actually redirects them to the latest 1.x release, which as it is a tagged and unchanging artifact, is sent back with a very aggressive caching policy. So as you can see, our special needs have come to fruition thanks to web components and Polymer. Now, I'd like to briefly cover a few more wins and show off some of our sites. So as mentioned, we have 75 components in production. They're now powering about 30 sites in total, and that number is growing rapidly every day. On the left is EA.com, corporate site, using the out-of-the-box default theme. And on the right is a more heavily styled Titanfall 2 site, but both using the same NDS version and the same HNY import. And here are a couple more with Mass Effect on the left, and on the right, an upcoming new franchise from BioWare, Anthem. And we have gone from a previous tedious and lengthy process to bring up a site to now only taking about one and a half weeks of content only. That means no development effort. So component type thinking is really just how we operate across all functions now. We don't design and build pages anymore. We are always looking to decompose and then compose with component-based building blocks. And as a bonus to the delight of our digital intelligence team, we have been very consistent in complete analytics tracking across all of our components, allowing us to compare apples to apples between different sites. And of course, efficiency and economy of scale. We've reduced duplication. We have better engineering mobility between projects and teams. And with a predictable, proven and streamlined system, we have much, much lower project risk and a far more dependable schedule. So going back to this original goal of living in a world of making our commodity web turnkey low effort and maintainable, how have we done? I would say a resounding success thanks to web components and Polymer. Thank you very much.