Mistakes Were Made

Razvan Spatariu speaking at London CSS in March, 2017
652Views
 
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

Lessons learned while building Funding Circle's internal styleguide and pattern library - mistakes and solutions, and plans to fix those mistakes.


Transcript


Hi all. There's a lot of people here. I didn't expect so many people to actually turn up to this event, but I guess it's great. Hopefully, the presentation will be up to your standards. Cool, so my presentation is called Mistakes Were Made, because in software development, you always make mistakes, you always look back at your code and, "What have I done there?" And I know Igor said that our meetup is called the London CSS meetup. I have one line of sass in my presentation and that's it. Everything else, I've tried to focus the mistakes around the process, more than the actual stack overflow type of answers. So hopefully, this will help you guys if you work on a style guide. So, let's talk style guides. Who here knows what a style guide is? Let's do some crowd work. Quite a few people. I do expect the people that work at Funding Circle to raise their hands though. Who here works on a style guide? cool. Who here wants to work on a style guide? I guess some people, right? Cool. In case you don't know what a style guide is, you can think about it as a way of abstracting everything that's design language, so everything that a design team provides you in terms of like smaller blocks of text, the way you do type over, the colors, margins, padding, and so on. Basically everything that a brand means, you can get that inside a style guide, try some documentation surrounding it, and then you can use that style guide to keep consistency for your brand. So, let's go back in time a bit, to two years ago, when Funding Circle was in this state. In case you don't know, Founding Circle has three offices in the UK, U.S., and Central Europe. So where you're going to see CE, it's basically Central Europe. And the way we developed as a business, we actually acquired companies in the U.S. and in Central Europe, which means those companies came with their own stack. Also, I have to be honest, I don't think we did the best job in the world in keeping front end up to good standards in the UK also. The stack across all geographies, or countries, if you want, goes from PHP and Symphony, with some custom bootstrap, to Rails apps that have angular on top of them, maybe some custom bootstrap, maybe some hard-coded CSS. They don't really talk to each other. We also have an old app that's shared between U.S. and UK that again, in terms of the style, doesn't really communicate to any of the other apps. So obviously, we consider that to be a major issue. We have different stacks. In the UK we have five years of people implementing projects rather than looking at the big picture and trying to solve front end as a global issue. In terms of resources, or people, as I know Igor doesn't like the word resources, we are five front-end developers in the UK, one in Central Europe, and one and a half in the U.S. Which means we have a marketing front- end engineer there and a full-stack engineer that likes front-end, and in terms of the front- end versus back-end ratio, it's not looking great for front-end. For every front-end engineer that we have at Funding Circle, we have roughly 15 back-end engineers. So you can imagine it's quite difficult to keep the pace with all the back end that's happening and build a front-end on top of it. So we said, "This is probably not a good scalable idea to just build small projects,î and you can see that right now, also, in production, we have inconsistencies across the board, basically. And one that really bothers me at the moment, when you try to sign up as an investor with Funding Circle, this is the first page that you see, which is a roughly cool page. It looks roughly 2017/2016. It's been built in the last year on the build, I think? It's responsive, which is great, and when you press Sign Up, it takes you to the second page, where you enter all of your details, that looks like this. As a normal user, you might wonder, "Am I on the same website? What happened? Did they rebrand between me entering my email and pressing Submit? And also, let's not forget this is a UK example, if you go to the general website and try to create an account there, it looks like this. I mean, even the guy in the picture seems quite upset with the inconsistencies. We're pretty good with the [inaudible]. We have 94%, which I assume is great, but in terms of how we actually build the codes to get to this, we're not doing great. So, two years ago as I was saying, we started looking at fixing the whole mess. And we started roughly doing some ideas there, what are the issues that we have? That's kind of an excerpt of what we came up with. We would love to write CSS and Sass once and we should just be able to reuse it everywhere without reinventing the wheel every time we build a new app. We should be able to implement JavaScript patterns in terms of UI, UX, just once, because we need to test them only once. We need to standardize the design language. If the design team in each geography or country is doing something else, you cannot really get consistency. We also need to document that so when you come back and try to reuse what you've built, you have a documentation on how to do that. And it's really important. We need to step away from building pages, because that's just not scale-able. Every time you want to build a page, you're just going to build something new. So we need to step away from that. And when we looked at all of those issues, we have one thing in mind, and I mean, it's quite obvious what the answer is. We need a style guide. So, we've built, almost two years ago, a style guide for Funding Circle, for trying to get the brands together. The style guide is called Radius. Igor came up with the idea. It's quite clever because we're called Funding Circle and the defining thing about the circle is its radius. But we always thought that our style guide will solve all of our issues, and it's going to be amazing, and it's going to be great, and everyone would be happy. we'll be out of a job because everyone would be able to write front-end consistently, and we're going to fix this, which is in a pre-style guide architecture and transform it into this, which looks much better, where we have the style guide living on top of everything, and then we just have like custom small style sheets for each app. And then it doesn't really matter what sort of app I'm building anymore, because the style guide will just provide what you need in order to build a UI. But this is software development, and software development doesn't always go according to the plan, and you also evolve as a developer, you learn how to do things. And we have to admit that while building our style guide we made some huge tiny mistakes. That's a great reference to Arrested Development in case you don't know the show, great show, I truly recommend it. But the good thing about making mistakes as a software developer is that every time you make a mistake, you learn from it, so that's always great, right? And it's not life-threatening, you can always go back, refactor your code, and everything will be better. So basically, this is the gist of my presentation, the next 10 or 15 slides will be a collection of mistakes that we've done, and the lessons that we've learned. So, let's start going through them and hopefully they will be useful to you guys. First one, first mistake. By the way, the mistakes might just be quotes, might just be me quoting myself, but, might. Anyway, first mistake. We want to fix everything in one go. The style guide will be the magical solution to all of our UI issues, well, yeah, but there's five of us in the UK, and we also need to deliver features, so we kind of have to pick our battles, and instead of fixing everything, we actually started looking at what the issues are, and what the biggest issues are. And from there we started solving the big ones. And after we were done with those, we could move forward to smaller ones, and then to nice-to-haves. I mean, we didn't get yet to nice-to-haves but we're on our way there, I guess. So yeah, I think the first lesson would be to just pick your battles. Understand that you cannot magically solve a lot of issues if there are no patterns, or there are a lot of inconsistencies, you won't be able to fix all of them. Focus on the big ones, and take it from there, and with time, things will like level up, and everything will become better. And a really good example about how we did this is the actual style guide. So when we started looking at patterns, and how we should encompass them in our style guide, we didn't really need to provide a style guide to other developers, because it was just for us exploring how it goes. So we were okay, we're just documenting the patterns in an HTML file, just pasting all of them there. But at some point, we said, "This is not enough, we also need to document them." So the second iteration was this, after we solved the initial issues, which allowed us to have snippets of code, and documentation on how to do modifiers, and what those modifiers look like, and so on. And when we started looking at getting the style guides to full stack developers, and into presentations for the wider company, we realized that we need to work a bit more on the look and feel of the style guide. So now it actually looks like this, which hopefully is much more professional than the initial one, hopefully. Cool, mistake number two. Everyone knows what a style guide is, right? You don't need to explain ourselves what it is. We are all working in London, everyone knows what everything is, all the acronyms and so on. Well, not really. Everyone will understand a different thing on what your style guide will actually provide. So it's really important to explain to everyone what you're trying to build, because there will be cases where departments will pick and choose your words, and create their own ideas on what the output will be. And probably a good example with this is we were talking recently about maybe having a CMS, and the discussion was, yeah, but will the style guide be the CMS? Well, no, they're solving different issues. And it's okay to have questions like that, because if you, as a developer, if you don't educate and cater your tools to the wider audience, you cannot expect marketing each morning to be each morning on Hacker News, right? Then they will start writing code, and nobody wants that. Also, back-end. There are quite a few back-end developers that ask me, "Does that mean I'm not going to write any CSS?" And my answer is always, "Potentially?" You might need to write some, but I also think there are a lot of developers at Funding Circle right now who are tired of hearing me talk about the style guide. And now less and less I get questions, and I actually get feedback now, which is great. Cool. Mistake number three. The company should give us time to work on the style guide. Yeah, really? Why? The style guide is a tool. The style guide is not a product that will make money. The company is interested in delivery. It's interested in having features that get users faster through our platform, but that doesn't mean you don't have time to work on it. You just cannot ask for six months to work on this. Yeah, there's five of us, can't three of us go for six months and work on the style guide, please? No one would say yes to that, right? So they way we approach it is similar to the way we write tests. It's just part of our workflow. The style guide is not a separate thing that gets built in an ivory tower. It's just another tool that is part of our workflow. We develop it as we develop new functionalities, and we maintain it as we maintain those functionalities. We always try to improve on it, doesn't always work. At least since we had this switch in our thinking, we actually got so many more things in our style guide, rather than just waiting to have nothing to do and then work on it. Cool. Hopefully, I'm not going through too fast, through the slides. Mistake number four. Really important one, and I'm the first one to make this mistake, I think. I said the design team should just provide us the designs. That should be enough. We're going to deal with writing the implementation and writing the documentation for it. They just need to do pretty designs, right? That's what design does. Well, actually, a successful style guide starts from the design. What we tried to do initially was to retrofit and find patterns where the design team didn't intend to have those patterns, Which goes well for a bit, until design starts changing things and then you realize, "Oh, that wasn't a pattern. That was just a coincidence to having the same..." Also, one thing that we noticed, we were changing colors quite often, and I'm not exaggerating when I'm saying that we literally have 50 shades of gray, because we had, and the reason for that was that every time we got a new design, there were new colors in it, and we're like, "Oh, the design team wants more colors in our style guide. Let's just add them." But at some point you end up without names. I think there's like a finite amount of names you could give to shades of gray. You can have a cool gray, a warm gray, a darker gray, but then you have a lighter gray that's darker than...it's just, it gets really confusing at some point. So we looked, with the design team, we had a meeting with them, "Guys, stop adding colors. That's just upsetting doesn't fit with our style guide." And we realized that each designer in our design team had its own palette of colors, and they were not matching, and every time we're updating the reds, and another designer was providing us a design, and we were like, "Oh, but we've just fixed that, now it's different again?" But getting the design team involved, it's actually really important, because they will be the ones that will move away from designing pages to designing components. And without them having an active role, you cannot have a usable style guide, I think. Next mistake, "We don't need to document that. It's self explanatory. It's just code, you can go through the source." I've done that probably too much in my career, and you write some code and you're thinking, "Yeah, it might be a quirky solution, but I wrote it. I can go back to this. I understand what I've done." And you go back to that piece of code in two weeks time, and you're like, "Who wrote this? Was that me?" And it happened to me a lot with the style guide, to have failures, and do a [inaudible] "Oh, who is the guy that wrote this?" Hoping it's someone else, and it's like, "Oh, it's actually me. Whoops." So, if you write a documentation, although it might be boring, because it's always boring to write documentation, we want to write code, actually helps you in the long run. And another good thing about writing documentation is that you're going to have more time to spend on delivering extra features to your style guide. And the reason why I'm saying that is as our style guide got more popular in the company, there were a couple, maybe like three or four, back-end developers that wanted to play with the style guide. But we never wrote the documentation on how to integrate it in your apps. So every time they came to one of us, "Guys, can you help us set up Radius? We really want to play with it, but we have no idea how to implement it in our Rails apps and our MPM," whatever they're using. So you go, you pair with them, and you explain for the tenth time how to include an MPM package, and they will complain about how you have a billion MPM packages already, and then you're going to say, "Yeah, but you have a billion gems in your Rails app, sorry, it's the same thing." But yeah, if you write the documentation once, you can just say, "Just read the manual. It's fine. You have that link. If you cannot handle that, come and ask me, but first try that." So that's great. So now we're actually working on creating a separate section in our style guide where we're going to document, hopefully, everything from how to include it in your projects, how your files should be structured in your projects, where you can find the linters, where you can find the style guide on how to write front-end. And we hope that at some point, when we have new joiners in the company, we can just send them the link and they can go through the documentation and in a week's time they know how to do front-end at Funding Circle. Cool. We have a magnificent style guide, why should we write CSS anywhere else? It's a valid point, why would you want to write CSS and build components in your app when you have a style guide that can distribute those components to all of the apps that you have available? We thought about it, and the answer was, yeah, but if you have two admin apps, or one admin app, the components that you're going to write for the admin won't be the same as the components that you're going to write for the SEO or marketing pages so there's no reason to include the CSS from those to the marketing pages. We came up with a system called Candidate Components, which worked for us for a while, which meant as soon as you develop a component in an app, you document it outside of the style guide, and if it's going to be used in another app, you then move it to the style guide. Which we thought, "Whoa, that's a good idea. Let's do that. But if we keep building components, and if we want consistency across apps, at some point we're going to move all of the components in the style guide as we go... The premise of this is that they're going to be used in at least two apps, because we want consistency. So we scratched that idea because it was just delaying the movement of components to the style guide, and now we're trying, I have to admit, slightly unpopular version of moving components, where you actually build the components in the style guide, but by default all of them are disabled, so when you compile the CSS, you don't get the CSS for any of the components. You need to activate them through Sass. It's still a discussion point in our meetings. I like the idea, I'm probably the only one but... Next mistake, and this is my favorite one. I'll just name it Large Title with Background One for now. I'll come back later, when I know, I have more context on it, and I'll just rename it. You never go back and rename it, because you're going to start using that component in apps, and that means if you're going to update it in the style guide, you need to go in the apps and also update the names, like the player is showing. We all know in software naming is probably one of the hardest things to do. How we manage to avoid giving silly names to components is by trying to find their purpose, and the meaning for that component. So first we're looking at what the component wants to solve, and then we can come up with a name for it. So if you have a graph, it can be a graph for the About Us page, so you can name it like the "About Us Graph," but then you use it on the homepage, and you're going to have to copy the "About Us Graph" class to the homepage, that is not "About Us" anymore. But by saying, "This graph solves the issues of having bar charts that have a certain X label and a certain Y label," then you've abstracted the naming, and you can easily use it everywhere without looking back and being like, "Oh, that's a stupid name." An example of a stupid name, and this is the only Sass line that I have, is a mixin called Table that takes three parameters initially in a list, and then just a string, and a Boolean, and I'm not going to ask you what do you think this is doing. Who here thinks this is something to do with tables? I assume most of you. Wrong. It's not. This was the mixin that was generating the widths for our column system from small mobile onwards. False means there's no upward boundary on the width. Mobile small is basically mapping to a pixel size for the view port, and 132 are the parameters that will generate the width for each column. Yea. We renamed that, and we've made it slightly better, so you don't have magic parameters in it anymore. So now it's actually called Columns which I think makes a bit more sense than Table when you're talking about columns. The reason why this was called Tables, and I'm not trying to justify myself, because it was a mistake, is because it was using "display:table" to generate the columns. And I thought,"Oh, it's using "display:table" so it should be called "tables" because it's basically generating hidden tables." It's using flex now, so, yeah. Next mistake. "Let's implement multiple variations of this component, just in case." And quite often we are guilty of over engineering, and I'm going to raise my hand, and I'm going to say, "Yes, I am always over engineering things because I feel like that's my job to do a future proof solution for everything." But that's not the case. And the best example that I can give you for this is what we call our hero, or billboard, or whatever you want to call it. I think bootstrap is calling is calling it a billboard. We call it a hero. I was building this component that had basically a title, some paragraphs in it, a button, and a background image. And I wrote the CSS for it in like half an hour, and I had some time to kill. And then I started asking, "Yeah, but what if you need the image, the focus of the image to be on the left, and the text on the right? I should probably write some CSS to allow that." And I wrote it, and then I was like, "Yeah, but what if we need to center the text? Should I also write a CSS for it?" And I did. What if we don't have paragraphs? Or what if the padding is top and bottom, or not fixed? What if on mobile it behaves differently? Roughly a month later, I actually ended up with a mixin. If you go to any car website, and you try to buy a new car, it gives you like 500 options that you can choose from for like the wheel color, the interior, the headlights, and so on. I think I had more parameters in my hero than any car website out there. It could generate roughly ten thousand variations of it, because I ended up building a mixin that had a lot of functions, and depending on the parameters, it was exporting a different CSS. And at some point, when it started breaking, and me having to go through the code and be like, "I don't know why this broke. I don't understand the code anymore, because I haven't documented properly." I thought, "Why are we actually doing this?" So right now, I removed everything, and just implemented that, which is a background picture, a title, a paragraph, and the bottom, and if we're going to need one that has a text on the right, I'll just create the modifiers, like, five minutes of work, right? So the lesson is just don't future- proof solutions, but instead allow for flexibility, allow for extension, which is a better approach. It might be slightly more difficult, because you want to solve all the solutions, but on the long run, it's better to just focus on the problem on hand, but allow for other problems to be solved in the future, if needed. Next one. As soon as we get that feature, we're done. The style guide is done, we can use it. It's magical. Everyone will use it everywhere. It's great. But the style guide is a project that will never be done. The reason for that is that our design evolves, and we're going to have to implement those features in the style guide every time we build something new. It might be an adjustment of colors, it might be a new component. Over time,we all know that MPM packages are not the most reliable thing in the world, so you're going to have breaking changes, and you're going to have to go back and fix it. Also, as I was mentioning at the beginning, as a developer, you learn new things. And one thing that we try to do at Funding Circle is to hire developers that are better than the existing developers so we can take it to the next level. And you get a new developer saying, "I can do this better." That's a great thing, because you can improve the style guide. That's probably valid for any app or any piece of code. It's actually a great thing to be able to look at how the style guide evolves, and looking through the git history, and seeing from where we started to where we are now, we are far from being done. We actually never say that. As soon as we get that feature, we are done, because we know there is always going to be something. But I think that was mostly an expectation from others, saying like, "Yeah, we're going to have the style guide, we're going to be able to use it." Yeah, we're still going to have to work on it. That's when the work actually starts, because then you have control over the way the app looks, and you can improve it from the centralized style guide. Cool. One more mistake and I'm done. Mistake number 10. What about technology X, version 0.0.pre-alpha whatever? As front-end developers, we look at the market, and we see a JavaScript framework each week. We see PostCSS rising. We now have display grades in Chrome and Firefox, and we want to use those, and all of those tools are cool. And as developers, we should want to use them, but we should also look at where we use them, and I'm not saying that when building a solution that goes across all apps, just go with the known things. Yeah, we actually build the style guide in Fortran because we know it's still here, and it's been here for like 50 years. It's good to use versions of tools that are not yet at stable versions if it's 0.0.1, that's perfectly fine, as long as you use it as a tool inside your style guide. As soon as you start distributing that tool towards your apps, any change that will happen in that tool will affect all of your apps. So you're gong to have to go through each one and fix it. So what I'm trying to say is that sometimes boring is good, because it allows stability, and that's exactly what the style guide should provide, a stable environment that can offer us consistency across the UIs and the way of influencing everything as the design evolves. So, yeah, as long as you use it for your internal tools, and it doesn't affect everything else, you should be fine, but you need to go back and fix it from time to time as the libraries evolve. So, thank you guys. Do you have any questions? - [Man] If you use any particular architecture to organize the patterns - No. We don't. I mean, we have...because we have so many different technologies in our tech stack, it's quite difficult to say, "From now on, we're going to use Angular." - As in architecture, I mean as CSS or Sass architecture, of organizing the...? - Yeah, so for naming, we're using BEM with the flavor of ITCSS, and SMACSS just because we like to combine them. We have a certain pattern when defining the components and the style sheets, and the functions live in a separate directory. There's a way of importing them so we don't break them. The whole idea is that when you distribute the style guide, you only have one entry point, so you cannot go inside the library and ask for function X, you get the whole thing, or you get nothing. I don't know if that kind of answers your question. - [Man 2] My question is did you steer away from object-oriented CSS, that use compositing components for a very specific reason? Or is because it didn't really work for you? - The reason why we don't really use all CSS is because we like to keep the components as contained as possible. And we think that BEM is actually a really good way of doing that, and it allows us, if CSS modules evolve to a point where they can be used like no matter what the tech stack is, we can easily move towards that, having scope components, because it's just a matter of renaming stuff. That's mainly the reason, just to keep them contained. What we notice quite a lot is that a lot of our styles, well, the old styles, bleed through everything, and you have no confidence in removing anything, because you don't know what that will affect, that thing. So with BEM although the class names get quite long, you end up having a full essay on the name, it actually works for us. And we have SMACSS and ITCSS on top of it, so we can abstract the design language even further. So we have like utility classes, a way of defining the classes and the data attributes when binding JavaScripts, we don't combine classes that are both for styling and for Javascript, so we tried to look at that, and I always say that having any pattern in place is better than not having a pattern at all. So far for us BEM, or BEM if you call it BEM, works quite well. - [Man 3] My question is, I end up with pretty much the same results, so with our style guide that I managed to compose with the designers, we didn't do the mistake. I spoke with the designers first, and that was a lucky move. I see that you suggest the Markup to be applied on your components, and that's exactly what we did. We found out that the developers, at some point, would just mess up a little bit with the Markup. Now, our new solution that...on the project that I'm driving in my company, we add the components... - We should definitely chat. - [inaudible] - Igor mentioned about having some discussions, it's exactly that, basically. - And I was really pissed off at the other developers, because some developers like to Markup, some developers like to do business logic or something else. Most of them don't like to work with Markup and CSS, and they try to do the quickest solution, and the dirtiest, weakest, and "I want to go home." kind of solution. - Well if... Yeah, I totally see where you're coming from. I think it also goes back a bit to my point of future proofing. You have code reviews, you have developers that have experience... I mean, copy/pasting should not be that big of an issue. Yeah, we prove that it kind of is, from time to time, because we are not paying attention, and we forget the closing tag, or whatever, and so on. But definitely we should chat about your solution, because it sounds interesting and probably Igor wants to find out more about it. - Following on from that question, it's less, although it's a big issue, developers changing, it's about Markup, just on their whim, the bigger issue is ongoing, what happens if you yourself want to change the Markup. If you don't supply templates or components for all of the stacks that you want to allow people to use, people have to end up just making their own. I'm working for the Ministry of Justice at the moment, and therefore we use the GDS stack guide. GDS, in their wisdom, didn't supply anything other than just adherence to the stack. And I can tell you that the amount of different implementations of some of their developers trying to create their own components for it is beyond measure. I've seen at least 20 different [inaudible]. - There's nothing to argue there. You are totally right. That's exactly what we've been talking... I think we had probably like 20 hours of meetings this week to talk about that, and we came up with multiple ideas on how to do it, but it seems like we are kind of going towards exactly that. Because it's really nice to just say, "I want a billboard," and you don't care about Markup, but then we still need to figure out if that's a viable solution, and if it's something that we can actually maintain, and if it works across the whole stack. Because we tried to stay away from any particular technology so far, so we can have the style guide working everywhere. Moving to something like React means that you're going to use React. Even if it's server-side rendered, there's still friction when implementing that. But it's something that we currently explore, so if you have any ideas, or if you've already done that, please talk to us. - [inaudible]. - Yes, I think Igor did a spike at some point to try web components, again, he's tried a lot of things with the style guide, but it goes back to the whole idea, we want server-side rendering, we don't want to tie ourselves up to certain technology, something that we explore, but so far without any conclusive results. - [Man 4] I have a question and one that's about the implementation about the results so you mentioned in the beginning you would have different locations where the companies presented, and I assume the team [inaudible] and there are UI engineers in that locations, is it? - Yeah. - Do they actually use the result of your work, and if they fully adapted to it? - Good question. It's not fully, we're working on a project now that means we're going to touch a lot of the current pages, we're going to refactor a lot of them in the next four months or so. And now we're looking at fully distributing the style guide in other geographies or countries as well. But obviously, there's resistance. Like, why would I choose a UK solution when my solution just works? But looking from a business perspective, we actually want a unified solution, so we don't reinvent the wheel in each country. And if you check, most of our pages across each country, they ended up with the same solution, but just with a modifier on it, with a twist, if you want. But yeah, it also goes back to the number of people that we have available, and on one hand, the style guide makes sense to be used, because we don't have a lot of front-end developers. On the other hand, it's really difficult to adopt it in a different country, because there is only one developer that needs to deliver features, but also learn the style guide and how to use it. So we've actually been to the U.S. to Germany, doing presentations there. We're doing pairing sessions with the developers in the U.S. and Germany, and trying to get them up to speed with what we're trying to do. But in terms of actually being used in production, yes it is used, a bit, if you want. But the future looks, actually, bright with that. - [Man 5] How far you went with the components? So complex components composed of other minor components, or how far did you go with the document? - Good question. - Do you have a search box with, you know, seven components? - So far we've been looking at...if you look at it from the atomic design perspective, you can say that we have atoms which are the utility classes, and then we have molecules which bring some utility classes together with some custom CSS to create the first level of components. That's because we had to work a lot with existing designs, and we didn't...we never had the idea of components as in composed components, but now we are looking at that, because it just makes sense. We're just trying to figure out exactly where you draw the line between composed components, and it's... - And more problems within [inaudible]. - Exactly. As soon as you start having components inside components, then you need to maintain both of them. We are using components inside components, in the pages, as in in the apps. Exactly, but not in the style guide yet. - You get rubbers or factoring of your old stuff. - Sure. You always have problems. - [inaudible]. - Yes, there are always issues. I think the biggest issues are actually related to the tech stack more than typography and things like that. And moving forward we're looking at something that Henry Roberts, the CSS wizardry guy, suggested in one of his talks of using the defense CSS, which is a file that sits between the important existing style sheets and the new ones, that just cancels everything out. So you basically have the new typography, although the old one might be in the code base, you just cancel it out through that defense CSS. And as you remove components from the existing pages, you start having that defense CSS smaller and smaller, and the idea is that at the end you only have the new one. Thank you guys.