Style Guides with Micah Godbolt

Micah I am good; I'm ready for this, let's do it!

Micah Sure. I'm currently a Senior Design Developer at Microsoft which is basically a front end developer, they just don't really have that title. But it's pretty apt for what we do, we really do development but we do development specifically to get our design into our applications, so right now my major focus is on Fabric React, which is a Design System that's used within Office, Office 365 and really a lot of the applications now at Microsoft. It's a Design System that started within one drive in SharePoint but has grown and started to become adopted within a lot of the Office products and actually products across Microsoft in general, so, truly great to be able to write a rack controller that actually gets used by, I don't know the millions, I mean it's probably a large number of people.

So that's been really exciting, I've been doing that for the last nine months or so and diving head first into React and TypeScript which for me was actually a first for both of those. Prior to that, I was doing a lot of Design System work at Red Hat, building out large systems for them, writing a book on Design Systems called Front End Architecture for Design Systems on O'Reilly Press, doing podcasts, doing speaking, doing lean-in meet-up for a couple of years just getting really, really busy, so right now it's kinda nice just to sit down and focus and be able to do this project at Microsoft.

Micah Nothing at all! I have no experience and I shouldn't be here!

Micah Sure. Kind of going back to what you're originally talking about, how we've come a long way in the last three years, going from what even is a Design System and why would we ever need one and I think a lot of us are kind of at this Version 2 of our Design System thinking. Three years ago, when I sat down with Red Hat, we'd just launched our site and we were looking to try and kind of bolster the Design System of it and try and create something a little more re-usable.

I was starting to prototype the ideas and get a few things together and one of the managers I was working with asked me, so, how many times have you done this? How many of these have they built? And I'm sure a lot of people would have the same response of, yeah, this is the first time I've ever done this! Because websites, especially when you're working on a large scale website, you usually do one a year-ish, kind of thing; you don't really get a chance to do lots of websites over and over again so yeah, that was the first time I'd gotten to even try and build one.

So this is V2, this is my second opportunity to take what I've learned and start building things and I think just a couple of things come to mind with that respect. One of them is the… it's kind of going back to that Million Dollar Button thing, I'm trying to remember where I heard it but somebody'd written an article or a talk or something about the Million Dollar Button or the Five Million Dollar Button or whatever the case is.

Micah Oh, OK; nice. I must track that down again. But as soon as I saw that I was like, what?

And then within nine months I'm working on this project; the amount of work I have put into our button and the amount of times it's been re-factored and the amount of times it's been updated with new technologies and so on and so forth, but I think that the power is that as you keep doing more work and more work and more work, we keep coming down to this realisation that so many things in our Design System are buttons, are literally buttons.

If you look at a drop-down menu and all of the items in a drop-down menu, those are buttons; those might be buttons displayed in different ways, with different styles and functionality wrapped round it but in the end they need all that core functionality any button could need, so we're kind of getting to this point where we're almost looking at anything you click on really needs to be, go down to that button.

No one should be writing an anchor tag or a button tag or anything that's not just using the button component itself, so that whole concept of how could you spend that much time and effort on a button? It's because everything you click on is literally a button and there's no reason to use something different because eventually you're going to come to a point where, oh, I wish our other button that we made over here had the functionality that our normal button has. Why can't we add an icon on the left hand side? Why can't we have a drop-down menu on the right hand side? Why can't we do this, do this, do this like our other button does?

And you realise that if every clickable object can basically be a descendent or parent, whatever way you want to go, of that actual button, it means that everything has a ton of power and flexibility to it and kind of going from there, as we start building more things and as this button becomes more powerful, we've just started introducing, we're using Glamor for our style links and it's a hot topic right now of moving CSS in a JavaScript.

The main reason that we've done it is that typically, if you have a button that you want to have, say you want it three different colours; you want a red, a green and a black or something like that. You need to enumerate those in your CSS and attach a class to it or whatever you're going to use for that and so then you say, oh, a green one, and you pass the green class through; the blue one, pass the blue class through. Now you want a purple button, you have to go in the CSS, you need to add purple button and make that a class name and so on and so forth down the list, so as you need more of these colours, how do you support those without going in the CSS and doing that? Or someone has to write CSS that overwrites those styles.

And this is obviously a big problem when you've got a button that needs to be used just about anywhere: hey, I want to use a button in this instance but the styles don't match, or the padding's not correct, or whatever the case is, now I need to write some styles to overwrite it. And what Glamor allows you to do is basically make… in the end, you're still the style tag with a selector and some CSS attributes; properties and attributes, but the way that tag is created is actually at run-time for us now, so every time a button is created, we pass in all the properties of, I want the colour on hover to be green, and you can actually pass that through as a property, so when that button gets rendered, it now has the hover colour of green.

Now there's some over-ride of more specific selector, not as a… oh, now we have different variants in our CSS and we're using a green hover variant; these are values that can be mixed down into the button every time you use it and this is hugely powerful because building this new command bar; we had a command bar that used to just be this monolithic, everything in the kitchen sink, all the functionality built into it, and now I'm breaking it down into all these tiny little pieces and one of those is obviously a button because it's a bunch of buttons, there's some overflow menus and those kind of things, and now in the contract, in the API I have for this command bar, I can literally say that for every item you have on a command bar, you can pass in a set of styles, you can pass in a set of icon colours and background colours and hover colours and all these things that now get mixed down into that button, all the way down at the bottom of that stack so that you can have, oh, I need my icon to be the first one green, the second one red and the third one purple and you can do all of that without a single CSS selector, without having to worry about specificity, without worrying about adding extra bloat to a CSS, or any of that and that's really an amazing place to be: we're able to now start leveraging the flexibility and the power of these really focused and really capable components as you start building larger things with them and seeing that level of flexibility has been really amazing because we're trying to build one command bar that can be used in Microsoft Word, that can be used in Outlook, that can be used in OneDrive and SharePoint, that can be used anywhere, and we don't want to have to add all these, well, here's the OneDrive version, you could pass a class for that, and here's the SharePoint version, you can do a class for that.

We're trying to make something that's powerful enough that you can pass in whatever you need for whatever styling and so you can override the button and use a different render function for that.

It's really kinda neat that, it's kind of moving onto Design Systems as a set of styles but also Design System as a set of functionality, because when it comes down to it, Fabric still has styles and it has, this is our visual language that we use within our product, but we try and make that visual language something that doesn't get in the way if you need it to look completely different, and I think maybe that's the Style or Design System 2.0 as you start wrapping up functionality around all these components as well, making them really capable.

Micah It's kind of crazy and I completely agree and hopefully we'll get to a point where we don't need to do that.

The best thing would be if we could actually compile Sass on the fly and pass the variables in to that Sass file before it gets rendered; that's basically what we're looking to do but right now, the way that works, it's in the build step, that Sass file. Before, without CSS and JavaScript, the Sass file actually gets converted into CSS and then stored as a string that then eventually gets passed to the component, so right now, that's all happening on build time rather than at run time, so as soon as we're able to at run time make those changes, it's going to be a whole lot easier, whether that's a better support with CSS variables or, gosh, just being able to compile Sass in the browser, I don't know what it's going to take, but I think the point and the value of what we're doing is showing, this is what we want to do and we want to be able to say, hey, render this button but here is the values that we want to go into that CSS; we want to do that and we've found a solution for it, it takes JavaScript and hopefully, eventually, we won't have to do that and it'll be something that will be supported within better tooling, within better browser support, within better something but we're blazing the trails as to where we want to get and hopefully a road will come after us.

Micah I mean, the thing about it is, you're not not writing CSS; the end product is still CSS, we're not talking about inline styles, we're not talking about not creating CSS properties and solving things with CSS. It really comes down to how the CSS get into the browser and what processes can you effect on it before it gets in the browser, and so when you start looking at CSS in JavaScript, you're basically looking like a big JSON object that pretty much looks like CSS except you're using commas instead of semi-colons and you've got quotes around your values.

Otherwise it looks like CSS: you've got background colour is, whatever your background colour and you have font size is whatever your font size is, so you're still doing all these things, it's just where do they get stored and right now we're doing it in JavaScript because we want to be able to, at run-time, be able to process that JavaScript and do things to the JavaScript before it actually prints to the page, and that's for us the power of it.

Beyond that, you're still creating CSS in the browser and the CSS has to work like CSS does, so I don't think we're taking away the pain of CSS; if you like the pain, it's still there!.

Micah We're changing the place that you write it and in a way, at least at this point, we're replacing Sass variables with JavaScript variable; we're replacing Sass mixins with a JavaScript function, so it's really the same kind of building process for your styles, it's just in a different language, but the end result is still the same.

Micah I write my Angular tools.

Micah Yeah, there's a ton to impact there, you could probably do a full podcast just trying to dive into all the pieces there. A little bit of history of Microsoft is that there's been a couple of attempts to try and to this, to unify the tech stack; you know, the pieces that we're building, so we're not in these silos all over the place and there have been a few attempts with some home-brewed applications and whatnot because right now, it's a mix of some knock-out over here and some Angular over here whatnot and really we found ourselves within the last year or two of everyone is starting to want to move over to React, so for us, as far as organisationally, for us it's worked out really well because there's been so much movement towards React, where so many different organisations that have independently gone: hey, this would work really well for what we're doing and we really want to get on board and then as soon as they find out, hey, there's also this library of controls that we can use, they've wanted to do it even more.

And kind of going back to the original question of why would you do it versus why tie into this tech stack and get dependent upon the tech stack, it really comes down to, again, this kinda like Design Systems 2.0 that a Design System is starting to be way more than just how a button looks, because we kinda started in this… Fabric started as just a set of CSS and HTML that showed how a button was supposed to look, or how a drop-down was supposed to look but then when we got feedback towards, hey, what happens when you click on it? I need to see what happens when you click on a drop-down and to see the drop-down; we need to… part of the visual language is, how things open and close and whatnot, so we needed to see that.

Micah And so we went about writing some JavaScript to show how that worked and writing some more JavaScript to show how that worked and now here's a people-picker where you tack names in and it shows a list of people; all right, write some JavaScript to show how that worked and we're just writing prototype JavaScript to demonstrate how all these things work and we write more and more and more and more and we were like, oh, this is getting kinda big; let's start writing some helpers and some extra things and eventually start writing our JavaScript framework to make this whole thing work and some bad things came out of that; for one, because the JavaScript they wrote was really just for presentation, really only intended it to show how its components work but then people wanted to just take our mark-up and our JavaScript and now put that in their application and so now we're like, they're asking us to support that and we're like, well, that was really just for prototyping!

So it's one of those… are you going to show the interactions of a component inside of your Style Guide, and if you are, there's going to be quite a bit of JavaScript that's required to do that.

So as soon as you start going down that path you're like, well, are we going to be writing this whole framework ourselves or should we maybe choose a framework and have that part of our Design System?

I know you don't have to go that path, if you look at Lightning Design System, they very specifically, when you go to their page and you look at components, there's no interactivity to it; if you see a set of tabs it's like, hey, that's nice, those tabs and mark-up. You click on the tabs: nothing happens. You click on the drop-down: nothing happens. Because what they are specifically trying to do is say, this is how it looks. They might have a couple of… here's five different panels of it; here's the closed state, here's the open state, here's the selecting state, so on and so forth, to demonstrate each of those. But they're not writing the interactivity for someone to go in there and play with it and that's a very intentional decision and I've even brought it up a couple of times internally of, hey, should we do this? Take our styles and our markup out and give a peer presentation of it?

And it really comes down to what's the value of it for our team? For us, there's so much work that's gone into making that button do what the button does inside of React that we really would rather just people use that React component and for us to have to maintain both of those and support a team trying to use Angular to do the same thing, it really comes down to we're a product team and our product uses React and for us to fund something that's not directly going into our product, it's not going to happen because we're a product team and that's what we do.

So there's some external forces that kind of made that happen but it's definitely, it takes some real intention to keep those two things separate and there's certainly that question of well, why keep it separated? As an organisation, do we need to support all of these multiple languages because so much of the work that we're doing is really, it's the animations, how things open and close, how you interact, how you tab through things, how arrow keys work inside of a list: there's so much stuff there that is part of our experience that people just get for free when they use the React component that you'd have to completely rebuild in any other language or framework, so when you start looking at a Design System as more than just how something looks but how also something works, then you need to have an opinion about how it's written and sure, you can do it in just pure JavaScript but…

Micah Exactly.

Micah Yeah, it comes down to the team, the team structure and really the charter. What is the business use-case for the work that you're doing? And if the business says, hey, we want a Design System that is going to meet the needs of Angular and React and KnockOut and X-Y-Z, you're like, all right, what's the staffing requirement to do that? Great, let's get the staff to do it. Now, what's it going to take to make all that work and let's make sure that each product align about this behaviour and those types of things so there's a ton of work that goes into that and the question just comes down to, is that the business charter? We're willing to put money into making this happen and for us, we're using React so that is the direction that we're going with it and if the charter changes in the future and hey, we want to support Multiple, we're like: all right, we need more staff in, because really it comes down to at this point it's a very small team, it's really just two or three of us that are really focused on it primarily and then past that it's very much a federated project where we've got all these other different products that are using Fabric that are contributing pull requests and bug fixes and lots of issues that are using the product and able to contribute back to it.

So it has been a great exercise in how do you create a Design System within a federated approach where you don't have this large core team to push it and you kinda have to be a little bit more of a cheerleader and maybe a sheep wrangler or something to try to figure out, how can we set things up so that anyone can contribute and be successful and add to the system in whatever small spare time they might have inside of their product, so yeah, it's been an incredible experience to say the least.

Micah Sure. We're actually close to doing it!

Micah We have a couple of hurdles. One of the things I came on nine months ago, I saw we didn't have any visual regression testing; I had a bit whiteboard behind me and I was listing out the things I want to get done and a big one right at the top was visual regression testing because a lot of it is we have, especially in a federated system, you want to make sure that when someone chucks some code in and re-factors some CSS or CSS in JavaScript or whatever the case is, that your component continues to look the same regardless of those changes and we didn't have that at all, so we went about writing it and the challenge… I'll kind of jump to this.

Visual regression testing is not as mature and complete as I really want it to be and I'm afraid it's losing a little bit of steam; I really hope the steam picks up again. Just because there's a lot of technical hurdles to get over and there's a couple of open source environmental issues that are hampering it as well, so there's two approaches for visual regression testing. One is with real browsers and one is with headless fake browsers and the way that you typically do it, really the majority of visual regression testing suites are built right now are using PhantomJS and often using Casper which is a set of JavaScript bindings to basically control the headless browser. And there's a lot of great tools written in it; I've used it a bunch. We used it at Red Hat really successfully and that's actually what we've built within Fabric right now that just hasn't gone live yet.

One of the challenges is it's open source software and it's had a little bit of a rocky life and then CasperJS looks like it was dead on the vine at one point, and then it got resurrected, the ghost came back up!

Micah In a friendly way, thank you! So that was great, hey, Casper is on board again and PhantomJS is at 2.0 and it's a little bit more modern, so we're doing good and then Headless Chrome came out four or five weeks, six… a couple of months ago and within a day or, I think seriously within the same day it came out, one of the head maintainers of PhantomJS said, all right, that's it: I, we, whatever, are calling it quits with Headless Chrome coming out that pretty much makes the work we're doing defunct and we really think you should go use that instead!

Micah Great!

Micah Implementation aside.

Micah I painted a really horrible picture of this!

Micah Yeah, it's all dead! Because the other approach, I think Headless Chrome is going to make a huge impact within a year or so, once people start writing for it and it gets mature enough, because once you can do that, then you've got solid, current, modern browser to do all your visual regression testing, and at least for Headless.

The other approach is also you can do it using Selenium WebDriver which is the same thing that BrowserStack uses, the same thing that Sauce Labs uses and that's a great tool because basically you're telling… you're basically remote-controlling a browser and getting screenshots in it and it's a great tool; I've used it personally a couple of times, it's just mostly a workflow question because it requires getting Java installed at your dev machine which can sometimes be a little bad, so for us it's mostly just trying to get over that technical hurdle of workflow, but it can be done.

So to back up real quick, what visual regression testing does is…in unit testing, what you do is you have a function that adds two numbers together and you want to make sure that function always adds two numbers together property, so in unit testing you say, adding two number function when I pass in two and three, it should always equal five and if for some reason that function returns seven or three or a banana, then something's wrong and my unit test fails, so that's unit testing with functions.

It's basically the same idea with visual regression testing, but instead of a function returning a numerical value or whatever that return is, the function is going and taking a screenshot, an actual png screenshot of your component and then comparing it, instead of to my result should equal four, it is, my result should equal the last picture I took, so if you have a button that’s blue with a white border and every time you take a picture of it, it should be blue with a white border. If one day you take a picture of it and it's green with a purple border, when you compare it to the old one it should go, hey, these two images are different and literally you're going through and comparing pixels, like pixel 00 in the top left, what's the value of it? OK, let's compare the two; it's literally going through and looking at all the pixels and seeing if they compare.

And it's a great tool to use because if a padding changes accidentally because you thought you did something right but you actually screwed something up, the two images are going to be different and it'll go, hey, there's a problem here. And when you have a large system with lots of variations, say you've got a button that's got five different variants and several different states and hover states and click states and split buttons with, what happens when you click and then focus and you're like… arghh, so many different variations!

Literally having to go in and every time you make a tweak to the button and go through every single state, OK, what was the focus state on this again and having to go back to red lines and check, it's basically a manual red line checker because the red lines are now all of these baseline images that you captured and you're able to just check, say there's a hundred of them, especially with buttons, you could have a hundred of these things, and to quickly go through...

Micah That's exactly one of the problems.

Micah Yeah, you can…

Micah If you have a Mac or a PC, fonts render different, or different fonts are installed.

Micah So you have different versions of browsers; the challenge there is to get a consistent test environment, which either a headless browser like PhantomJS, that's why that's so popular is that when you npm install, it literally installs this browser for you, so that you can lock in what version of browser people are using. The other approach to this is that all of the testing happens in your build process so in Travis CI or your Jenkins instance or something like that.

Micah Oh, definitely fail!

Micah The idea there is, if you are checking baselines into the Git repo, the reason that you have something fail is because baselines don't match what the new styles are, so say you're asked to increase the padding on the button, of course, that test is going to fail.

But then the process after that should be, it's just like if you change a function like a JavaScript computational function, like now my add-in function does return banana, you need to actually go and update your test to say, I'm expecting banana to return so when I make that change to the function, I also need to update my test, so the idea there is that if you change the button and now the button fails, you need to include the new baseline along with your pull request because then the next person has the new baseline and your new CSS so that it doesn't fail for them.

So yeah, if you are going to be including in baselines in the Git repo, that means that any time you add padding to a button, you also need to, in your pull request, which is actually kind of a neat thing is, hey, I've got a pull request that's adding padding to a button, you can see the CSS…

Micah Yes, so, your pull request will actually include that screenshot as well, so you're like, that's what the new baseline looks like and when that code gets merged in, it gets the new CSS, it gets the new baseline and the next version that will run the tests, if they don't make any changes, should run and pass. And of course you have to get past some of the challenges of differences from one person's machine to the next; that's kind of the problem we've ran into now is, even PhantomJS from one browser to the next we're having, for some reason, errors and so one approach to that, the solution is that all of the testing and all of the baseline creation gets done in one place, so we're trying to get Travis to do that…

Micah Yeah, and the only problem is, Travis doesn't have file storage so you literally have to, in your build step, push those files somewhere else and that's basically where we're at right now is just getting that set up for it to push the files somewhere else that we can get to them so we can pull them down, so if there is an error and a new file gets…you've got more padding on your button, you can go get that baseline and update it. This wasn't a problem when we were doing Jenkins previously because Jenkins was its own… we had an instance of it with its own file storage so we could just pull the file directly from that.

Micah I'm really hoping to have this Chrome as a solution there once the UK is mature enough…

Micah It should hopefully do exactly what PhantomJS does which PhantomJS was basically just a WebKit browser implemented in JavaScript so now that we're moving to having a Chrome version of that, hopefully that'll fill that gap and we'll find some even better tooling. It just might take a little bit of time. The other approach is obviously going a Selenium route, using to make sure your build stuff… as long as it builds stuff will build the artefacts… I've had talks on it, it takes forty five minutes to explain!

Micah There's a lot to it!

Micah But when it's set up, it's a beautiful thing!

Micah Definitely will.

Micah Hey, thank you guys and if I've one last plug I can possibly give is that I will be at CSS Dev Conf this year which is going to be in New Orleans again in October, certainly check that up, but I'll be giving a talk there specifically on React and Design Systems and then we'll also be giving a workshop on Design Systems, so if you're curious about how to build a Design System out, I don't think I'm going to dive fully into React, it's going to be a lot more in kind of the core essentials, but how to take a design, break it down into smaller pieces, how to use the tools for documentation, for visual regression testing and all those types of things, check that out, CSS Dev Conf and I think there's still some spots open and that's our workshop as well.

Micah Awesome!

Micah Hey, thanks so much for having me on! Bye.