Hey everyone and welcome to Developer Tea my name is Jonathan Cutrell and today I have the pleasure of speaking with Marcelo Summers and Jon Golly. Marcelo and Jon created Pattern Pack we talk on this episode about pattern pack, what it is, what it does, and how you may actually go about using pattern pack 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 1month.com. One month helps you learn all the skills you need to start a business, grow a product. We will talk more about what 1 month has to offer specifically to Developer Tea listeners later on in today's episode. But first I want to get straight into the interview with Marcelo and Jon. Marcelo and Jon, 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 pattern pack 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 Marcelo's voice and we're going to hear Jon's voice next I suppose. Why don't you introduce yourselves and kind of explain what your positions are and where you work? Thanks a lot Jonathan, my name is Jon Gully and I am a solution principal here at Solom Consulting in Dallas with a focus on our mobility practice. 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, my name is Marcelo Summers and I am a solution architect in our user experience practice so I kind of come from more of that design background and with a flavor of development as well. I kind of lead some of our front and development efforts, more of like our CSS and architecture and really when you're trying to build like the interface of how things look. Solom 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 mid size to large companies just basically solving their application development needs and helping them solve their problems through software. Awesome. Yeah, so that is interesting because I think a lot of people who are listening work in some scale of a similar place. So whiteboard where I work is a consulting agency as well. We call ourselves a firm but ultimately we're all doing something similar to consulting work. What is a typical project look for you guys in terms of workflow and how it flows throughout the agency? Yeah, we do have 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? So we do other deliveries as well. There's a whole business arm of Salam as well. However, Marcel 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 Marcel and I primarily focus on web applications and Pat and Pack really fits in that space. So you mentioned Pat and 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 Pat and Pack does? Maybe I'll even take a step back and you mentioned pattern libraries. Let's maybe set a baseline of what we're talking about today. A pattern library is as we define it because a lot of people throw around these terms. It's basically this idea of a living style guide within your application. It's this idea that it used to be that a branding agency might come in and drop off this PDF 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, living design systems. 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 encompassed how people are going to use it and they can use those parts in the right way, right? 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 go in and copy and paste, right? It's this idea. I think it was Mark Otto and a couple other people Dave Rupert, I think, has also talked about it. This idea of basically building your own bootstrap within your organization. So maybe it uses bootstrap, maybe it doesn't, but you're really focused on building that design system that can be reused. Yeah, bootstrap is a great example of a design system that a lot of people are familiar with. And our tool pattern pack 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 pattern pack 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 like HTML tools and CSS, you know, SAS and less generators and everything that you can actually build what we 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 Jon showed me, you know, the very, very early alphas the very first time is that it allows you to distribute that code easily as an NPM or a Bauer package. So that's really a big focus for us, right? It's that it's that real implementation of once you build the design system, being able to go about using it. But pattern pack 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, you know, there's these fundamental elements that are, you know, beyond the basic actual elements and 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 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? I think that the powerful piece of a pattern library is that 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 the 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 set out to build a tool, right? We actually set out to build a better way for designers and Developer 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 icons 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 less, 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, Patent Pack. 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 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 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? 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, all right? We would never want to see that, but it's possible, and that's the problem. If you don't have a guide that explains, you know, don't do everything that is possible, everything that is possible is not necessarily a good idea. I want to take a quick break to talk about today's sponsor, onemonth.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. It 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. Growth-hacking, iOS development, HTML and CSS content marketing, Ruby on Rails, Python, jQuery, tons of other great courses on onemonth.com. Now normally, if you were to go to onemonth.com, you'd have to pay full price, but of course, because you are a Developer Tealistener, one month has a special offer for you, onemonth.com slash Developer Teawill get you 25% off your first month at onemonth.com. You would take an entire course for 25% off. 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 is such an important part when you're learning. 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 a growing your product, a real person rather than an emailing machine. So go and check it out onemonth.com slash Developer Tea. Of course, that link will be in the show notes. Thank you again to onemonth.com for supporting Developer Teathroughout 2015 and for providing such a great deal for Developer Tealisteners. Onemonth.com slash Developer Tea. I've been talking with Marcelo Summers and Jon Goli about Pattern Pack. 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. I think there's really two sides to this. There's exactly what you touched on, which is the idea of we've given Developer 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. They even go and get the product owner or the stakeholder to sign off on it. These guys are really excited about this beautiful looking thing and they don't really bring the tech team into it. When it comes time to actually build this application, it's not possible. One of our primary motivations, and we've seen both of those problems at different projects 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. I talked about this with Cap Watkins, actually. He talked about this concept of throwing the thing over the wall. If you have a team of developers and a team of designers and the designers are basically building something for a set period of time and they never talk to a developer and all of a sudden they say, okay, well, it's done. It looks great. Now we just need to ship it off to the factory, essentially. They throw it over the wall to the developers and the Developer 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. It's not a symbiotic relationship at all. It's quite the opposite of collaboration. The things that we know are good for these systems to be able to bring together the repeat ability that a developer naturally understands and the usability that a designer should naturally understand. Those two things can find a coexistence and that's what this tool is intended to do, correct? Yeah, absolutely. What's interesting about that is much of our design process because of the way this tool was built has actually moved to prototyping in real code because it becomes so easy for me as a designer. As a designer, 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. There are designers that work in code really well, but the idea is to get to code as quickly as possible. We've actually had projects now where PatternPack lives at this center where what branches out from there, we actually have a prototyping project that pulls from the CSS code in PatternPack while the main application also pulls from that CSS code in PatternPack. Our design process, eventually, once we have a mature design system, we're actually wrapping up 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. 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. There was a rumor on the project going around that the client then was going to start wire framing in actual or other static wire framing tools. The developers actually freaked out and we're all raising their hand and saying, hey, we want these prototypes to continue to exist because it speeds up our development process. For Jon and I, we live in a consulting world where we have to justify why we're putting these line items on a statement of work. 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 how to scope this to expensive and want to pay for that. For us, we've actually taken the sales approach of saying, this is an accelerator for our development teams that maybe there's a little bit of legwork up front to get it up and running. When you're doing a six-month-year-long multi-year, a lot of times we'll do these big multi-year engagements. All it does is make the development process easier. I'm saying this as a designer. Jon, what's your perspective on that? I personally think that's the case, but I've also heard it from people who have 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 they think about these different modules or components and how they can be assembled together and reused. It's naturally how a developer wants to write their code is for reuse, so I don't have to write it again and again. Because this promotes that kind of thinking and that kind of code, our developers have really taken to it. Like Marcelo said, are coming back and asking for it. We found that as a very encouraging sign that we may be on to something here that we can use long-term and maybe have some legs that we really want to work that into a lot of our different projects. As a developer, it helps to have a repeatable process that I use in every situation. You have 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. There's work well, and I think really in general, not just developers, but everyone works well 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. Having these tools, they make a lot of the decisions for us that we otherwise had to 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. Let's imagine that you have five different widgets on a given page, or maybe one of those is a nav, or maybe one is a carousel, or whatever. There's no reason for you to approach a nav or a carousel drastically different more than once in a given project. Let's just throw that out as a valid statement. There's not a good reason, 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 cost for something that you've already completed. That's exactly what patterns are made to reduce. Instead of going through the process of redesigning and recoding, why would you have multiple sliders or multiple whatever 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 for page two of the design. We've done the home page. Now we're going to do the about page, and we start all the way from scratch. This is a really expensive process to actually go back and start with a blank page with no classes, create a brand new CSS file for that page. That's crazy. Hopefully, hopefully people know that by now. You would hope so. Unfortunately, that's one of the primary drivers that led us to this. We're okay with things being different, honestly. If you need a different button, there's a purpose for it. That's completely fine. We're not okay with is divergence because you are unaware or because it was unintended to be that way. We didn't know that there was another way to do it. 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, but just be aware of the patterns that are there and follow those so that you don't end up in this unintentional why we created everything from scratch. Well, in an- Injuration. Take a step back from a UI component and think bigger picture. 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 Jon and I doing this across multiple clients. We wanted to make this scalable and reusable. That is for sure one of the guiding principles of pattern pack itself because being in a consulting environment, there's a ton of smart people out there talking about building pattern libraries who or writing about it, who build it once. That's amazing because we get some great depth on what happens a year or two after you implement one of these. For us, we had constraints around we would have Mac and Windows developers. We're building on unknown platforms. It could be just like a Java app. It could be an Angular app. It could be a React app. It could be anything. We had to build something that was truly platform agnostic with pattern pack, not just pattern pack, but the process that we wanted to take to be able to reuse it. The reason why I say that is if many of your listeners 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. 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. 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 practice, we should be able to build up resources over time so that the next project that I do benefits from the last project that I did. There's no reason why I should solve some of the same fundamental pieces of code. Why not just reuse some of those things? Having documentation is what makes that possible. That's exactly what a pattern library provides. I want to make it very clear, by the way, that neither Solom nor Pattern Pack is sponsoring the show. What we're talking about here is a practice of documenting your patterns and doing so in a way that is alive. 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. 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. As you see the need for new platforms to support the system, maybe you have further platform documentation to explain how that particular platform integrates with this particular thing. There's many different ways that you can go about solving this problem. I think what you said just a few minutes ago, Jon, that's the ultimate goal, which is awareness. 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, 30 font size declarations in your project and many of them are duplicates, then a pattern library is probably a good idea for you to adopt. That happens all the time. Duplicate code, very simple things like that that can be cleaned up. You can write code more intentionally. This really acts like a testing ground, right? 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. 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, particularly if you're a web developer, awareness of how to go about constructing a site that is cohesive, not individual 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 that makes use of reuse. Yeah, absolutely. One thing I did want to touch on Jonathan was when you brought up documentation, that's often a kind of a scary word for people to hear, oh, that's just another thing for me to do. We don't have time for this. 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, it not only will 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 recoded all for our application. That's one of the key differences between what I've seen in a lot of the different pattern library and design systems that are out there is that they're great. They help define what the patterns are, but then when it comes time to implementation and application, 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 pattern library and make that available 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 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 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, 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 100% agree with the idea that it is super useful. It would be super useful to have the code that I see that is creating the documentation and be literally not just connected but literally the same code that is loaded into the application. That seems like a huge win to me. Yeah, and I'll say for me as a designer who's more development minded, it's even become addicting to go into sketch, create a new component or something that we truly need for a page right in the middle of a new project. And instead of coding that, instead of having to go into like the production application that I swear, I haven't pulled the latest code in two weeks and it won't even build. And 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 your user interface in components. Right, like that additional little level of friction of building the component in 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 part of my interview with Marcelo Summers and Jon Goli. 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 Teawill 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 dot com. If you are a tech entrepreneur and you're looking for a learning resource, go to one month dot com slash Developer Tea. You'll get 25% off your first month. Thank you again to one month for sponsoring Developer Teathroughout 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. 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 Teacan be found at spec.fm. And until next time, enjoy your tea.