Hey, everyone, and welcome to Developer Tea. My name is Jonathan Cottrell. And in today's episode, we continue the interview with Marcella Summers and John Gulley. 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 Tea possible this year. Not only our 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 Tea has 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 the link in the description below. 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 Marcello Summers and John Gulley. And 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... I don't know if you use PatternPack 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 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... 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. And when you were talking about that, something that popped into my mind is we built PatternPack to solve a specific need that we have that we've open-sourced and some other people have caught on to 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 pattern library. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. 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 weren't 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 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 in marketing that's going off doing their own brand ideas and designing marketing pages separate from the application if the entire organization is meant to be working on this single design system, right? This is an organizational problem. Then it is a technology problem. Yeah, 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, you know, 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, you know, two or three. You're going to have two or three rogue people who are just against it, for whatever reason, they haven't bought in, 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, you know, 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 a 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 Medium 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... 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, right? 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, it's 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, and it's the other person, and it's the other person. And so it's a very different model. And I think that's the most important thing. Just saying, hey, here's this cool thing that I built. Then he goes into a model that's basically a centralized model, where a company 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 going to be 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. And all those people are going to bring a different context and a different flavor. And so what's important is to have those different voices. And 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'd highly recommend going and 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 John and I were doing, we would walk into a project midstream with a few months left, and we'd go and implement this pattern library. 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, 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 developers 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 developers 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 Marcella, 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 long-term projects is that we're not going to be able to run a whole bunch of these 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 planned? Maybe there's another two or three weeks worth of work that is continuing on, or maybe there's a whole nother application, you know, in this case, if 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 versioning. So, you can have a versioning 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 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? Semantic versioning is a great solution to that problem. That's actually what we promote for, Pattern Pack. 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 this same design system in a design tool, a Photoshop tool or an Aksher type tool, because they're not really handled as source code, they're not really handled as a design tool. So, if you have a design tool 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 makes them 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, you know, which is the idea of, you know, you're going to have to have major, minor, and patch releases, but defining for your design system what one of those releases mean. You know, so a patch release might just be true CSS bug fixes, but then if you're adding or deprecating components that you've built, you know, that's a minor release, where then major releases are true, like, rethinking of the design, you know, major breaking changes, don't upgrade to this unless you're ready to redesign. But again, that's going to change per client, right? We've had clients that have done this for a long time, and they'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 team's 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 developers 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 communications. Another huge benefit of the pattern library when it comes to versioning and releasing is testing, right? One of the worst issues in CSS is that idea of unintended changes, right? Two CSS properties walk into a bar, a bar stool 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 toying 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 just my pattern library. So, you know, I think that's a huge benefit of the pattern library. is wired up to a database that might be a little bit slower, right? That's something that could take five to ten 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 the fact that you're building your CSS with a lot of different things, and you're building your CSS with a lot of different things, and you're 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 interest. And so I think that's a huge benefit of the pattern library. 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 your design. And you can run them in a way 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's considered a unit test. Typically, those are the words for it. What we're talking about here with regression testing, a regression test makes sure that something that you've written is correct. And that's what we're talking about here. 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 look at the design element and see if it's correct. Put eyes on that particular design element to make sure it looks like it did before, right? 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, right? So re-rendering the old one and re-rendering the new one, and creating a new one. And so that's the hard part. And so that's the hard part. And so that's the hard part. And so that's the hard part. And so that's the hard part. And so that's the hard part. 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 Wraith and WebDriver. It's a very challenging space because browser development by itself is a very complex thing, right? If you think about it, there's not a ton of people that are low level. 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 in Git. And so that's a great way to do that. And so that's the hard part. 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 diffing 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 IE or Chrome or something, right? 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 a perfect circle. It's a little bit difficult for my eyes to tell the difference sometimes, right? 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, you know, a situation where a computer would be much better at telling the difference than a human would. 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, right? We can teach computers a lot of things. So 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 PatternPack make it an adoptable field, right? Make it available to the general public to start realizing that we need it. As developers, we need to be able to do that. And I think that's a big part of the reason why we need to be able to do that. And I think that's a big part of the reason why we need to be able to develop a tool that makes it a little bit easier to do. 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 John, I've really appreciated your time today. I'm going to ask you a few more questions that I like to ask all the guests who come on Developer Tea. Do it. 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 and 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 times, we do it because we're not going to be able to do it. And I think 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 and away from the computer are the areas in my life that's given 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 John, 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 developers, 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 um, there's many times when I find myself in a situation where I'm not really sure what I'm doing. I'm finding 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, um, there may be a different path to go down. Writing code, um, 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 do that. And I think that's a really good point. And I think that's a really good point. Um, but if you're trying to focus on that and not the code, it's probably the best thing I could encourage somebody to do. Yeah, that's, that's really good advice. I think, uh, 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, uh, it is not the hardest thing we do. Solving the problems that is much more difficult to do. And I think that's a really good point. And I think that's a really good point. I think that's a really good point. And I think that's a really good point. And I think that's a really good point. And I think that's a really good point. And I think that's a really good point. And much more in your head than, than the code is. Great answers. So, uh, 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. No, you've got some really good questions. You know, like these are the things that, uh, 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, uh, people to ask me more about, I often bridge the gap between developers and designers. Um, 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, um, especially if you're a designer, you're going to want to be more engaged in the design process. 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, um, clients often want to bring us in for the technical skill, right? 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, you know, clients would ask me, and this is so hard to say in a humble way, I guess, but, um, you know, oftentimes I, I wish we could have more input or have more influence around how organizations structure kind of this long-term maintenance of their pattern libraries and keeping these up and running. You know, we try to give input, but so often when we walk away, we can't, we don't know how that's going to keep running. Um, there's so many great practices out there, but if you're just trying to work with them, you're going to have to work with them. And so I think it's important to kind of wedge this into how you're doing things today. You know, oftentimes we're working with, um, organizations that need help, right? That's, that's part of being in consulting. Um, but if you're not going to take, if you're not going to, 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, um, it's going to die. It's going to, it's going to fall off and it's going to become irrelevant. So all of that investment's going to go away. That's great. Yeah. I, I, it's hard to say, I, you know, I wish that you would talk to me about how to do things better. Like that's, 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, you know, and that is, uh, you know, that's why things like pattern pack, we have to create those things to support, uh, 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, uh, 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? Um, we're, we're somebody, we're a company that always likes to be talking to people. 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 of days later, and there's people that we talked to and hire two years later. Um, so you can find, you can find slalom at slalom.com. We have offices in most of the major cities in the U S you know, New York, San Francisco, Seattle, et cetera. Um, outside of that, you can find pattern pack at pattern pack.org. Um, and from there, we have a lot of, we have links to get hub. We've got a Slack channel that you can join if you'd like support. And if you just want to find John and I individually, I'm Marcello Summers on Twitter. And I'm at John 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, uh, we really appreciate, uh, 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, uh, to John and Marcello's Twitter accounts, as well as pattern pack itself, uh, both the promotional page for pattern pack and, uh, in the get hub 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 T 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.