 My name is Chris LaPresto. I live in the greatest city in the world. I work at EAP, where we make Ember apps that run mobile apps, that run Ember apps. Before that, I was CTO of Plythe. I play a bunch of non-computer keyboards. And you can find me at Chris LaPresto on Twitter, on GitHub, the Ember community Slack, and hopefully everywhere, because I learned my lesson when I lost out on Hotmail. Now I am not a designer, but I've worked really closely with many wonderful designers over the years. And together we found all sorts of ways to bump our heads. So I've come to care deeply about why that happens and how to prevent it. So that's why I want to talk to you about style guides. Now when people hear the term style guide, they usually think of aesthetic standards like this excellent work from the US Digital Service. You know, color palettes and fonts, buttons and forms that help create a consistent look and feel. Now most digital style guides stop here, kind of documenting at this UI element level. But today, we're gonna explore how driving development through a living style guide that looks something like this can simplify many aspects of our web design process. By presenting all of our applications components in one place, we can shorten feedback cycles simply by working with this design showcase. Now if you're familiar with other style guide projects, you may be thinking, ah, this is just more stuff to worry about and maintain. But here's where Ember comes in. Now of course, the last thing we wanna do is add something else new to our development process. You know, another meeting, another tool, a dependency on left pad. Now in the Ember ecosystem, we have fantastic tooling and conventions that help jumpstart and pull development effort. Winds accumulate when we lean into the framework. So hopefully, we can just type Ember install style guide. Well, unfortunately in this case, we are not quite there. But I have some stories I wanna share first anyway. You see, we didn't have Ember CLI in the year 2000 when Conan was ascendant on late night. This is when I built my first website. I had a band, wanted to get the word out. So I built this site, showed it to all my friends. And the crowd went mild. To make matters worse, our tech was better than our music. And while I garnered praise for my adept use of frames, my friends pointed out that I should not attempt a solo web career. Therefore, this is not a design talk. We're gonna leave selecting shades of green to the professionals. Now every few months, the internet seems to erupt over this sort of thing. As a child of the 80s, personally, I think high C nailed it back in the day. That was peak green. The point is, there's a diverse set of skills involved in web development. And we each possess a subset of them. So I teamed up with a designer. We relaunched the website. And while the band did not take off, our web company did. Now in 2003, the web is at V1. Now I never really understood web versioning. It's clear we're not using Semver. But companies were paying my buddy and me hundreds of dollars to build websites. And we thought this was great. So we land our first bigger customer and we are seeing those dollar signs. He designs the site and I start to build it. Emphasis on start. As it turns out, it is possible to design impossible things. Apparently Photoshop is not built on WebKit. Now in 2009, my team and I are on the 40th floor of the Hearst Tower in Columbus Circle. Captain Selly crashed lands in the Hudson River. We all raced to the side of the building, just missed seeing the plane float by. But we were building a fancy template engine for newspapers on e-readers. We could make the times look like the times. We could make the posts look like the post. We had designed multiple versions of multiple page layouts for multiple publications. And then we shipped the wrong design to production. Now, this was neither the first time nor the last time that someone just looked at the wrong Photoshop export. But you have to laugh after the fact that how all this fancy tech is so easily undone by us humans. Now in 2013, my team is building personality quizzes and sweepstakes and we decide we need to support custom themes for our customers. This meant we had to clean up our CSS. And we find 37 shades of gray in there. Now the jokes that ensue grow tiresome over the two weeks we spent cleaning up to get this feature out the door. So it turns out web development is hard. It's fun. It's fast paced. It can be hard, you know, projects start cleanly and then they get messy despite the best efforts of smart people making the best decisions under the circumstances. But why does this happen all the time? What is so hard about interdisciplinary teams collaborating to continuously deliver modern applications, targeting the latest browsers and devices in action-packed JavaScript landscape? All while the product keeps changing. Well, that's a long and winding rhetorical road. And we never do reach the end. But at the end of the day, it turns out there's a bunch of humans involved. You know, designers and engineers, product visionaries and thought leaders, figuring out what to build, and then changing our minds. When you have dozens of people making dozens of decisions over dozens of weeks, this leads to literally, literally dozens of problems. I like to call this design confusion. Symptoms include designing impossible things, like UIs, a third-party library can't adhere to, or losing track of files as the Dropbox goblins exact their weekly toll. We get our signals crossed with the intent of a feature and we end up building things we don't need. It happens to the best of us, and therefore, all of us. So what is a living style guide, and how will it help with the sleep-eating? A living style guide is a design showcase built using a live presentation code base. Now, I love this idea. I've tried a bunch of these projects over the years, most showcase current CSS using dummy HTML, and behaviors and interactions tend to fall by the wayside. You kind of have a copy of your design, and you have to maintain this, like documentation. It is bound to become out of date. Now, I would argue this approach is treating the symptoms rather than the causes of design confusion. But a year ago, Hugh Francis published an Agile Design Manifesto for Ember. In it, he discussed Gin Lane's Agile Design Process as they built out a new ordering system for Sweetgreen, which is a fantastic lunch spot if you're in New York City. Now, they would articulate pieces of the design and formulate design tiles. Each tile became an Ember component, and they decided to add these components to a dedicated style guide route. This allowed their CSS guru to load that one page and do all of the nitty gritty style work without needing to know the technical details of the application or Ember. Now, the article was full of great ideas, not the least of which is this emphasis on distilling a design into its individual components. Now, we should all be deconstructing our application UIs this way. Modern JavaScript frameworks like Reambular.js all provide a component implementation that provides the means to encapsulate behavior, appearance, and structure. So, gone are the days of hopelessly entangled JavaScript and CSS that causes the same piece of HTML used in two different places to yield wildly different results, different behaviors, different appearances. And if we're disciplined about this, we can compose interfaces out of components that are themselves assembled from other components and arrive at an application that is coherent, flexible, it's testable and maintainable, it's beautiful. There are gestalt winds at play. Now, the key insight of the blog post was to present the application's components in the separate context of the living style guide. And in one fell swoop, this obviated the architectural shortcomings of all of those other style guide projects that I had tried previously because the things in the style guide were now the actual things, not approximations. Now, on a Yap Labs project about a year ago, we had carte blanche and we decided to try this out. And the results exceeded expectations straight away. Now, on the first day, we had a bunch of designs, signup flows and whole sections of the app. What we didn't have were AWS credentials or a web server or an auth system or any APIs. But we didn't need any of that to get to work. We created a style guide route and we added components to its template, starting with these buttons and then inputs and forms and validation behaviors. And before we knew it, we had a bunch of UI components that were production ready in just a few hours. So what do you think we did when the CEO emerged from a meeting other than ask for the AWS credentials? We showed him our work. You can see it in action there, it looked really good. He was blown away. The designer was blown away at how quickly these concepts had sprung to life. And we had stumbled into an unexpected benefit of having a living style guide, rapid prototyping. We didn't have to wait for infrastructure setup to start building UI pieces in the style guide. Now, this worked wonders, divvying a task to the onset of a project. So far from being blocked, we were incorporating design feedback on day one and this never stopped for the rest of the project. So let's dive in and build a simple style guide. It's easier than you might expect. Now this presentation is an Ember app and each slide is a component. That gives us these actual Ember examples that we can play with, mini style guides in each slide. Now imagine you're building an Ember Conf website. You have this logo that appears throughout the site and obviously you want to pop out from behind it. So we need a Thompson Conf logo or Thompson Conf component. So we create a style guide route. You can see that we created this component. It just has a template backing component file. CSS for that animation that you saw. We put it in the style guide. We don't need the whole site to exist to build and marvel at this component. Once the site does exist, the component is ready to go. So now we have a basic style guide. Let's do some cool things with it. Let's talk about loaders, spinners and progress bars designed to be on screen for a fraction of a second. How many times have we added temporary code to force our app to remain artificially stuck in one of these ephemeral states? And we do our work. We remove the shim, never to think about it again until something goes wrong. Now these UI bits are notoriously difficult to work on due to their fleeting nature but the living style guide provides a place to keep them forever. You can see we have lots of versions of this monograph loader. That's that M icon you see in the middle. We have different sizes. And you can see here we have this big old dev version, huge and slow. It's so much easier to work with when you're making changes. And then we can just see those changes in effect in the loaders that are actually used in the app. Now the sandbox makes it really easy to make these often neglected things look great. And we did a lot of tweaking to get this just right. Designers care deeply about expressing their designs properly. The living style guide isn't just a snapshot of current state. It is an excellent environment to apply finishing touches. Because as we're continually polishing and tweaking, it makes way more sense to make these changes on live components rather than in design mocks. Now I'd like to talk about one of my pet peeves, empty states, or more specifically, forgetting about them. Now empty states are a pain in the neck to deal with partially because it's a pain to put our development environment with the right data for them. Now in design mockups, they all feature this most perfect data scenario. Unfortunately, our brand new users form first impressions of our apps in precisely these empty states. Now the living style guide provides an easy way to prevent, to present multiple states of the component side by side. In this case, we have an installs chart for Yaps Customer Analytics dashboard. And in the style guide, we stubbed data sources for nice data, for no data, for waiting for data forever. We provide nice messaging to users in the empty state. And a bonus is, in order to present these scenarios in the style guide, it forced us to encapsulate our functionality sensibly. We had to separate our presentation from our data munging and we built something better than we might otherwise have if we'd been developing the app, developing in the app where there's always real data flowing. When we broke things, we realized we had leaky abstractions on our hands. And this development approach ultimately raised the quality of the component we built. Now, animations. Animations are fun when done well, but they're often as tricky to work on as the segue into this slide. Now given we will have the Chrome DevTools open, I'm not talking about that. I'm talking about revving our app in and out of the states that invoke these animations. Now in this example, Yaps wanted to add helpful hints to first time users. And when a user would interact with one of these pulsing circles, affectionately dubbed Hinty, this one time modal appears and then, hopefully, for us developers, disappears forever. Now we all know the traditional development approach here. Create a new user and log in. Then click through the seven steps to get to the right spot. Open those Chrome DevTools and then click the thing that triggers the animation and now you start making changes. You twiddle with the DOM and CSS until your app is hopelessly out of whack. And then you give up and you blow everything away and you repeat the process hundreds of times throughout the day. Now if we model components effectively, we can toggle back and forth between the states that as we refine these animations. Now in this case, we had countless iterations because we were trying to strike this delicate balance of noticeable enough, but hopefully not annoying. And we had the living style guide live reloading all the way. There was a lot of work between the design mock-up and launch. I mean it is easy to make things just so in a design mock-up. Now everything fits perfect and looks great. I laughed myself silly when I saw this send-up of the Apple Watch promo that was telling us how to stay closer to all of our professionally photographed model friends with four-letter names. We all know that's not how the real world works. In the real world, we have data like this. Now here the living style guide rides again. Show this screen to any designer. They will immediately drop what they're doing and help you fix any and all edge cases. Here we came up with a simple strategy of just ratcheting down the font size as that stat went up and as you can see the design now tolerates that number, which by the way would be a fantastic page view count. And an added benefit is that once you fix this, it is really unlikely that you will accidentally break it without knowing. You see the living style guide lends our designs a certain durability. If we're developing against it every day, if we're conducting design reviews and demos, we are implicitly putting our design through its paces. If something goes awry visually, tests might not catch it, but a human will notice. This makes it really difficult to regress. Now let's dig deeper into a situation where we know that we have a bunch of these different data scenarios to handle. In another YAP Labs project this past year, we were working with Collectorium, they're owned by Christie's, and we were helping build out a search engine for auction results. Now they have many features and integrations that are unique to the art world, and they were building this Amazon like search engine for what sold where and has all these filtering aggregations backed by an Elasticsearch API. Now depending on the search terms, the API returns a heterogeneous set of search results, different categories here, paintings, jewelry, wine, and each category has a rich taxonomy, so it's a different shape to the data that's coming down. So this necessitates a bunch of logic to bring this information to the screen in a pleasing, consistent fashion. In the style guide we can represent all of these different scenarios on screen at the same time. We actually did this by subbing different data sources in the style guide controller before the data API even existed, and then we updated it as the API changed. This gave us a lot of confidence in our present UI capabilities, but it also gave us a strategy and workflow for incorporating future API changes. Because of this separation, I don't even need to be running that full data API service to work on these components. If I'm a new team member, I don't even need to know how they work to begin working on these components. So another huge benefit of the living style guide is that it provides easy onboarding. It is so cool to see someone join a project and contribute immediately without knowing everything. The application patterns are all nicely self-documented in one place in the living style guide. And unlike most onboarding documentation, it's actually up to date. It organically improves and scales with the application as we build new things in it. We have the richest and most complex interactions in the app laid out in component form in the style guide, like this rich stepwise flow in the monograph platform that allows users to compose legal contracts, setting up licensing terms for their media files. Now there's a lot of complex capabilities under the hood, but we needed a simple intuitive interface. And came up with an interactive sentence builder, but this functionality behind it didn't exist yet. And so when we got the designs, we had all sorts of things to model and reason about. We were able to deconstruct the experience into a set of components, present them in series in the style guide. You know, this gave us stuff to play with to see how things felt, to see if things made sense, gave us a way to incorporate changes. And the end result, as you can see, was beautiful on both their web and mobile apps. Now at one point during this process, their designer, Chris Gardella, mentioned that he had some feedback on these animations and transitions and also a lot of minor things. So he said he'd like to give us a doc by the end of the day so that hopefully we could implement changes sometime by the next week. So instead I suggested that we just work together at my laptop. And what followed was a really fun two hour design audit and refresh with really efficient dialogue. We analyzed the design holistically and made changes in the style guide. Then when I loaded the app and he saw that our work was already live, he was doing designer cartwheels. Now Chris and I were reflecting recently. Whoa. I need to sip anyway. I'm Italian, I have these hand gestures as I talk. So we were reflecting about this process and he was saying how it's often far less efficient at design studios where designers log support tickets for revisions and engineers go to implement them but then there's all this back and forth and misunderstanding what the designer's intent was and the living style guide gets around all of that. He said it's very liberating to see changes enacted immediately. So at this point, hopefully everyone is sold and ready to create a living style guide. So how should we go about building it? Now everything in a modern Ember app is made from components so we need a style guide component. Now if your next thought was maybe someone else has already done this. This time here in luck. I've collected our thoughts and learnings from the past year and come away with this Ember add on. It makes it really easy to add a living style guide to your Ember app. It's called Ember freestyle and out of the box it gives you something that looks like this. So all of the examples in this presentation were built with components provided by the Ember freestyle add on. Every interactive example, you have code snippets and notes. This left navigation collapses so that we can work, test responsive design, load this style guide on your phone or tablet. See how every piece of your application fares. It saves a lot of tapping around in actual app. Now, if you see something you want to work on, you just focus on that one component and you get to work on it. The style guide will live reload as you go. I can even share the URL that I'm on right now with the teammate and the style guide will load right up to that same component, focused. All this is just set up for us by Ember freestyle. So I will tweet the URL of this presentation and the GitHub repository includes the slides and codes so you can peruse and join in the fray. The add on is in its early stages but it's already really easy to work with and it goes toe to toe feature wise with all these other style guide projects but with a fraction of the overhead. It's a polite lightweight Ember citizen as fully encapsulated CSS using suit CSS naming convention. So that means it's safe to use in your app. And that is Ember freestyle. Now, I have one bit of Embery goodness that I want to take a peek at in particular and that is the component that we're using for code snippets. So we have this freestyle usage component and all you need to do is wrap your component, in this case the Thomster logo component, inside one of these freestyle usage components and it will render your Thomster logo component along with the handlebar snippet that generated it. Additionally, you can use comment delimiters anywhere in your application code base to flag a code snippet to be pulled into the style guide. The same goes for markdown notes. We have this freestyle note component that you can use to make markdown notes in the style guide but you can also use comment delimiters to pipe special code from comments in your app into the style guide. It is so cool to have all of this just happen using the actual code in your app. One repository. So what's next for Ember freestyle? Well, there's plenty of work to do. I would certainly appreciate help. The GitHub repository is Crystal Presto, Ember freestyle. There's a bunch of issues I have up there. Most notably, we need testing and documentation so that we can get this into more people's hands but the reality is that today you are one console command away from a living style guide in your Ember app. If you're already building composable UIs with components with reasonably encapsulated styles, you can just spin one right up. If your app is not as well organized, count this as another reason to refactor towards modern Ember conventions. They really are empowering. You see this living style guide driven development approach that I'm touting relies on Ember components, other add-ons, service patterns and query programs, build hooks for those code snippets. Ember CLI puts the whole thing together. It is amazing to be able to do all of this. It is even more amazing to be able to package it up into an add-on share with any Ember app. So where do we go from here? Well, there are many problems to solve. Many of you are likely pondering some of them right now. Regarding payload size, engines could be very useful in the future. We can consider build hooks in the interim to conditionally serve our style guides. Bigger organizations like Salesforce have been tackling the problem of presenting consistent experiences across large suites of apps, across multiple platforms. They have an open-source project called Theo that seeks to establish a single source of truth for design properties using common JSON config. And there's a bunch of interesting opportunities to use the style guide for testing, whether that's acceptance tests or screenshots for visual regressions. There's lots to do. But these design problems transcend any add-on, any framework, any team. And I'm excited to tackle them together. I've been thinking a lot lately about how technical teams work together. Things that have changed over the years, things that haven't. Ultimately, I'm happiest when people are working together, closely and efficiently. We should avoid over-complicating our interactions because the things that we're working on are already complicated enough. So I love teams that optimize for collaboration. John Mada recently tweeted how design partners with engineering to imagine and realize a product that is not only reliable, but has soul. And so it's often easier to just spin the chair around, speak out loud into a webcam, than it is to open an issue and throw something over the fence or onto the back lap. I routinely marvel at how far web technology has come since I first started out. Like so many things are possible now, technically, interpersonally, that we couldn't dream of five, 10, 15 years ago. Sometimes it feels like surfing a renaissance. And above all, have fun tackling tricky problems with good people, because that's why we all started doing this in the first place. Thank you very much. Hey, that was a great talk. I've seen some companies with pretty big teams set up a separate add-on or a separate repo for their styles, and that's been really effective for letting the designers feel like they can change stuff without getting in the developer's way all the time. So how would you use that with Ember Freestyle? And do you think it's a good idea? I do think it's a good idea. We have used that approach actually internally at Yap. We have a bunch of Ember apps because they were built several years before Engines came about. And we have a common Ember add-on that we pull into all of them. And that's where we have our living style guide, our main one, because you can have more than one if you want. And we actually serve it up using the dummy app in that add-on. So that's great. What's important to remember is that these really are just components. So you can use them wherever you want, however you see fit. You're just sticking your app's components in them. So every single one of these slides with examples had different subsets of components, and then the one example slide had the whole guide. So you can really, any way that you want to organize your systems components, if you have a shared add-on like we do, or if it's all in one app, it's really up to you, because you're just composing with these components. Quick question about Ember freestyle. Is it, when you install that in your repo in like a production app, does it just, when you build it, does it just like remove all those assets or is it? When you build it, sorry, I didn't hear the last bit. And when you build it, do you install the add-on in your production app, or is it like a separate thing you do in development? So it's up to you, you can do either way. At Yap, we actually do just have it in our production build because it's not really adding to the payload size, much at all. And we prefer, when our designer is asking a question or one of us is working on something, we can just link directly to something it's all publicly hosted. So it's nice to not need to be on a developer's machine in order to see it. But it really is up to you. And we have discussed using build hooks in order to strip it from production builds if you specifically don't want to, let's say show how you could potentially break a bunch of stuff in your app. You don't want people maybe stumbling across that on a public URL. Then again, you could also have multiple style guides if you want to. So it really is up to you. But that is a very good question.