Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode we continue the interview with Marcelo Summers and Jon Gully. They talk about pattern pack and a bunch of other interesting things. If you did not hear the first part of the episode, make sure you go back and listen to that. You can find it at spec.fm. We do not have a specific sponsor for this episode but this is the last episode of the year and I want to say thank you to everyone who has made Developer Teapossible this year. Not only are sponsors but also all of you who are listening to this show each and every week. This has been an incredible year. We've had a lot of awesome things happen to the show and I have only you all to thank. So thank you for listening to Developer Tea. It has been such an incredible journey launching this podcast this year. The official one year anniversary is January 5th and of course you can expect a special little episode on January 5th to talk about what all Developer Teahas experienced over this past year but again I want to thank you so much for joining me on this show. If this is your first time listening and you want to be a part of the next year long journey with Developer Tea, please go ahead and subscribe in whatever podcasting app you are using and then join us in the Slack community by going to spec.fm slash Slack and you can come and talk to me and many other people who listen to the show, who are developers and who enjoy talking about these subjects. Let's go straight into the interview with Marcelo Summers and Jon Gully. I think anybody who's listening to this, you are either totally convinced by now or you won't be convinced that a pattern library makes a lot of sense. Regardless of if you use pattern pack or not, pattern libraries are a very good idea especially for systems that if you're doing like a one page site that you know is not going to be expanded into a larger project or perhaps you know maybe it's maybe it's just a marketing page that is expiring for a particular event. It may not be worth your time to invest in creating a pattern library but if you are creating a project that's any larger than that especially if you have multiple developers working on that project or perhaps that project is going to be handed off to another team in the future. Having a pattern library, it's not only a valuable thing for your developers, it's a valuable thing for everyone involved. The stakeholders now have a reusable system that they can take to anyone anywhere and they can visually see what's going on and how that application is constructed. It's almost like having a brain guideline system except more practical than that. Yeah, absolutely. When you were talking about that, something that popped into my mind is we built pattern pack to solve a specific need that we have, that we've open sourced to other people, you know, have some other people have caught onto that. But there's a really great website out there called styleguides.io and they have an entire tools section that just has dozens and dozens of tools you can use to build a living style guide. There's a lot of different approaches and I think what's important, you know, the big message that we always try to convey with pattern libraries is you have to do what's right for your team and your organization and your specific situation. And, you know, there's tools out there that you just literally write comments in your CSS and it generates the style guide from that. You know, there's other tools that will comb through existing CSS and spit out your style guide for you. Those were in a fit for what we were trying to accomplish. But I definitely encourage anybody who's like on the fence or interested in learning more about this to go check out the wide variety of tools that are out there to see what might work. You know, there's some tools that are much lower friction to get up and running. But maybe if you're trying to scale this to be, you know, shared across multiple applications for an organization of hundreds of developers, it's not the right fit. You know, so go out there and find the right tools and find the right processes. You know, that's that to me is the most important first step in doing this for anybody who isn't, right? You shouldn't just go out there and declare an intention to start a pattern library and just start making it. This is about getting people together and having the right discussions, right? So a lot of times this might bubble up from design or maybe it'll bubble up from development. But what's important is that design and development and product ownership and marketing or branding or anybody else, you have to get all those people on board with the direction and the idea that you're going to be using a design system, right? You can't have a designer and marketing that's going off doing their own brand ideas and designing marketing pages separate from the application. If the if the entire organization is meant to be working on this single design system, right? This is an organizational problem, much more than it is a technology problem. Yeah, the perhaps the worst thing, even worse than not having guidelines is having guidelines that are not actually followed, right? Or are only marginally followed because if you have a system and you have multiple pages that or whatever, multiple applications that your agency or your team is working on and you have a system that is documented and shared with everyone. But then you have two or three rogue people who are just against it for whatever reason. They haven't bought in and they haven't seen the value in it and they're still doing things outside of that system. Well, now when you approach a page, not only do you have questions about whether or not that particular page is going to use the system, but it's possible that a page that at one point was using the system no longer does, right? So it becomes even more confusing and it's almost better to just go all the way one direction or all the way the other direction. There's nothing quite as bad as out of date documentation. I would rather be forced to read source code than to read out of date documentation and trust it, right? And that's the same thing for pattern library. If you have a pattern library, that is, it's a facade. If somebody says that they're going to follow this and then they don't, well, now you have a bigger problem on your hands because then you have to go and find out which things are not following it. You have to go through the process of cleaning up the things that haven't followed it in the past. Ultimately, the only way to make this work and make it work well is to have everybody buy in to the reasoning of why you are using a pattern library. Yeah, absolutely. And I highly recommend everybody to go on BDM and look up a blog post that Nathan Curtis wrote several months ago. It's called team models for scaling a design system. And in there, he basically dives into something that we've seen across the clients we've been working on where he identifies three different models for these design systems. The first one is kind of this solitary model where there's a designer on a product that has this idea of, hey, I'm going to build these shared styles and let the rest of the organization use them. And so they go and put that out there. And I think in a model like that is the highest likelihood that you're going to run into the situation that you just talked about where you put something out there and nobody uses it, right? Because it's one person just saying, hey, here's this cool thing that I built. Then he goes into a model called, that's basically a centralized model where a company, you know, says, hey, we're going to build a design system team and put them at the center and they're going to build a bootstrap for our organization. A lot of times when we first start with clients, that's the direction they think they're going to go at the end of this, right? They're going to hire a designer and a developer who are going to own this. But what ends up happening is you lose the context of the applications that are consuming it. A model like that works fine if you have one application that is consuming your pattern library. But then I might argue if you even need a pattern library, what you really need is what he goes into, which is the third model. It's a federated model where you have multiple people from multiple disciplines working on different products all coming together and sharing what they've learned to enhance that design system to work for the entire company. And so you might have designers coming from your mobile application and designers coming from your big data and reporting application that's plugging into Salesforce or something crazy like that. All those people are going to bring a different context and a different flavor. And so it's important is to have those different voices. So he talks about that in team models for scaling a design system. I think he has another post also where it talks about achieving platform balance within your design system. Again, Nathan writes some amazing stuff about design systems that's inspired a lot of our work. But I highly recommend going looking at that because it gives you a good perspective for how you might scale this in the long run. I think a lot of the design systems that we're building, at least early on in this initiative that Jon and I were doing, we would walk into a project midstream, you know, with a few months left and we'd go and implement this pattern library, right? We'd find a way to kind of work it in. But now as we're doing this more and more and kind of even making it a core part of how we kick off the projects, we have to think long term about how these organizations are going to scale it because our project team might be bought in. But the question is, will the client team be bought in once we're not there? And really, you know, this is ultimately about creating value for the client. That's what this is for is to create value for the client because even if you are engaging in the creation of something like a pattern library for a client, even if your intention is to make it easier for your Developer To create something that is acceptable in a less time, right? Well, that ultimately delivers value to the client because you are now able to move faster, you're able to deliver more with less resources. And so if you can focus on making ways for the pattern library to deliver more value to the client, that's the ultimate goal. Yeah, I agree. And, you know, one of our goals and something that we try to build is a tool that generates so much excitement from the Developer That are going to own this that they can't help but want to use it because it's valuable to them, right? That's the easiest way to evangelize a design system and get other people buying into it. So we have this idea of having a pattern library available to use on a project throughout a project or throughout multiple projects. I think an important piece of this though, and Marcelo, you've mentioned this to me before the interview is versioning and having a way of actually distributing a particular version of the pattern library. How do you recommend kind of going about making sure that whatever your particular version of a pattern library is obviously known as a dependency for a given iteration of a project? Yeah, Jonathan. That was a really key part to this. One of the big struggles that we would actually have when we're working on longer running projects was really around how do we envision new and changing patterns, adopt them to maybe new business needs, new requirements, while we're in flight developing something, right? So I have a component and it looks a certain way. But then our president of the company comes in and said, you know what, I've seen this thing, it's great. Our component should work this other way instead. I love this, you know, it's purple instead of blue. Whatever his new requirement for that is. And so then the people working with the stakeholders have to start envisioning how the application could look and feel with this new direction. And how do you keep that separate from the work that's going on that's been playing? Maybe there's another two or three weeks worth of work that that is continuing on or maybe there's a whole nother application, you know, in this case, we're sharing the same design system between multiple applications. How do I continue on with one application and then absorb these new design patterns without breaking the other, right? And so this was a really important piece of the puzzle that we thought we had to solve in order to make this meaningful. So because this is published as a package on NPM every version that is published or every time you publish it, it is given a new version. So you can release multiple, multiple versions of this and your versioning strategy that you use for your applications can also be used for your pattern library, right? So you can imagine a development branch ongoing development for a release that's going to happen next year and we're working on that. But in the meantime, there's a bug that came in, you know, we introduced something in the production application that's broken a screen and we need to be able to fix that. So your branching strategy that you use for your source code for the application, you can apply that same strategy to your pattern library and then release versions. If what's in production is version 2.3, you can release a bug fix for version 2.3 and publish that while your developers are working on the new and shiny version 3.0 that's not going to come out until next year. So you can have these things working in tandem and you can have confidence that making a change to the design system for the new future look and feel won't bleed over and break your production system. Does that make sense? Absolutely. Yeah, I think that's a great way of handling it. Which I mean, really all we're saying here is use versioning, right? Like if you have, especially if you have semantic versioning, you're hopefully you are doing this with your projects, especially projects that use multiple versions of a particular design system. If you have semantic versioning, then you can bump the version by a major release number or even a minor release number. If you understand how semantic versioning works, then you can avoid breaking changes, right? So you can release a bug fix to an old version without having to overwrite the new versions and you don't have to upgrade your old version to the new version in order to add new features to it. That's the whole point of semantic versioning. I will include a link in the show notes, by the way, to describe a little bit more about semantic versioning for those of you who are listening and are not aware of how semantic versioning works. But that's of utmost importance in a project like this when you are building something that possibly could have multiple versions. Don't just build it with the now in mind. Build it with a long term vision of how could this thing be forked, right? How could this thing possibly be applied in five different scenarios? Is there a way that we can say, okay, you know, we don't necessarily need to update every single page or every single iteration of this particular design or particular look and feel? We just want to update it for this particular project, right? The semantic versioning is a great solution to that problem. That's actually what we promote for PatternPack. However, the project itself is not opinionated. If you have a different strategy for versioning, you can follow that same strategy using this tool. This really all becomes possible because what we're doing is creating the design system in code. If you had created the same design system in a design tool, a Photoshop tool or an action type tool, because they're not really handled as source code with a version number attached to it, it becomes a lot more complex to do this type of thing. But because we are promoting the concept of creating the design system actually in code, it makes these type of things available and makes a whole class of problems that a lot of designers suffer today. Just make some go away. And something that we really advocate for on projects, because this really is something that changes on each project, is really taking that idea of semantic versioning, which is the idea of major minor and patch releases. But defining for your design system, what one of those releases mean. So a patch release might just be true CSS bug fixes. But then if you're adding or deprecating components that you've built, that's a minor release where then major releases are true, like rethinking of the design, major breaking changes, don't upgrade to this unless you're ready to redesign. But again, that's going to change per client. We've had clients that bump their pattern library version every two weeks just because that's their release cycle and they put the pattern library matching the rest of their application release cycles. What's important is that the design and development teams are on the same page about that and what it looks like. And then getting into predictable release cycles, right? As your design system becomes more mature and the design teams going out and iterating, it's so important to have, you know, every two weeks, we're going to be cutting a new release and there's going to be updates. And if you have a bug, it'll make it into one of those two week releases. But being able to communicate that within the organization is just going to make it easier for Developer To consume that. In the same way that maybe a shared services team or an internal API that you build, you would have to do those same those same communications. Another huge benefit of the pattern library when it comes to versioning and releasing is testing, right? One of one of the worst issues in CSS is that idea of unintended changes, right? Two CSS properties walk into a bar, a bar still in a completely different bar falls over, right? But if you're building your CSS with good practices from the start, where everything is this modular component and you have this static site being generated, it's much easier for you to test changes in that context or even we've even started towing recently with visual regression tools, you know, that can run a lot faster on a static HTML website that's just my pattern library rather than trying to go through an entire production application that's wired up to a database that might be a little bit slower, right? That's something that could take five to 10 minutes to run on a huge application, but you could run in 30 seconds on a static pattern library that's, you know, 15 or 20 HTML pages. Yeah, yeah, that is hugely helpful. In fact, there was a discussion on visual regression testing at CSS DevConf, which is actually where I met Marcelo, by the way. And the discussion was really good. I thought, you know, thinking about regression testing for visuals, that is a kind of uncharted territory currently, right? Where most of the tools are relatively not matured all the way yet. And so there's a lot of space there for more work. So if you're listening to this right now and you're wanting to create an open source project, that is a very like ripe for a lot of development. That is an area that could use a lot of energy, I think. And a pattern library, in my opinion, is a perfect place to start as a baseline for, you know, establishing a way of doing visual regression testing. Yeah, absolutely. You're kind of reading into the future of where we think this is going. You know, like you said, that area is not very mature yet. We definitely hope that there are some great new tools that we can leverage, but the use of those things together in combination could be a very powerful tool for someone creating a design system and ensuring quality in what we're doing from the visual side as well as the code side of things. Yeah, let me clarify for anybody who's listening and you're not aware of what we're talking about here. Visual regression testing is, if you've ever heard of test-driven development, basically what you have is some programmatic tests, typically this is the way it works. You have programmatic tests that you can run to ensure the validity of the code that you've written in the past. And up until now, really, the primary use case for this is to ensure that the workflow or the application flow is correct. That's called a feature test or an integration test, but also to ensure that your logic is correct for a given class, for example, if you're writing in Ruby, that is considered a unit test, typically those are the words for it. What we're talking about here with regression testing, regression test, make sure that something that you introduce new into a system doesn't break something that already existed in the system. And so what we're saying for visual regression testing is introducing a new design element, for example, and ensuring that that design element or those design rules have not accidentally affected something else in the system unexpectedly. And the hard part for doing this up until now has been that the only way to know for sure is to put eyes on that particular design element to make sure it looks like it did before. That's the difficulty. Now, what we have seen in development is the ability to do even things at the pixel level, checking the pixel rendering of a particular design element against the new one that you've created. So re-rendering the old one and re-rendering the new one, and comparing them to make sure they're the same. That is an example of a way of doing visual regression testing. Yeah, that's exactly it. And I actually attended the workshop that Micah Godbolt and Kevin Lamping put on at CSS DevConf. It was a great workshop. They dived into some tools like Rath and WebDriver. It's a very challenging space because browser development by itself is a very complex thing. If you think about it, there's not a ton of people that are low level enough to go build a web browser, basically, and render HTML and CSS and JavaScript. And so the way that most visual regression testing tools work is that they spin up a headless browser in the background. And basically go through a defined set of URLs and take screenshots of each page. A lot of times they can fake interaction, like clicking on something, hovering on something, and take those screenshots. And what's great is if you commit those screenshots to a Git repository, you can set a baseline and Git does a great job of visual dipping. Where if an image changes slightly, you can see that it changed. And so a lot of these tools then they'll abstract on top of it and basically build in functionality where they'll use the Git dipping to overlay a pink box where something looks different from the baseline that you set. What's challenging is all of these tools are open source tools. They're not super mature yet, I would say. So there's a lot of kind of working around weird quirks or you're building, it only renders Firefox and you're building a project that only needs to support i.e. or Chrome or something. And so there's just a whole multitude of challenges in that area, but it's definitely a direction that we're trying to explore more right now and see how we can incorporate into our design and development process. Because it's something that machines do really well that humans, it's super time consuming and they don't do well. I mean, testing in general is that way. If you have to reload your browser and try to diff with your eyes, for example, like if you're looking at one thing on the left and one thing on the right, I'm working on a project right now where we have a previous design, had a perfect circle and the new design has a typographic O. And the typographic O has replaced what was previously perfect circle. It's a little bit difficult for my eyes to tell the difference sometimes. I can look at it for two or three seconds and know the difference, but the computer knows the difference instantaneously because it's just pixel differentiation. That's an example of a situation where a computer would be much better at telling the difference than a human would. Now sometimes humans are much better at certain things than computers. For example, facial recognition, humans are better at that than computers are, but computers can do that. We can teach computers a lot of things. Without getting too far into the weeds of artificial intelligence or machine learning, we won't go down that route. But this is a very wide open field for open source to grow in. And I think projects like Pattern Pack make it an adoptable field, right? Make it available to the general public to start realizing that we need it. As developers, we need visual regression testing. And we need the tools that make that a little bit easier to do. Yeah, if you're someone who's out there with a real passion for this and has a great new tool, we'd love to hear about it. Definitely. I would too. Marcelo and Jon, I've really appreciated your time today. I'm going to ask you a few more questions that I like to ask all the people who, all the guests who come on Developer Tea. Do it. The first, the first question that I have for you guys is if you had just 30 seconds to speak with any developer, all developers, if you could give them advice in just 30 seconds, what would you say to them? So for me, something that's great about being a designer or a developer, right? I'll kind of split mine since I kind of come from more of the design in UX world. We do what we love. Right? This is something that even if we weren't getting paid to do it, we would probably go do it as a hobby. And a lot of us do, right? We get home at the end of the day, we go hack on side projects, go contribute to open source. But I would say for me, the times in which I've become a better designer developer are actually the times when I step back and go have more balance in my life, right? Spending time, ironically, spending time with my family or friends or getting out and doing something else in a way from the computer are the areas in my life that's giving me the most perspective that I then bring back to my job and grow the most. So while, you know, again, I'm saying this as a person who now, you know, co-maintains an open source project with Jon, and I'm constantly hacking on side projects, you know, I'm constantly keeping that in check and making sure that I am still a well-rounded and balanced person. Yeah, that's a good perspective, Marcelo. And it kind of leads towards, or it leads into my comment, which would be, you know, a lot of times it's easy for us as Developer To get caught up on solving an individual problem and getting really deep down in the weeds. And so the best thing that I can encourage developers who are really getting stuck on something or really working hard at something is make sure you're taking the time to pick your head up, look around, understand the problem that you're truly trying to solve, not the problem that's in front of you, but the objective and goal you're trying to achieve, because there's many times when I find myself really working hard to solve something that's very difficult. And there's just a different solution that's right in front of me. And if I just take a step back and look at all the options that are available to me, there may be a different path to go down. Writing code is actually not the hardest thing that we do, right? Breaking down complex problems into smaller pieces in a logical way is the real challenge of being a developer. And so making sure that you're taking the time to focus on that and not the code is probably the best thing I could encourage somebody to do. Yeah, that's that's really good advice. I think the most important piece that I'm going to take away from what you said is that writing code is not the hardest thing we do. And that is so true. And it's difficult to think about it that way because it makes up the majority of the output that we have, but ultimately it is not the hardest thing we do. Solving the problems, that is much more involved and much more in your head than than the code is. Great answers. So the next question that I have for you guys is what topics do you wish people would ask you more about? We're both giving each other inquisitive looks over here and deep thinking. Now you've got some really good questions. These are the things that are actually important in what we do. So I have my answer. I'll go first then Jonathan. So I think the thing that I would like people to ask me more about, I often bridge the gap between developers and designers. And this might be an ask for the folks who sit on the design or the UX side of things. I would love if they would come to us as developers more frequently. And just ask us to be in the conversation. Be a part of the design process because while we're not necessarily the person looking to set the look and feel of the application, there's often a technical perspective that will lend itself to those conversations and inform the design, the interactions. So I would love to be more engaged in some of those things earlier on rather than the recipient of that information later down the line. I'd say for me, especially when I look at our consulting projects and the type of work that we do around pattern libraries when we get to do it, clients often want to bring us in for the technical skill. Like hey, we want to build a pattern library. Come help us do that. But like I said earlier, pattern libraries are less of a technical challenge and more of an organizational challenge. And oftentimes I find companies that are very stuck in a way of doing things. And they set up their pattern libraries for failure because they're stuck in a way of doing things. So oftentimes I wish clients would ask me, and this is so hard to say in a humble way, I guess. But oftentimes I wish we could have more input or have more influence around how organization structure this long term maintenance of their pattern libraries and keeping these up and running. We try to give input, but so often when we walk away, we don't know how that's going to keep running. There's so many great practices out there. But if you're just trying to wedge this into how you're doing things today, oftentimes we're working with organizations that need help. That's part of being in consulting. But if you're not going to make the changes that you need in your organization to support the long term life of your design system, it's going to die. It's going to fall off and it's going to become irrelevant. So all of that investment is going to go away. That's great. Yeah. It's hard to say, you know, I wish that you would talk to me about how to do things better. And like that's a difficult thing. But that is our jobs. Our jobs as developers are to understand kind of the fundamental systems, the underlying pipes that run between things. And that is, you know, that's why things like pattern pack, we have to create those things to support the different initiatives that we work for. And I think that's a perfectly fine answer. I think that is exactly the way that developers and designers really should be thinking. Well, guys, this has been a fantastic interview. I appreciate your time and your answers. And for sharing pattern pack with the world, thank you so much for creating a fantastic open source project. How can people find you and find a slalom? Are you guys hiring by chance? We're somebody, we're a company that always likes to be talking to people. So whether or not we're hiring, you know, there's been people that, you know, we talked to them and hired them a couple days later. And there's people that we talked to and hired two years later. So you can find, you can find slalom at slalom.com. We have offices in most of the major cities in the US, you know, New York, San Francisco, Seattle, etc. Outside of that, you can find pattern pack at pattern pack.org. And from there, we have a lot of, we have links to GitHub. We've got a Slack channel that you can join if you'd like support. And if you just want to find Jon and I individually, I'm Marcelo Summers on Twitter. And I'm at Jon Gully. And I'm just really glad, Jonathan, you had us on the podcast. This is something we're obviously very passionate about. So we're always excited to get an opportunity to share this with others. And we really appreciate the work you're doing here and giving us an opportunity to talk to your listeners. Absolutely. Thank you guys so much for your time. And we will include all the links in the show notes to Jon and Marcelo's Twitter accounts as well as pattern pack itself, both the promotional page for pattern pack and in the GitHub account for pattern pack. Thank you guys so much again for your time today. Thanks, Jonathan. And thank you for listening to this last episode of Developer Tea for 2015. Join us again in 2016. We have a lot of awesome stuff planned. Make sure you subscribe and rate the show in iTunes if you're enjoying it that helps the show tremendously. Thank you so much for listening. And until next time, enjoy your tea.