Hey everyone and welcome to Developer Team. My name is Jonathan Cottrell and today I have the pleasure of speaking with Marcello Summers and John Gulley. Marcello and John created PatternPack. We talk on this episode about PatternPack, what it is, what it does, and how you may actually go about using PatternPack. And some of the difficulties that go along with introducing a pattern library into a project, whether that's a new project or an existing project. I'm really excited and we're going to jump right in. But first I want to thank today's sponsor. Today's episode is sponsored by OneMonth.com. OneMonth helps you learn all the skills you need to start a business, grow a product. We will talk more about what OneMonth has to offer specifically to Developer Team listeners. Later on in today's episode. But first I want to get straight into the interview with Marcello and John. Marcello and John, welcome to the show. Thanks, Jonathan. How are you? Doing very well. It is the middle of a Wednesday, so I'm right in the middle of my work week. But I am incredibly excited to talk to you guys about PatternPack and about pattern libraries in general. Because honestly, I want to bring these into my daily work. So I need your information. And I think a lot of people who are listening to this episode are going to be really thankful that I had you guys on. Because the stuff that you're talking about is incredibly practical stuff. It's going to be super useful. So let's go ahead and start out by having you guys introduce yourselves. We've already heard Marcello's voice and we're going to hear John's voice next, I suppose. So why don't you two introduce yourselves and kind of explain what your positions are and where you work. Yeah, thanks a lot, Jonathan. My name is John Gulley and I am a solution principal here at Slalom Consulting in Dallas with a focus on our mobility practice. I have a long time developer background with a real passion for user experience. So pattern libraries are really something that's a good blend of those two and something I'm really excited to talk about today. Yeah, and my name is Marcello Summers and I am a solution architect in our user experience practice. So I kind of come from more of the. That design background and with a flavor of development as well. I kind of lead some of our front end development efforts, you know, more of like our CSS and architecture. And really when you're trying to build like the interface of how things look. And Slalom is basically a national consulting firm. I think we're actually international now and we've got offices all around. We kind of try to serve clients in the local markets, but kind of started out in Seattle. We both work here in the Dallas office and serve clients here in Dallas and work with some like mid. Mid midsize to large companies just basically solving their their application development needs and helping them solve their problems through software. Awesome. Yeah, so that that's that is interesting because I think a lot of people who are listening work in some scale of a similar place, right? So whiteboard where I work is a consulting agency as well. We call ourselves a firm, but but ultimately we're all doing. Some. Something similar to consulting work. What is a typical project look for you guys look like for you guys in terms of workflow and you know how it flows throughout the agency? Yeah, we do a variety of different type of projects. But if we're talking about an application development project, it's usually a small team. We prefer agile as our delivery methodology and we'll come on to a client help understand what the problem they have to solve through the software. And it may include helping them with their organization, improving their processes for software delivery as well as an actual technical solution. So that could be a mobile application or enterprise application that they have behind the scenes, helping them get that launched and maybe filling some gaps they have in their own development capabilities. Are you guys primarily web web based applications or do you do other deliveries? Yeah, I'm. So we do other deliveries as well. There's a whole business arm of Salon as well. However, Marcelo and I both sit on what they're now calling our digital side of the business. But we do everything from native apps for mobile devices to web applications and even services or projects around continuous delivery and those type of things as well. But Marcelo and I primarily focus on. On web applications and and pattern pack really fits in that space. So you mentioned pattern pattern pack and that's going to be a big part of today's episode. Could you guys give me kind of the elevator pitch, the basic overview of what pattern pack does? Maybe I'll even take a step back and you know, you mentioned pattern libraries. Let's let's maybe set a baseline of what we're talking about today. Right. A pattern libraries as we define it. Right. Because a lot of people throw around these terms. It's. Basically. This idea of a living style guide within your application. It's it's this idea that, you know, it used to be that a branding agency might come in and drop off this PDF, you know, with your with your company of all these brand assets and logos and colors and maybe some interface design ideas. But something like that was essentially dead on arrival. Right. Because it didn't fit the mold of the realities of building web applications. So there's been this trend over the last several years of building these living style guides. And it's basically this idea of instead of going in and designing pages for an application, you're more designing a system that can be reused across one or multiple applications and extended in the future. Right. So that when you have this baseline design system, you know, you've you've encompassed how people are going to use it and they can use those parts in the right way. So I have the table styles that somebody can use. I have the reusable accordion styles. And I have all that code documented for somebody to get to. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. on building that design system that can be reused. Yeah, Bootstrap's a great example of a design system that a lot of people are familiar with. And our tool, PatternPack, is really designed to help you build your own version of that so that your application doesn't have to look like Bootstrap. It could look something different. And it can meet the specialized needs that your problem that you're trying to solve has or that your company has. Yeah, and PatternPack really does three things well. The first thing is the idea is that you can actually use it to build your design system, right? So it's a set of HTML tools and CSS, SAS and LUS generators and everything that you can actually build basically your UI code. And when I say UI, I'm thinking HTML and CSS. It allows you to document that, right? So it's a static site generator that'll actually build your documentation pages. And then really what I love the most about it and what I thought was most magical when John showed me the very, very early alphas, the very first time, is that it allows you to distribute that code easily as an NPM or a Bower package. So that, and that's really a big focus for us, right? It's that real implementation of once you build the design system, being able to go about using it. But PatternPack is really built around that core idea of versioning and releasing your pattern library. Yeah, I think that's an important distinction here because a lot of us probably are familiar with something like Bootstrap. Whether that's Foundation or Bootstrap or something different. But the idea being, there's these fundamental elements that are beyond the basic actual elements in a browser that we need to be able to use in many different scenarios, right? Whether that is a button or something more complex. And now typically these Bootstraps or something similar to Bootstrap, they cover the baseline that you... you would likely use in a given 10 projects. However, what they don't tend to cover is the way that those things work together with the exception of maybe a few elements, like for example, a nav, right? But typically they don't talk about, you know, how does this button work with these other things? And I think that the powerful piece of a pattern library is that you're not only talking about a button, you're not only talking about a button, you're not only talking about the individual element, but also how the element works with other elements together. Is that an accurate description of, could I do that with a pattern pack? Let's start there. Yeah, so one of the... So let me take a step back. We actually started building... We didn't start off... We didn't set out to build a tool, right? We actually set out to build a better way for designers and developers to collaborate together, right? We saw this need where, you know, a lot of times, designers who are maybe only Photoshop or sketch designers would just throw something over the fence and then developers would be stuck implementing it and then you get into that typical developer cycle of nudging everything one pixel. And the reason why I bring that up is one of the original guiding principles of this project was Brad Frost's atomic design, right? And if any listeners aren't familiar with that, it's this idea that your interface is composed of atomic elements. So maybe you have these atoms that are iconic, and fonts and header styles and a table and things like that. And then I can combine like a label, an input field and a button to be a form, right? And so then that becomes a molecule. And so you can build up your atomic design system, basically stacking them on top of each other, which is exactly what you were talking about, right? Bootstrap does a great job of giving you a whole bunch of atoms that you can reuse. Or maybe, you know, they'll compose a few of them in different ways. But you're right in that the realities of implementing this in an organization you don't always want, from a design perspective at least, you don't always want to just leave that up to the development team to have to figure out how to compose those, right? You want to think through the defaults and make it easier on the developers, honestly. That's what we found. Like the fewer options that you give to developers, the easier that it is for them to go about implementing it because you're telling them how exactly to use it. So we basically, we set out to basically figure out how can designers and developers use a concept like atomic design to better collaborate and then went down this path of exploring the tools that were out there, didn't find anything that really fit our needs. And then that was why we ended up building and then open sourcing our tool, PatternPack. That's great. Yeah, I think the biggest problem that I face as a developer when I start, you know, trying to use something like Bootstrap is that because we don't, as a company, for Bootstrap for a given project, we don't have the rules, right? The standards. We don't have the style guide for that given project. It's very easy to stack a bunch of things that shouldn't be together to stack them together, right? It's the same concept as giving a construction team just a bunch of raw materials and saying, build something, but you don't really have a plan for how to build that thing. Sure, they had the right raw materials, but if you don't explain to that construction team or if they don't have the, the, the built-in knowledge, if they haven't been educated to understand, you know, foundations, for example, if they don't have that knowledge, then it's possible that they're going to create something that first of all is structurally not very sound, right? And so to use that metaphor in design, you know, imagine a nav that just has a bunch of Bootstrap's primary buttons strung together at the top of the nav. That's awful, right? We would never want to see that, but it's possible. And that's the problem. Is if you don't have a guide that explains, you know, don't do everything that is possible. Everything is possible is not necessarily a good idea. I want to take a quick break to talk about today's sponsor, one month.com. If you have an idea for a product or an app, but you've been waiting to build it because you don't have the skills, the practical skills to build it, then one month is built exactly for you. One month is the first ever online school specifically for tech entrepreneurs. Now, this isn't about getting a degree. It's about applied learning. You don't have to waste a bunch of time in a classroom. Instead, you take these courses from your home and takes 15 minutes a day. You learn things like programming for non-programmers. For those of you who are thinking about becoming developers, that would be a good course for you. A growth hacking, iOS development, HTML and CSS content marketing, Ruby on rails, Python, jQuery, tons of other great courses on one month.com. Now, normally, if you were to go to one month.com, you'd have to pay full price. But of course, because you are a developer T listener, one month has a special offer for you. One month.com slash developer T will get you 25% off your first month at one month.com. You would take an entire course for 25% off. So as a one month student, you'll get immediate access to the exclusive community of budding tech entrepreneurs. Just like you, you'll be able to talk to those people, learn from them, community, and learn from them. And you'll be able to learn from them. And you'll be able to learn from them. And you'll be able to learn from them. And perhaps the most important piece of this is that if you get stuck along the way, there will be somebody at one month who will help you out while you are building and growing your product, a real person rather than an emailing machine. So go and check it out. One month.com slash developer T. Of course, that link will be in the show notes. Thank you again to one month.com for supporting developer T throughout 2015 and for providing such a great deal for developer T. Listeners one month.com slash developer T. I've been talking with Marcello Summers and John Goley about pattern pack. And the last thing that I mentioned before the sponsor break is that not everything that is possible is necessarily a good idea. And the last thing that I mentioned before the sponsor break is that not everything that is possible is necessarily a good idea. Yeah, that's a great point, Jonathan. Just because it's possible doesn't mean that it's what we would like our application and our user experience to be. And I think there's really two sides to this, right? There's exactly what you touched on, which is the idea of we've given developers the raw tools. Now let's just have them build the user interface for application, which is often results in something that may look shiny, but doesn't work or looks a little bit funny. The other side of that equation is designers who go and design something looks really beautiful, but, uh, and they even go and get the product owner or the stakeholder to sign off on it. And these guys are really excited about this beautiful looking thing. Uh, and they don't really bring the tech team into it. And then when it comes time to actually build this application, it's not possible, right? So our, one of our primary motivations, and we've seen both of those problems at different projects we've, uh, we've been at or at clients that are struggling with these same problems. That was one of our primary motivations for this whole activity was how do we bring designers? How do we bring developers? Closer together so that when we're envisioning this new application and this new beautiful thing that everybody's so excited about, we can actually deliver on that. Yeah. And we, I talked about this with cap Watkins. Actually, uh, he talked about this concept of throwing the thing over the wall, right? Uh, if, if you have a team of developers and a team of designers and the designers are basically building something, you know, for a set period of time and they never talked to a developer, and all of a sudden they say, okay, well it's done, it looks great and now we just need to ship it off to the factory essentially. Right? And they throw it over the wall to the developers and the developers take one look at it and they say, there's no system, there's no structure here. I'm going to have to build every single thing different from every other single thing. And then they throw it back over the wall at the designers and everybody ends up frustrated, right? It's, it's not a symbiotic relationship at all. It's quite the opposite of, uh, of collaboration. The things that we know are good for these systems to be able to bring together the repeatability that a developer can naturally understands and the usability that a designer should naturally understand. Uh, those two things can find a, a coexistence and that's what this tool is intended to do. Correct? Yeah, absolutely. And, and what's interesting about that is much of our design process, because of the way this tool was built, has actually moved to prototyping and real code, right? Because it becomes so easy for me as a designer. I mean, as a designer, I, I will often still go to Photoshop or sketch to bang out a new idea just because it's easier to move things around, change colors for me, right? There's, there are designers that work in code really well, but the idea is to get to code as quickly as possible. So we've actually had projects now where pattern pack lives at this center where what branches out from there, we actually have a prototyping project that, that pulls from the CSS code in, in pattern pack while the main application also pulls from that prototype or pulls from that shared CSS code in pattern pack. Um, and so our design process, eventually once we have a mature design system, um, we're actually wrapping up, uh, with a client right now we've been working with for almost two and a half years now. The design system at that point was so mature that we just went straight from sketches to code, right? Whenever we had a new idea, whenever somebody wanted to, build something new, we would just go straight to the whiteboard, sketch out some ideas, and we could immediately prototype that in code because it was basically assembling those Lego bricks that were already built out in the design system. All that does is it makes life easier for the developers in the long run, right? There was, there was a rumor on the project going around that, you know, we, uh, the, the client then was going to start wire framing in, you know, actual or these, you know, other, other static wire framing tools. And the developers actually freaked out and, you know, we're all raising their hand and saying, Hey, we want this, these prototypes to continue to exist because it speeds up our development process. Right. And that's for John and I, I mean, we live in a consulting world where we have to justify why we're putting these line items on a statement of work, right? Where if you just put, Hey, we're going to build you a pattern library, the client may say, Hey, let's pull that out. That's, that's out of scope. That's too expensive. I don't want to pay for that. But for us, we've actually taken the sales approach of saying this is an accelerator for our development team. And we're going to build a pattern library. And we're going to build a pattern library. And we're going to build a pattern library. That maybe there's a little bit of legwork up front to get it up and running. But when you're doing a six month year long multi-year, you know, a lot of times we'll do these big multi-year engagements. All it does is make the development process easier. Right. And I'm saying this as a designer. So John, do you, what's your perspective on that? I personally think that's the case, but I've also heard it from people who've worked on these products or these projects. It makes it easier because developers can wrap their mind around what these different pieces are. You alluded to this, earlier, Jonathan, when you said, you know, they think about these different modules or components and how they can be assembled together and reused. That's naturally how a developer wants to kind of write their code is for reuse. So I don't have to write it again and again. And so because of this promotes that kind of thinking and that kind of code, our developers have really taken to it. And like Marcelo said, are coming back and asking for it. So we've, we found that as a very encouraging, sign that we may be onto something here that we can, we can use longterm and may have some legs, right. That we really want to work that into a lot of our different projects. You know, as, as a developer, it helps to have a repeatable process that I use in every situation, right? So, you know, you have a, who is an IDO. I believe they have a repeated design process, regardless of what the problem is. They have a way of approaching problems. Developers work well. And I think really in general, not just developers, but everyone works well. Uh, if they have processes that they can refine, regardless of what the input is to that process, because we learn how to do things better every time we iterate, right. And, and having these tools, they make a lot of the decisions for us that we otherwise had to, you know, induce a lot of cognitive load in order to make before. And really those decisions end up not really adding a lot of value to the project. So, um, let's imagine that you have, you know, five different widgets on a given, on a given page, or, you know, maybe one of those is a nav and maybe one is, uh, a carousel or, or whatever. There's no reason for you to approach a nav or a carousel drastically different more than once in a given project, right? Let's, let's just, let's throw that out as a valid statement that there's not, not a good reason. Uh, usually at least to rewrite a carousel that you've already written, especially in a single project. Now replace carousel with anything that is repeatable. There's not a good reason to induce the, the cost for something that you've already completed. And that's exactly what patterns are made to reduce. Instead of, uh, going through the process, of redesigning and recoding, why would you have multiple sliders or multiple whatever's in a project? Why would you rewrite those? Well, a lot of the time, the reason people rewrite these things is because they didn't have a documented set of ways of doing that thing. And this is most often incurred, uh, for, you know, page two of the design, right? We've done the homepage. Now we're going to do the about page and we start all the way from scratch. And this, this is a really expensive process to actually, you know, go back and start with a blank page with no classes, create a brand new CSS file for that page. That's crazy. And hopefully, hopefully people know that by now, right? Yeah, you would hope so. Uh, unfortunately that's one of the primary drivers, uh, that led us to this, right? We're okay with things being different. Honestly, if you need a different button, there's a purpose for it. Uh, that's completely fine or we're not okay with is, um, divergence because you are unaware or because it was unintended to be that way. You just didn't know that there was another way to do it. So we want things to follow the same pattern. If there's a pattern in place, we're not saying don't add a new pattern if there's a purpose for it. Um, but just be aware of the patterns that are there and follow those so that you don't end up in this unintentional, why recreated everything from scratch. Well, in situation, and take a step back from a UI component and, and think bigger picture, right? One of our guiding principles around pattern libraries in general was we don't just want to do this once. We want to be able to do this on many clients and spin up teams that aren't just John and I doing this across multiple clients, right? We wanted to make this scalable and reusable. And that's, that is for sure. One of the guiding principles of pattern pack itself, right? Because being in a consulting environment, there's, there's a ton of smart people, there's a ton of people out there talking about building pattern libraries who are writing about it, who build it once, right? And that's amazing because we get some great depth on, you know, what happens a year or two after you implement one of these. But for us, we had constraints around, you know, we would have Mac and windows developers. We're building on unknown platforms, right? It could be just like a Java app. It could be an angular app. It could be a react app. It could be anything. And so we had to build something that was truly platform agnostic, with pattern pack, not just pattern pack, but like the process that we wanted to take to be able to reuse it. And the reason why I say that is, you know, if many of your listeners are, are in a consulting environment, something that we're out here trying to beat this drum is you can do this in a consulting environment, right? You don't have to be working for a product company or directly at that company to be able to spin up one of these. Um, it's more just about how you frame it up to your clients and then having a way to do that consistently where you're not reinventing the wheel each time we are not starting up a static site from scratch, each time. I think that is kind of the fundamental piece of this is that as we go forward in our, in our practice, we should be able to build up resources over time so that, you know, the next project that I do benefits from the last project that I did, right? There's, there's no reason why I should solve some of the same fundamental pieces of code. Why not just reuse some of those things, right? And having documents, uh, documentation is what makes that possible. And that's exactly what a pattern library provides. You know, I want to make it very clear by the way that neither slalom nor pattern pack is sponsoring the show. Um, w what we're talking about here is a practice of documenting your patterns and, uh, in doing so in a way that is, uh, is alive, right? It doesn't, it's not solidified at a moment in time, but instead it is a living document that can change over time. As is necessary. Uh, for example, a really important piece of this is that as you learn how to use different patterns in combination with other patterns that you write documentation around those combinations, right? Um, as you, as you see the need for, you know, new platforms to support the system, maybe you have a further platform documentation to explain how that particular platform, uh, integrates with this particular thing. There's many different ways to do that. There's a lot of different ways to do that. There's a lot of different ways that you can go about solving this problem. Um, but I think what you said just a few minutes ago, John, that's the, the ultimate, uh, the ultimate goal, which is awareness, right? Uh, we don't want to write code accidentally. We never want to write code that is either a duplicate or is kind of a shadow of another piece of code. If you have, let's say, you know, 30 font size declarations in your project and many of them are not duplicates, then a pattern library is probably a good idea for you to adopt. That, that happens all the time. Uh, duplicate code, very simple things like that, that can be, uh, cleaned up. You can write code more intentionally. And this really acts like a testing ground, right? Uh, to be able to compare your page to these patterns and say, okay, this is how this page is constructed. Fundamentally, we're taking these three or four, different pieces from the pattern library and we're constructing it in such a way that makes sense for the objective of this particular page or of this particular area of the site or application. Uh, there's so many ways that this can apply, but the most important piece of that is awareness, awareness of the code, awareness of what's available to you. Um, particularly if you're a web developer, awareness of how to go about constructing a site that is cohesive, not an individual, many, many sites that make up one site just because they're all on the same domain. That's not a website. That's a bunch of code that is on a domain, a well executed website. And you guys can chime in on this, a well executed website or a well executed code base. It makes use of reuse. Yeah, absolutely. One thing I did want to touch on Jonathan was, uh, when you brought up documentation, that's often a kind of a scary word for people to hear. Oh, well, that's just another thing. For me to do. We don't have time for this. You know, that's a lot of extra work, but it is a great communication and collaboration tool, right? So one of the things that we're trying to accomplish here is to lower the bar for that documentation, to make that as simple as possible, to make the process of writing that documentation unobtrusive. So it's not this big burden for you. And then by writing the documentation, uh, it not only will create the pattern, but it will also create the pattern library where you can see the patterns and use that to talk with your designers, talk with your stakeholders, make sure there's a clear understanding of how an application would work. But then the code that is generated from that, the styles that are used for the documentation are actually used in the application so that you're not then starting with great. We've got this wonderful documentation that shows us exactly how to do it. Let's go recode it all for our application. That's one of the key differences between what I've seen in a lot of the different, pattern libraries, uh, pattern libraries and design systems that are out there is that they're great. They help, um, define what the patterns are. But then when it comes time to implementation in an application, um, the developers are basically replicating what's in the design system. The pattern pack tool will actually package the CSS that you generate in the documentation or in the, in the pattern library and make that available as a dependency. So you can actually use that as a dependency to your application in the project itself. So this opens up the ability to know that the code that you're using to communicate with your, with your stakeholders is the code that's going to actually be on the final application. And you can take that a step further. I know we use this at because we're consultants to go from client to client. But if you're just working at a company where you aren't doing this, um, by having that CSS code packaged up in a reusable unit, you could, then use it on one application and then a new project comes along. You can use that same design system and all those patterns in a new application just by specifying it as a dependency of your application. And what this allows companies to do is kind of is define a design system that fits their brand. All of their applications should look and feel the same. That's great for user experience because repetition makes something and consistency makes a product more usable. So if you're using three different apps and they all look and feel the same, it makes them more usable. And with a design pattern library like this in place where you're actually sharing the code amongst those three applications, you can achieve that goal a lot more quickly and with a lot more success in keeping everything the same. Yeah, I, I 100% agree with, with the idea that, uh, it is super useful. It would be super useful to have the code that I see. That is creating the documentation be literally not just, uh, connected, but literally the same code that is loaded into the application that that seems like a huge win to me. Yeah, and and I'll say for me as a designer who's more development minded, it's even become addicting to go into sketch, you know, create a new component or something that we truly need for a page right in the middle of a new project. Um, and and instead of coding that, instead of having to go into like the production, application that I swear, you know, I haven't pulled the latest code in two weeks and it won't even build and you know, it just doesn't work for me. I have to go update 10 things to get it working. I can just go right into my pattern library and have this example and just like build it isolated from the rest of the application and just build it on its own and make sure that it works right. That makes it a lot that just makes it infinitely easier than having to worry about the whole context and part of that is also us trying to push for this best practice. Of people thinking about building their user interface and components, right? Like that additional little level of friction of building the component my library first and then going and implementing it in the production application really is just pushing a team to better practices, you know, just in the same way that something like a code review does right? There's a little bit more friction in a code review and going through a pull request process, but you end up with a better system in the end. Thank you for listening to developer tea today. The first one, the first part of my interview with Marcello summers and John Gully. Of course, there will be a second part to this interview in the next episode of developer tea. I hope you will join me for that episode to make sure you don't miss out on that episode. Go ahead and subscribe and whatever podcasting app you use that way. Every episode of developer tea will be automatically delivered straight to your device. So you want to subscribe in whatever podcasting app you use. Thank you to today's sponsor one month.com. If you are a tech entrepreneur and you're looking for a learning resource, go to one month.com slash developer tea. You'll get 25% off your first month. Thank you again to one month for sponsoring developer tea throughout 2015. If you have not already joined the spec slack community, you are missing out on a fantastic group of people who are interested in the same things you are interested in. Go to spec. FM slash slack. I am there and so are the hosts of the other shows on spec. Go to spec.fm.com. And of course, you will be able to ask questions of other developers. It's a great community. Go and check it out. Spec. FM slash slack. Of course, all the show notes for this episode and every other episode of developer tea can be found at spec. FM and until next time, enjoy your tea.