Living Style Guide Driven Development
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 37 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/34706 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
VideoconferencingCodeElectronic program guideHost Identity ProtocolSupremumProcess (computing)FeedbackSoftware frameworkPointer (computer programming)Software developerWebsiteWeb pageRevision controlAnalytic setTemplate (C++)BuildingCross-site scriptingNP-hardWorld Wide Web ConsortiumModemWeb browserGroup actionProduct (business)Decision theoryOnline helpDecision theoryLattice (order)Product (business)WordFrame problemCASE <Informatik>WebsiteQuicksortMusical ensembleInternetworkingComputer fileSet (mathematics)SubsetCrash (computing)PlanningSign (mathematics)Point (geometry)Graph coloringProcess (computing)Multiplication signSoftware frameworkElectronic program guideProjective planeSoftware developerWeb 2.0PlastikkarteInstallation artSemiconductor memoryGamma functionNumberDisk read-and-write headVideo gameTerm (mathematics)Standard deviationBuildingMobile appRevision controlLibrary (computing)MultiplicationTemplate (C++)RoutingWeb-DesignerTrailWeb browserWebdesignComponent-based software engineeringComputer fontForm (programming)DigitizingService (economics)Level (video gaming)Cycle (graph theory)Cartesian coordinate systemElement (mathematics)DampingGreen's functionKeyboard shortcutE-Book-ReaderFeedbackSoftware maintenanceUser interfaceCommon Language InfrastructureAvatar (2009 film)Graphics tabletXMLComputer animation
07:03
Presentation of a groupElectronic program guideCodeEuclidean vectorCross-site scriptingFunction (mathematics)Component-based software engineeringComa BerenicesScripting languageJava appletData structureModemImplementationElement (mathematics)Interface (computing)Different (Kate Ryan album)Projective planeBlogComponent-based software engineeringContext awarenessCausalityOcean currentPresentation of a groupCodeResultantSheaf (mathematics)ImplementationRapid PrototypingElectronic program guideTesselationAuthorizationForm (programming)Arithmetic meanMobile appPhysical systemConnectivity (graph theory)Interactive televisionProcess (computing)Cartesian coordinate systemValidity (statistics)Data structureQuantum entanglementGroup actionWeb 2.0Encapsulation (object-oriented programming)Web pageSoftware frameworkLattice (order)Key (cryptography)Expected valueDataflowApproximationSoftware maintenanceProduct (business)Server (computing)outputWordComputer animation
10:31
Rapid PrototypingVideo game consoleComputer virusElectronic program guideState of matterHill differential equationBootingOrder (biology)Moving averageWebsiteRoutingArithmetic progressionConnectivity (graph theory)Template (C++)Mobile appCodeFraction (mathematics)MathematicsBitTouchscreenPresentation of a groupProjective planeTask (computing)Slide ruleElectronic program guideMultiplication signBooting2 (number)Integrated development environmentFeedbackState of matterSound effectRevision controlComputer iconVideo gameMessage passingInsertion lossNatural numberNumberSymbol tableOcean currentBuildingTouch typingStructural loadComputer animation
12:54
State of matterConnectivity (graph theory)Functional (mathematics)State of matterMathematicsSource codeOrder (biology)Installation artIntegrated development environmentMobile appElectronic program guideAnalytic setSlide ruleVideo gameMessage passingFreewareCASE <Informatik>XML
13:59
Convex hullEncapsulation (object-oriented programming)AbstractionPulse (signal processing)Personal digital assistantSoftware developerData miningDataflowLoginMultiplication signNumberComputer fontPeer-to-peerDigital photographyCircleStrategy gameEndliche ModelltheorieGraphical user interfaceTouchscreenState of matterCASE <Informatik>Process (computing)Connectivity (graph theory)Slide ruleMobile appLibrary (computing)Real numberWeb pageAbstractionMathematicsPresentation of a groupBuildingStatisticsOpen setChemical equationElectronic program guideView (database)XMLComputer animation
16:50
Euclidean vectorElasticity (physics)INTEGRALInformationConfidence intervalMathematicsTouchscreenProjective planePresentation of a groupSet (mathematics)Different (Kate Ryan album)Strategy gameGame controllerCategory of beingElectronic program guideSoftware testingShape (magazine)Search engine (computing)LogicSource codeService (economics)Multiplication signResultantConnectivity (graph theory)Computer configurationConsistencyTerm (mathematics)Flow separationDemo (music)SpacetimeNumerical taxonomyComputer animation
18:36
Kolmogorov complexityLimit (category theory)Data typeDesign by contractText editorElectronic program guideInstallation artComputer iconNumber theoryCodeBit error rateSoftware testingCollaborationismLevel (video gaming)CodeFraction (mathematics)Cross-platformOpen sourceGoodness of fitMobile appBitDataflowPoint (geometry)Wrapper (data mining)Revision controlMathematicsCASE <Informatik>WebcamSoftware testingLogical constantPosition operatorRepository (publishing)CuboidMultiplication signSound effectScaling (geometry)Code refactoringPattern languageCountingBuildingCartesian coordinate systemTablet computerDependent and independent variablesFocus (optics)Form (programming)Service (economics)Design by contractComputing platformHypermediaTerm (mathematics)NumberComputer fileWeb 2.0Interactive televisionProcess (computing)Lie groupFunctional (mathematics)Interface (computing)Connectivity (graph theory)Electronic program guideComputer wormFeedbackShared memoryComplex (psychology)Query languageProjective planeConsistencySeries (mathematics)Suite (music)Endliche ModelltheorieForcing (mathematics)Set (mathematics)ResultantSingle-precision floating-point formatView (database)Software developerQuicksortSelf-organizationPresentation of a groupServer (computing)CodeLinear regressionSource codeSubsetGroup actionCategory of beingVideo gameRight angleSlide ruleDecision tree learningSoftware frameworkOpen setProduct (business)LaptopCollaborationismCommon Language InfrastructureVisualization (computer graphics)Structural loadUniform resource locatorSession Initiation ProtocolConfiguration spaceFlagUser interfaceXML
27:25
TwitterVirtual machineMathematicsSubsetSoftware repositoryMultiplicationSlide ruleMobile appProduct (business)Connectivity (graph theory)Different (Kate Ryan album)BuildingUniform resource locatorElectronic program guideOrder (biology)Computer wormMultiplication signPhysical systemSoftware developerGodGoodness of fitComputer animation
30:11
Computer animation
Transcript: English(auto-generated)
00:13
My name is Chris LaPresto. I live in the greatest city in the world. I work at eApp, where we make Ember apps that run mobile
00:22
apps, that run Ember apps. Before that, I was CTO of Plife. 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.
00:42
Now, I am not a designer. But I've worked really closely with many wonderful designers over the years. And together, we've found all sorts of ways to bump our heads. So I've come to care deeply about why that happens and how it would have prevented it. So that's why I want to talk to you about style guides.
01:02
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.
01:20
But today, we're going to 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.
01:41
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 want to do is add something else new to our development process, another meeting, another tool, a dependency on left pad.
02:04
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.
02:23
But I have some stories I want to 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.
02:43
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.
03:02
We're going to 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 Hi-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.
03:21
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.
03:41
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
04:02
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.
04:21
Captain Sully crash 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 posts. We had designed multiple versions of multiple page layouts for multiple publications.
04:40
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 at how all this fancy tech is so easily undone by us humans.
05:00
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
05:25
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. Projects start cleanly, and then they get messy, despite the best efforts of smart people making the best decisions under the circumstances.
05:43
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 an action-packed JavaScript landscape? All while the product keeps changing.
06:00
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, 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
06:21
over dozens of weeks, this leads to 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
06:41
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?
07:01
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.
07:21
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 Jin Lane's agile design process as they built out a new ordering system for Sweetgreen,
07:43
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
08:00
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.
08:22
Modern JavaScript frameworks, like ReimbularJS, 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
08:43
in two different places to yield wildly different results and 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.
09:04
There are gestalt wins 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
09:21
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,
09:41
sign-up 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,
10:02
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.
10:20
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, you know, divvying up tasks to the onset of a project.
10:42
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.
11:01
It gives us these actual Ember examples that we can play with, you know, mini style guides in each slide. Now, imagine you're building an EmberConf website. You have this logo that appears throughout the site, and obviously you want Tomster to pop out from behind it. So we need a TomsterConf logo, or TomsterConf component.
11:20
So we create a style guide route. You can see that we created this component. It just has, you know, 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.
11:43
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, you know, 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.
12:01
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
12:23
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 oft-neglected things look great, and we did a lot of tweaking to get this just right.
12:42
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.
13:05
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 mock-ups, they all feature this most perfect data scenario.
13:22
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 present multiple states of the component side by side. In this case, we have an installs chart for YAP's customer analytics dashboard, and in the style guide, we stub data sources
13:41
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.
14:01
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.
14:21
Now, animations. Animations are fun when done well, but they are 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.
14:41
Now, in this example, the app 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, helpfully 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
15:00
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,
15:21
we can toggle back and forth between the states 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
15:41
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.
16:02
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
16:21
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,
16:42
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.
17:02
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 Collectrium. They're owned by Christie's, and we were helping build out a search engine for auction results.
17:22
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 it has all these filtering and aggregations backed by an elastic search API. Now, depending on the search terms, the API returns a heterogeneous set of search results, different categories here, you know, paintings, jewelry, wine,
17:41
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.
18:01
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,
18:21
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.
18:45
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
19:01
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,
19:26
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.
19:40
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.
20:01
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.
20:20
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 a sip anyway. I'm Italian, I have these hand gestures as I talk.
20:45
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.
21:03
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.
21:23
Now if your next thought was maybe someone else has already done this, this time you're 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.
21:44
So all of the examples in this presentation were built with components provided by the Ember Freestyle add-on. You know, every interactive example, we have code snippets and notes.
22:05
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 an actual app. Now, if you see something you want to work on,
22:24
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 a teammate and the style guide will load right up to that same component, focused.
22:41
All this is just set up for us by Ember Freestyle. So I will tweet the URL of this presentation in the GitHub repository, includes the slides and code 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.
23:02
It's a polite, lightweight Ember citizen, has fully encapsulated CSS using Suit CSS naming conventions. 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
23:21
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 Tomster logo component, inside one of these Freestyle usage components and it will render your Tomster logo component
23:41
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
24:01
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 is plenty of work to do. I would certainly appreciate help.
24:21
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
24:42
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
25:00
that I'm touting relies on Ember components, other add-ons, new service patterns and query params, 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.
25:22
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
25:40
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.
26:02
There's lots to do. But these design problems transcend any add-on, you know, 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, you know, things that have changed over the years, things that haven't.
26:21
Ultimately, I'm happiest when people are working together, you know, closely and efficiently. We should avoid overcomplicating our interactions because the things that we're working on are already complicated enough. So I love teams that optimize for collaboration. John Mehta recently tweeted how design partners
26:40
with engineering to imagine and realize a product that is not only reliable but has soul. And so I mean, it's often easier to just like 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 lot. I routinely marvel at how far web technology has come
27:01
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.
27:21
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 separate repo for their styles
27:42
and that's been really effective for letting like the designers feel like they can change stuff without, you know, getting in the developer's way all the time. So how would you, you know, 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
28:02
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. You can have more than one if you want. And we actually serve it up using the dummy app in that add-on.
28:21
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, you know, any way that you want to organize your systems components,
28:44
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 it in your repo,
29:01
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. 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. It's, you can do either way.
29:21
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, you know, 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.
29:40
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
30:03
if you want to. So it really is up to you. But that is a very good question. Thank you.