#137: Design concepts and tips for developers Transcript

00:00 Michael Kennedy: Design has become a critical element in software. Back in the '90s, it was fine to produce and sell battleship gray apps that worked but did not do much to delight. Today, design is table stakes, and knowing how to design applications yourself or work with designers is a key skill. This episode, you'll meet James Stone who straddles that gap between developers and designers. He's both. He has a bunch of tips for improving your design skills as well as working with designers. This is Talk Python to Me, Episode 137, recorded October 30th, 2017. Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter where I'm @mkennedy. Keep up with the show and listen to past episodes at talkpython.fm, and follow the show on Twitter via @talkpython. This is episode is brought to you by Linode and GoCD. Be sure to check out what they're offering during their segments. It really helps support the show. Hey, James. Welcome to Talk Python.

01:13 James Stone: Hey, Michael. Thanks for having me.

01:15 Michael Kennedy: Yeah, it's great to have you here. I'm super excited to talk about design, web design, and general application design because this is originally something I found super challenging and daunting for me, and then once I really learned it properly, I felt like, "Wow, I have this whole wide world that's been unlocked." Now I have this power that a lot of people are afraid of, which I think makes it even better, the stuff you can do, so hopefully we can share that with everyone, and a lot of your tips from your experience.

01:40 James Stone: Nice.

01:41 Michael Kennedy: Yeah, absolutely. Before we get into those topics though, let's start with your story. How did you get into programming in Python?

01:47 James Stone: I have a funny story. I'll talk about really quickly how I learned to program. I'm the product of a clinical microbiologist and an RV salesman. My mom, the scientist, was taking me to laboratories, had me looking through microscopes, and she bought me an Atari 600XL back in the '80s, and taught me to program in Basic. I have no idea why she did this, and she never programmed again ever since then, but it kind of turned into a career. And so, I always had a fascination with programming and computers. It was kind of a hobby. I got into hacking computers, got kicked out of high school, or you might say like in air quotes, like ask nicely to leave, you just can't stay here kind of thing.

02:31 Michael Kennedy: Oh okay. What was the reason for that?

02:34 James Stone: It was maybe an ends to a means but I lived in a small island in Washington, and this is the beginning of the internet, so it was long distance to Seattle to connect to bulletin boards, which is what I was doing when I was younger. There was a library system there, so I started hacking their system. I figured out a way to break out into Telnet, and start accessing interesting shell servers over in Seattle, circumventing the long distance thing. I basically kept doing the same thing in high school, and had a knack for finding maybe exploits or ways to break software, use it in a way that it's not supposed. I think at the end, they had me on my own computer that was disconnected from the network, so I kind of roll this cart into the library with my programming books, and I would be like programming out in the middle of a library, if you can imagine. And then of course, we got caught again, my friends and I, and so, they're like, "This is enough. You're out of here." And so, I went to college through a thing called Running Start program.

03:30 Michael Kennedy: That's really interesting. I feel like a lot of times, structured education misses opportunities to take people that are like super creative, and find like. You know, these rules, they don't actually have to exist, like whatever, right? And like turn that into. They probably could have redirected your energy into something that's super powerful but instead, they just said, "We're going to unplug you."

03:52 James Stone: Yeah. Yeah, I think I'm kind of a product of that system, not really having a good avenue for those interests or pursuits, so they were scared.

04:03 Michael Kennedy: Yeah, sure, of course. And it was all bizarre. Nobody knew really what to do with the internet anyway. And that idea of the way you got on the internet was to find something you try to access or one of these dial-up things that then fail then dropped to a Telnet. I've heard that from many other people. I've experienced this as well. It was interesting. Awesome. Okay. So that was high school. And you were going to start to learn programming.

04:25 James Stone: Yes, I had kind of a start in programming in high school. They had like a Pascal class, so I was super fired up about that. I was doing some C and some things but I wouldn't call myself a professional programmer. I certainly had a lot of interests. What happened is a friend of mine helped me get a job in 1990s at a startup where I learned to begin like a professional programmer on the job. And so, basically they threw at me the Java 1.2 or Java Two Bible, which was pretty thick in those days, and they said, "Ah get to it," and I think it's a few weeks later, I was writing production code, and in charge of data classes, so I started mostly doing backend programming in Java back in the '90s.

05:03 Michael Kennedy: Yeah, nice. And that was the heyday of Java. Sun was super big, powerful corporation. Java was a big revolution, right? It was, like, so much better than C at the time, for example, and things like that, yeah?

05:14 James Stone: Yeah. So much more portable. Bytecode was going to be the future of everything.

05:18 Michael Kennedy: You just wrote it once--

05:19 James Stone: Yeah. Yeah, it's so funny to think back about those days. Fast forward, I've always been involved with programming computers. I went back to school 'cause I dropped out of college eventually. I went back to college. I actually studied art, and then found a way to combine computer science and art after having a short career as a professional programmer. And so, I'm coming from it from a little bit different angle, the lead into Python is I've always been interested in Python, and recently, my wife started doing astrophysics work, and she did a master's, and now she is working on astronomy PhD. And so, she taught herself to code in Python for scientific purposes in about a month with some books. And so, it's very interesting for me 'cause she never did knew any programming at all. And so, now I guess maybe 'cause I have some affinity towards Python, I try to focus my projects into that. So when I have to do an API or something, Flask is my tool at hand. When I have to crunch some numbers or things, I find myself reaching for Python in those time.

06:25 Michael Kennedy: Ah that's a really interesting story. Python has taken over astrophysics.

06:28 James Stone: I think so. I mean, I'm not that far in it, but from my observation, it's either that, or the old-school people, they're like, "No, it's Fortran." Pretty hardcore, yeah.

06:41 Michael Kennedy: That's right. That's definitely a giant chasm between those two languages in terms of time and space. But yeah, like a lot of the APIs were controlling a lot of the major new telescopes that are going up are done in, basically the APIs for them are Python, and a lot of the machine learning stuff to discover a lot of the stuff in the, the visual stuff is Python. So yeah, it's really interesting to see that she taught herself that to get going in there. Cool. I think it's a lot of you've been, what got you to where you are today but now what do you do day-to-day?

07:12 James Stone: What I do day-to-day now, I've got a little bit of a split line but for most of what I do, I work as an independent design systems engineering consultant. And so, some of the things I'm working on there, I write daily emails to kind of a secret list the I have, record videos and tutorials sometimes. I'm researching new tools and processes. Sometimes I'm giving talks and webinars. And so, some of those, again, might be to this kind of secret inner circle list. I just gave a talk recently here in Turku where I'm at in Finland. And I work a lot with design and development teams, and often, it might even just one designer or two designers and development teams helping them to work on their web projects. On the other side of what I do, I teach. I'm an assistant teaching professor at Penn State, and I teach an online course, which I'll put in quotes, but creative code is what we focus on, and it's teaching artists and designers how to program in Processing, which is a simplified API for Java.

08:12 Michael Kennedy: Okay, cool. The creative code part is basically simplified coding for creative types.

08:18 James Stone: Yes. So if you've ever programmed in Java, you might have had to deal with its very heavy API, and so, you end up with all this boilerplate to do very simple things, not simple things but do like 3D OpenGL animation, and having things rendered quickly like kind of a game buffer. And so, Processing does this all for free, and you just use very simple calls like rect or ellipse, and then you can do those in two dimensions or three dimensions very easily.

08:44 Michael Kennedy: That's really cool. So the first thing that I want to talk to you about, and it's our proper topic is this concept that I opened with, which is web design as a superpower because I really honestly don't know what the breakdown of my audience is, and how many folks out there say, "Yeah, I feel totally comfortable as designing the stuff that I work on, or even interacting with designers on the stuff that I work on," right? Maybe people are infrastructure folks, and design is basically a colored terminal. Maybe they work on web apps. Maybe they work on other kinds of apps. But I feel like there is a lot of stuff in design that feels really scary and daunting. People feel like, "Oh I'm not an artist." You kind of came from the programming side, and then you studied art, and then you came back. Maybe talk to us about that journey a little bit, and where it got you to.

09:31 James Stone: Yeah. It's very interesting. And I can understand that apprehension a little bit from if you're an engineer, and you've never done really any art, or you feel you're creative in certain ways but maybe design and art are maybe not your forte, or you never had experience. It can certainly be daunting 'cause there's a whole another language, and sometimes the way people are realizing things, it seems difficult to get your head around what that is. But I'm a firm believer that creativity is something that everyone has, and also that art and design and I can get in music is something that can be taught, or you might have perhaps an aptitude for it. But I don't think that in general, people are born an artistic design genius, and that's it. They may have an aptitude where people have, given the right kind of tools and resources to that person as they're developing but I've seen all sorts of people, especially when I work at Penn State, I actually teach a lot of computer scientists and software engineers. They take my course because they want to do something creative, they want to do something visual. And so, that might be a little bit of a struggle coming in but it's something that can be taught, it's something that can be learned, it's something that's accessible. Just like you've learned to program, right? You have these little pieces to build upon each other. It's the same thing in design, and I think it's just a little bit different perhaps in the approach. It's more of a bottom-up approach than the top-down that we're maybe perhaps used to but don't let design scare you if you have some interest or interest in art.

11:09 Michael Kennedy: I totally agree with that. How do you think people should get started? They can't, short of like, "I'm going to just go back to school and do graphic design too." How is somebody who maybe like works on the web but that doesn't really do the UI stuff other than just like get it in place and pass it off, what are a couple of steps people could take to really get better at that?

11:29 James Stone: Yeah. To get better at design, I think there's a couple of things. One is if you start to recognize the patterns of design like if you've worked with a designer and they say, "Hey, this is not quite right. It should be this," maybe asking the question why like why is that not right, and so, there is just like how we have variables and functions and all these types of--

11:52 Michael Kennedy: Why can't I put it all in one function? It's only 3,000 lines.

11:55 James Stone: Exactly. In design, there is these principles of alignment, so often, design elements will be aligned with each other, so the baseline of the font will often line up. So you don't want them off by a pixel or 10 pixels. And so, you see this alignment principle, right? And you'll see balance and contrast. There's a lot of other principles, and so, you could pick one of these, or you could pick up a book that talks a little about it, and just try and recognize what those are as you're working, and then what I do, and I think maybe this is because I have a lot of experience with code, often I think about visual ideas in terms of code, especially when it relates to web, so I jump very quickly from a sketch, for example, to just building it out in code. Sometimes I skip that whole using a visual design application.

12:42 Michael Kennedy: Right. Okay, yeah. So you do your initial work with pen and paper, or with a stylus type thing?

12:47 James Stone: Yeah. In the past, it's been pen and paper with Sharpies and Copic markers. And lately, it's been on like an iPad Pro, and part of that, for me, I recently moved abroad, and so, it's very heavy to carry a lot of paper, and those types of supplies. I did bring my Copic pens and a Sharpie, which I don't think they actually have in Europe. They have another type of pen that they use that I have to find, but yeah, it's just whatever I have available, but the iPad Pro is quite good for sketching, I think.

13:14 Michael Kennedy: Yeah, that's cool. I have an iPad Pro with an Apple Pencil like the 12 point whatever inch one. Actually part of this getting better at design experience I went through was I got some drawing apps, and I decided I'm going to force myself how to learn to draw in this thing even though drawing was something I thought I was very bad at. And with a lot of practice, you can do it. It's a pretty nice experience.

13:37 James Stone: Yeah, no. I totally agree, and I think the experience in the iPad Pro is quite good with the Apple Pencil. I actually studied for a time traditional animation and illustration, so I have a lot of experience with this kind of hardcore Florentine style drafting the human figure, working very quickly. And you know, I would say maybe I drew good at the community college but when I got into this, when I've tried to get into this ranked program at San Jose State, those guys are hardcore. I remember they said, "This guy draws like Michelangelo." I think if you're thinking, "Oh I can never be an artist," like when I was drawing, and I thought I was quite good, and then here I'm like next to Michelangelo. So there's always going to be someone better, right?

14:20 Michael Kennedy: It also depends on what you're trying to get out of it, right? Like are you trying to improve what you're doing versus are you trying to do animation, like you say, basically fully become a digital artist. So you also had a resource you wanted to reference about this design as a superpower concept.

14:38 James Stone: Yeah. So I haven't taken any of her classes but I have spoken with her, but her name is Laura Elizabeth, and she's got a website lauraelizabeth.co, and she's got some really fantastic articles focused towards developers, and especially maybe if you've had some exposure to frameworks, or you've done a little bit of web design, maybe not full-on UI design but maybe more on the backend, and you're, say, building out some smaller projects, personal projects, so you want them to look a little bit more designed, like more so than just, say, out-of-the-box Bootstrap. She's got some really great resources you can look at where she talks about color choices, alignment, basic principles of design but she explains them in a very developer-friendly format.

15:20 Michael Kennedy: Oh yeah. That sounds really cool. I'll definitely link to Laura's stuff. Let's go ahead and actually talk about front-end frameworks first because I feel like if you sat somebody down with like just open up a new file, and you say, "Okay, first thing you type is angle bracket HTML. You also get a CSS file. Design that. Build something beautiful." That's really super daunting for a lot of folks but I feel like in the last five years or so, the front-end frameworks have really democratized design, not in the super high level sense but like I can start from like a 70% good with these front-end frameworks. So maybe tell us about front-end frameworks and some of the ones that are great.

16:01 James Stone: Yeah. So my exposure with front-end frameworks happened in early days of responsive, and so, there is kind of Zurb Foundation version 2 kind of Bootstrap 2, simple stacking, and responsive, but I mean what they have done for the web is I think nothing short of amazing because if you find pretty much any website it was built before these existed because I think they have raised the bar in design for the stuff that's hand coded, it's like you look at websites, and you're like, "Wow, this is like from the 1990s or from like the early 2000s." There is like these two big gaps. You can like really spot it.

16:37 Michael Kennedy: If I had Y2K problem but it's not broken, it just looks, it looks like it.

16:42 James Stone: Exactly. I think one, they take these design patterns, they take these design trends, and they package them all up into an easier-to-use UI toolkit, like you can just, instead of having to figure out how to create a button every time because actually if you go like you're saying, right, and you're like HTML, and just start writing in some standard elements, it actually still looks a lot like 1995 or like the early Netscape if you don't actually spend the time to style it, and what the frameworks do is they provide you a lot of how to get that reset in a much more modern way automatically, and then what I think they're also good for is a learning tool. So CSS I think is not that complex as a language but there is a lot of complexity in like how you might use it to create visual effects, especially when a lot of the things that we've been doing in the past, even the past few years are kind of hacks like flip-based grids. And so, there is a lot of weird stuff that's not obvious. And so, it helps you to learn those patterns and how people are creating things because you can just view the source, and use the inspector, and learn how the components are being built.

17:57 Michael Kennedy: I think you're totally right on about that, and there is also some of the underlying things that you get that are just non-obvious. What you're touching on before about the subtle color changes, the topography, the line spacing, the reset CSS, so Firefox then look different than Safari, or whatever, right? There is just so many subtle little things that you can just take for granted rather than have to figure out how to do. And then it's down to using the widgets that what people probably mostly think of when they think of these frameworks.

18:27 James Stone: I think that's what a lot of people are thinking like these accordions and tabs, and it's kind of interactive, more sliders, and that kind of stuff, and that's certainly a part of it. But yeah, a lot of it can just be CSS only. So until you get into some sort of interaction, which on the web is requiring like when you click on something, you get some sort of reaction that's beyond the default of a button, which is a lot of things obviously but everything else is CSS only. And so, that's really the JavaScript it's just handling that interaction.

18:54 Michael Kennedy: There is a couple of really popular ones. There is Bootstrap. There is UIkit. There is Zurb Foundation. And you're actually pretty involved with Zurb, right?

19:02 James Stone: Yeah, I'm pretty involved with the Zurb Foundation. The secret, don't tell them, I actually got started on Bootstrap back in the day. But sometimes people start on Bootstrap, and they switch over. But they have a little bit different focus on their philosophy, and I think they're better suited to certain projects.

19:19 Michael Kennedy: Sure. My site is based on Bootstrap. I have done a lot of Bootstrap. Primarily, I've chosen Bootstrap because one, it was pretty early, and the other, there is a lot of themes for it, so I go grab stuff for it. But I'd love to hear your thoughts on the pros and cons of each, or like even just why's Zurb is awesome over Bootstrap, things like that, 'cause this is, a lot of time, you have to choose that right at the beginning, before you've even done a lot with it, and you're kind of like, "Well, I'm not redesigning it now. It's done."

19:47 James Stone: Sure. I would say the reasons that you talked about are actually some of the great reasons to use Bootstrap. Bootstrap is probably the most popular framework by a very large margin, and it's very developer-friendly. The reason is, is it looks really designed outside of the box, and also like you said, there is these themes that you can just plug in, so if you want a little bit different visual style, you can either get a free theme or purchase a theme, bolt that on, and there you go. It looks a certain kind of way. So it's very good if you're creating like I think an MVP, if you're creating like your version 1.0, you don't have designers on board, or maybe you have designers on board but you don't have the time to focus on like that much visual branding in the app. It's more about functionality, and it has to look okay enough, or personal projects, or you do hackathon. This is a perfect type of thing 'cause you can just use Bootstrap and build upon it. And then I think you can make some pretty moderate changes and restyle it but the themes are really probably the more powerful way that you can get closer to the visual style that you're looking for.

20:57 Michael Kennedy: Yeah, I totally agree. But how about Zurb? What's awesome about Zurb?

21:00 James Stone: If you liked how that sounded, Zurb Foundation might not be the right fit for you. I got into it. There's I think really two reasons people use the Zurb Foundation. One of 'em can just be an aesthetic like some people like this very minimal aesthetic of like the Zurb Foundation unstyled kind of look, and there is certainly some people that are doing that, but the most important thing, and what it was actually designed for is for strong visual brands, and so, it's actually not intended to be used that way out of the box. In fact, if you're using it that way, this is probably what Zurb would call like a layout or a wireframe that's done in code. And so, what's intended is you use the framework like a wireframe, and actually you have to create a whole set of design on top of it. So it doesn't have like these subtle shadows and gradients. It's expected that you're going to add all of that afterwards based on a professional design. So you take like a mock and translate it to this framework.

21:57 Michael Kennedy: Right. So it provides the foundational building blocks and the typography and all those things I was talking about but instead of going, and it's basically done using a button. Maybe is it more of a framework for designers to go continue to build with than it is for developers to drop in and keep doing their web stuff?

22:13 James Stone: Yes. I think it's much more a framework for designers because the emphasis is on design. So if you're coming from, say, your app or your marketing site, and you have fully realized radically different than Bootstrap visuals for all the pages, and this is like how you're starting your process, and then you're trying to convert that. Zurb Foundation is going to be a better framework for you whether you're a designer or a developer working on a team like that.

22:41 Michael Kennedy: Okay, cool. And are there some themes out there that you can go grab that people built like landing pages, or is it really you're starting from the framework?

22:48 James Stone: I know there has been some discussion on themes for Foundation. Don't quote me but I think there are some themes but I've never used them because my experience has been building out these websites that have like a strong visual brand to it.

23:04 Michael Kennedy: This portion of Talk Python to Me is brought to you by Linode. Are you looking for bulletproof hosting that's fast, simple, and incredibly affordable? Look past that bookstore, and check out Linode at talkpython.fm/linode, L-I-N-O-D-E. Plans start at just $5 a month for a dedicated server with a gig of RAM. They have 10 data centers across the globe, so no matter where you are, there is a data center near you. Whether you want to run your Python web app, host a private Git server, or a file server, you get native SSDs on all machines, a newly upgraded 200-gigabit network, and 24/7 friendly support even on holidays, and a seven-day money-back guarantee. Want a dedicated server for free for the next four months? Use the coupon code PYTHON17 at talkpython.fm/linode. So maybe tell us some real examples that you've worked on with Zurb.

23:53 James Stone: Yeah, so I've done some work for agencies upon tracking, so I can't really talk about the particulars of that but one of the websites that I work with, and I think it's got a pretty strong visual brand as well. It's called Snowflake Stories LLC. It's a very interesting solopreneur, self-funded startup, and what they do is they create children's stories that are completely customizable where there is a cast of characters resemble your family. And so, we create this character builder that's kind of based loosely on the Wii, I can't remember what it's called, the Wii Mii. You know, we got the character. We've had it customized. And so, this is something that we created there, and what's nice is it's also mobile responsive, and we're using Angular and this kind of thing in the background but the styling of it is very visually distinctive. So I think that in this case, Zurb Foundation was a really good fit for it. And it's also an interesting project, and I think this is one of the benefits of working with Foundation too because I did a lot of what you might call UX design, solving the experience and what that was like. And then later on, we actually brought in a visual designer, a UI designer Marcus Handa. We came together, and then we actually won a award called the IPPY Award for one of the best publisher websites for that year. I think it's International Publisher of the Year.

25:17 Michael Kennedy: Yeah, that's a really nice idea as well, like have a book with your child as the character in it. My daughter would go crazy for that. That's cool. The site looks nice. I'll link to it in the show notes. So maybe that's a good place to segue over to talk about interactions a little bit. In this case, there was person who owns the company, created the books, and have the idea, and then they wanted to work with you. I expect they're probably not a developer, or they would have put something less nice together or whatever but maybe let's focus it on like how developers should interact with designers. I supposed sometimes people see this as like a frustrated thing, like you know, I built the site, and it totally worked but the designer said it's off by three pixels, and it was the wrong color. What can people do to maybe make these really great interactions, and where people are supporting each other?

26:09 James Stone: Yeah. It's a great question. And I worked on a team recently where I came back to them, and I told them actually that they had 147 or something like these wrong colors, and then I went through and fixed them and got it down to about seven or eight. So yeah. And I can relate to that too. I think I'm in a unique position maybe to talk a little bit about this 'cause what I've been doing over the past few years is working with designers and dev teams, and kind of a little bit being the go-between, and helping them to translate these ideas, and communicate by. I think the biggest thing is to realize that as engineers, we have a really different agenda and a different focus than probably the designers. And so, one is to kind of understand better what the designers are going for, and maybe understanding a little bit what they mean when they say things like they have empathy for the user or what good user experiences. I think these are actually great things to tie into but maybe the loss in translation because I know that a lot of engineers include myself really care about the performance of the website. And I'm very focused on the front-end. So I really want that front-end to really pop. I want it to be fast. Not too many connections, really smooth, really quick. And so, we're actually working towards the same thing. I want the user experience to be good as well. But sometimes it can get lost in translation, right? And so, I think where that goes astray is you mentioned the wrong color or off by three pixels but I think what I've seen that can be a bigger problem is when there is a little bit of a detail in the design where you really need to let the design team know early on, or the stakeholder in the project that it's going to be expensive, right? Sometimes there is a little flourish, right? And that flourish is going to be like 10 times the time of some other task that you've got on this task list. And so, I've actually been working with some designers lately, and when that's brought up, they're like, "No no, cut that. It's not important." So getting to like what's important 'cause sometimes I think what happens is that designers feel like they have to fight for their ideas, and so, they have all these sketches and ideations, and then they're showing all these different versions, right? And so, when you're finally interacting with them, you might be at this final version that they've had to fight tooth and nail, right? They really want that flourish or whatever, and so, they're fighting for it but not necessarily because they're fighting you but just they've had to put a lot of energy into getting the design pushed forward. So I think if you can get involved in the design process earlier on, and bring these things up like if there is some, I'll put it in air quotes. Crazy thing that you're freaking out, like, "How am I going to even do this?" in our system, or is it going to be cross-browser?

28:58 Michael Kennedy: They know it's HTML, right? They know it's HTML. It's not print, come on. I wanted always to be exactly the size. It's not even 8.5 x 11, come on.

29:07 James Stone: Yeah, exactly.

29:08 Michael Kennedy: Something like this, yeah.

29:07 James Stone: Yeah, exactly. And so, I think when you gain more experience with it, with this translation, you can kind of spot things right off. And so, I know for myself, I know if I'm working with Photoshop-based work, I can tell them already, like, "Look, the fonts are going to be the wrong weights. So, it's not going to look as bold or as light as you think it's going to. I think sketch-based digital assets are working a little bit better. But there's still some translation there. So you can kind of start to have that conversation earlier. And I think it's good. It doesn't mean you're going to hang out while they're sketching all the time. But just maybe to inject the engineering thought process a little bit earlier on, so that it doesn't ruin your day, like a week or two weeks from then.

29:48 Michael Kennedy: Yeah, it seems to me like the design team probably spends a lot of time in boardroom meetings, where there's the CEO, or the major stakeholders, who have super lofty ideals about what they want built. And then they ask the designers to build it, and then the builders, the designers eventually get down to the developers, and say, "Developers, this is what we've chosen." Maybe having some sympathy for the pressure that is on the other side of that story for the designers. And then, you maybe try to, from a design perspective, try to get at least one representative for the dev team into those meetings so they're more involved earlier.

30:26 James Stone: Yeah, I think so. And I think it can really help. Especially if you're kind of in an environment where you're really siloed off, or the designers who are over there or over here, and we see them in the hallways, but we're not interacting as much. Or, some places have places where it's much closer. Maybe you're sitting next to each other. But I think, what can really help, is like you're saying, have someone who can kind of, span the gap. And it could come from either team. It could be a designer, maybe who's doing some code or has some aptitude. But, getting someone who can kind of understand the visual nature of the front end code, and kind of take that on, so that. Most teams that I have worked with have very specialized roles, and I wouldn't say the bulk of the team is doing front end work. It's usually one person or, you have maybe in a very large organization, a team of people doing this type of work. Or in some cases, for myself, as a consultant, there's often been a gap. And so that's where I've kind of injected myself in the process. 'Cause they have the designer, they've got the back end team and they don't know how to--

31:24 Michael Kennedy: They're bringing you in to be the bridge.

31:26 James Stone: Pretty much. And so, I think that's the, something that can be really quite useful. And just to get involved more in the process earlier on. From both sides, too. Designers, should get involved. Not telling you the nitty gritty of what you're doing, but at least letting you know what's coming down the pipe or "This is what we're thinking. What do you guys think? It's going to take forever. Is it feasible?"

31:47 Michael Kennedy: Right. "How much do you want this? Are you willing to wait a month longer to have this?" So, you were touching on a couple things here that I think are interesting. And one is, this workflow with the design team and the dev team. The projects where it's worked a lot better for me, as being a team member on the dev side mostly, has been where the designers and the developers work more closely together. Maybe they share a GitHub repo. And the design, sometimes at least, is done in the CSS, and in the app. Where it's worked less well is where I've worked with people, largely from a print background, where they're like, "Oh we're not going to touch the HTML and CSS. "We don't do that. What we'll do is we'll just give you this picture, and you can just make this picture." And I found that to be a lot less helpful, and like, "Well, I can have a picture of it." What I need is to actually make the HTML look like the picture. That's where it's super, super hard, right? Because that's where the rubber meets the road. And so, it's one thing to draw a picture and say, "I want this." It's another to say, "And here's how you get there." What do you think about that? There's tension, right? Not every designer is a web developer, for example. But, what do you think?

32:57 James Stone: Yeah, I think it's, maybe, in a lot of cases, unfair to just tell designers, "Look. We need you to code. Or we need the code." However, there's some more modern thoughts. And this might not be news to some designers or people in some circles, but there's some more modern ways of working on the web. One of them is this tool called "Sketch", and it's not because it's an amazing drawing tool, although some people think that. But it's because it renders very close to what the browser's going to render. And if you are a designer and you understand how the web is built, and you understand how the grid system is going to be displaced, and you understand, maybe, a little bit about the box model, then you can create these beautiful designs that are very easy to hand off. And there's tools for that as well. There's a tool called "Zeplin.io". There's another one that I like lately, called "Simplee", which is spelled in a very silly way and I can't remember, so I won't quote it. Maybe that'll be in the show notes. And there's another one called "Avacode", like "avocado", but with "code" in it. In what these are, I like to call them automatic redlining tools. And so what you can do, is you can load up that Sketch file, the designer can do it, share it with the team. And you can just click on things, and it gives you measurements between stops. So, for me, when I'm building stuff on the front end, and I'm building out the CSS, I need to click on an object and I need to know how far it is between the edges of the button, how far is it between the other objects, so I can add padding, spacing, and all this kind of stuff. I need to know the exact colors. And so they allow you to lockdown the colors and name them. And so hopefully you're not naming them like, "purple haze" or some crazy name, but it allows you, actually, as a designer, to be a little bit more programmatic and think in systems, which I think most engineers actually appreciate if you're given a set of colors as variables that imply the user explained the use. So this can be injected much earlier on. You can use a tool like this for measurements. Makes the front end code easier for whoever ends up doing that. Maybe it's the designer, but maybe it's someone on the dev team. It just depends on who does it.

34:59 Michael Kennedy: Yeah. I really like the idea, especially of working within the constraints of the CSS box model and stuff. And the grid system. Because, I feel like, that's where it gets really hard. It's like, "I want it to go like this." Then you move it, it goes like this. "Should I put". That's so hard in HTML. So you kind of, you're working with the same clay. Not steel versus mud or whatever.

35:21 James Stone: And it's getting better, I think, with Flexbox and CSS grid, in terms of grid systems. Some of this is getting a little bit better and less hacked. But, some things that I've done--

35:30 Michael Kennedy: You don't see that many tables as front pages anymore.

35:33 James Stone: Yeah. Yeah. I'm building all my websites, all with tables. They're all like, this cutup Photoshop from the '90s, yeah. Or 2000s.

35:43 Michael Kennedy: This portion of Talk Python To Me was brought to you by GoCD. GoCD is an on-premise, open source, continuous delivery tool to help you get better visibility into, and in control of, your team's deployments. With GoCD's comprehensive pipeline modeling, you can model complex workflows for multiple teams with ease. And GoCD's value stream map lets you track changes from commit to deploy at a glance. Say goodbye to deployment panic and hello to consistent, predictable deliveries. We all know that continuous integration is super important to the code quality of your applications. Choose the open source, local CI server, GoCD. Learn more at talkpython.fm/gocd. That's talkpython.fm/gocd.

36:27 James Stone: I think when you're coming at this, you have to think about what's going to be the most fluid process, like how can you help the people on the other side? If you're a designer and you care about the design, you want to hand this off in a way that's going to kind of carry over the design intent. Clearly, we both, you were joking, I gave you the image, like "Just build it". It's so hard. And what I see a lot of, from designers, hopefully there's no designers listening in. But they send me these beautifully rendered high fidelity mocks, which look just like the regular website, and maybe they're even in Sketch, so I'm like, "Awesome, I can use one of these tools and build it out even faster, rather than having to try and estimate measurements or get it close by eyeballing or taking measurements myself." Then they didn't do anything for the mobile, or tablet, or maybe even tablet, but so I'm placed in the position, and I obviously have some design background, and maybe this happened to you. Where it's like you have to invent the whole mobile experience, and if they don't have a lot of experience with responsive and how things are going to displace or stack on mobile, or the box model, then it might be kind of a disaster. You might have to rethink patterns on mobile. And it might be quite difficult. And so, and I don't know why, but they just skip that whole part. It's kind of like the modern day version, I think, of just handing off the image, just like, "oh". The mobile, yeah, you just like put a hamburger or menu on that.

37:50 Michael Kennedy: Exactly. You're using the Foundation, right? So you'll be fine.

37:52 James Stone: Exactly. Yeah we're using Foundation.

37:54 Michael Kennedy: It's responsive. It says responsive. It says responsive right there in the design. Yeah I've had people say, "This website is not responsive. I thought you were using Bootstrap." You have to employ the features of the thing, then add the responsiveness to it. It's not just pixie dust you sprinkle on it, right?

38:11 James Stone: Yeah. There's some patterns that are challenging too, like mega menus, and that kind of thing. How does that work on mobile? It depends, right? Depends on what kind of crazy menu you've thought up in the first place.

38:23 Michael Kennedy: Yeah. Yeah, for sure. Smaller, minimalist. That's what I say. One thing that you brought up is having named colors and things like that. Do you recommend that the dev team use something like Sass or Less or one of these sort of more programmatic CSS super languages? I don't know what you really call them. I'm making that up.

38:43 James Stone: Yeah, I think that's a really good move. Especially, I think, in two instances. One is where you're in a team environment, where multiple people will be working with the CSS and making modifications to it. And the other reason why is when the project gets large for maintainability. I think Sass does a couple of things. So, it is programmatic.

39:02 Michael Kennedy: Sorry, before we get too far in, hey. Maybe not everyone knows Less and Sass. You want to just define that real quick for them?

39:06 James Stone: Yeah, sure. So, if you don't know Less and Sass, or there's post-CSS as well. But, they're CSS pre-processors, and so, what it allows you to do is use things like variables, functions. Also allows you to create mix-ins, which are also kind of like functions that return CSS code. Code in quotes. They also allow you to split up your code across multiple files. And so, you can create something that's much more programmatic. But I think the most important thing isn't that it's programmatic. Sure, you could start generating tentless in this kind of stuff with colors. But I think what's more interesting about it is the organizational aspect of it. I don't know about you, but I've worked on projects where you come on, and you go, "Okay." And maybe it's multiple CSS files. But it's usually one CSS file, and you open this up, and you're like "What?" You're like, it's like maybe being created by five people. Things are named like, "something something" like "number 2-3". And you're going through this, trying to make sense of it. And it's difficult.

40:07 Michael Kennedy: We have a five thousand line CSS file. And one of them, and why, yeah exactly. Why is this okay?

40:14 James Stone: Yeah, so, I think that's a disaster. 'Cause how are you going to maintain that? That's like opening up a single five thousand line Python program that's not in any sort of order. Like, what are you going to do with that?

40:26 Michael Kennedy: Well, yeah, I, you know, what I think is even worse, although I totally agree with the analogy, is a lot of times that file was started as, like a zero byte CSS file was added to and added to, as the site or the app has gone through many prototypes and many phases, and features were added in, then canceled. But they're just, they're all still in the CSS. It's like the tree rings of growth of the app. And you don't want to take it out, because you're like, "Well what if, what if that one part that is "in this obscure page was depending on that thing?" And it's just really hard to know that you can clean up this dead CSS code equivalent.

41:02 James Stone: Yeah. They do have a good tool for that now, called UnCSS. It's the equivalent of, if you've ever had your room be a disaster, which I know, growing up, mine was a disaster. My parents were always yelling at me, "Clean your room." And then if you took everything in the room, and shoved it in the closet, I think it's the equivalent of that. But it basically looks at your website and what CSS selectors are being used, and it basically dumps the rest. But it's still just a mess. It's just, it's still all in the file. It just doesn't render out to the website. So it's a good solution, but--

41:33 Michael Kennedy: That's cool. How does it work with potentially dynamic stuff like Chameleon or Jinja2 templates? How does it work with say, something behind a login versus public, you know what I mean? You're like, "Oh there's that admin page." That thing maybe isn't, does it address any of that stuff?

41:52 James Stone: There are ways to configure it to address these types of things, but just like, as you're sweeping things into the closet. Like, for me, I don't think it's a very elegant solution. And so then you're like, "Okay. How can I program this stuff to sweep more stuff into the, be the new things that are coming into the room or something?" I think this is where the organization helps, because you can kind of keep things paired down. And, I've found, when you keep things organized, just like in your room, if you had a clean room, it's like, perhaps you get older and you're more clean or organized, you can find things very quickly, right? You're like, "Where is this thing?" And so, when you go in and inspect it in Chrome, because you have a map, it'll tell you, "It's in this file, on this line." It's very obvious. And not only that, but if you name these files correctly and create a good sense of structure, then they're already named with the views or the names of the components, or this type of thing. So it should be super obvious what's going on.

42:46 Michael Kennedy: Yeah, that's cool. A lot of times I'll try to have a navigation CSS file. Maybe like a store CSS, a homepage, 'cause homepage, like the landing page always seems to have a bunch of insane styles that don't reappear elsewhere on the site. So yeah, I definitely think organization's important.

43:03 James Stone: Organization, I think, is important. And then the programmatic nature of it, what it does, is it allows you to maintain design consistency. And so, as you might move towards a larger app, or towards something where the visual design is more important, it's really key. Like if you're using, like I'm working on a project right now, where one of the brand colors is red. So, it's red in the logo. And so, we use this branded red everywhere. But, it's maybe not obvious to you if you don't have a design background if you're using the wrong red. So, just like I said, I went through hundreds and hundreds of variations of those reds to kind of clean it up and you know, you find this pound, like Foo, F-0-0. It's kind of red, and it's like, "That's not the right red." And so, and the other thing that's really nice with Sass, or Less, but I think a lot of people don't realize, is you can create code linters to kind of prevent this type of behavior, this accumulation of things. So, you can kind of create good practices and instill them in a coding conventions document. But also have them enforced or at least warned when they're running the pre-processor.

44:04 Michael Kennedy: Oh wow, you can even bring that into a continuous integration workflow?

44:07 James Stone: Yeah. And you could either warn people or kick them out, so that they won't render the CSS.

44:12 Michael Kennedy: Actually fail the build. And it's crazy to fail the build because the CSS is using the wrong color. I think that's awesome. Didn't know that was an option 'til just now.

44:20 James Stone: Sure.

44:20 Michael Kennedy: So maybe that's a good place to touch on a few final things around methodologies, like, one of the things you talked about is designers, developers, working together, using outdated methodologies. It'd make it harder for them to do work together. They have to do a lot of rework. Want to give us some thoughts on that?

44:37 James Stone: I've been doing stuff on the web for quite some time. And I think the old school way is, like you said, like the designers huddle and come up with some crazy design and kick it over the fence. And then you're, I know I've been panicked. I remember I used to work at Pulse Magazine. It was a magazine put out by Tower Records, if you can remember back then when they were still around.

44:56 Michael Kennedy: Like music, when it came out on a physical thing, you carried it around?

44:58 James Stone: Yeah. It was all on CDs and this kind of thing. And so, I worked at a music magazine and I remember the creative director came up with this design. And this is back in the days of tables. And he had this thing that would overhang like a flourish that would overhang the rest of everything else underneath it. And I said, "This is going to be so difficult to make." And I kept, this whole kind of argument. And he didn't buy it at the time. But this is the thing, like kicking it over the fence and developers, you're going to have to struggle and make it work. Or else. Or this kind of argument that goes on. So if you've been in that position, it kind of sucks. But there's newer ways of working, I think, than just kicking it over the fence and then developers just trying to build it, by some sort of weird ways. And part of that is, one, there's this idea of design systems, and this is kind of a big area. But, there's kind of two parts of a design system that I think could be really useful for anyone who's approaching a large project, a redesign, some sort of major changes to, not like you're building the app day-to-day, but you're going, maybe you hire an agency or something like that, and it's like a radical redesign. And so, those two things that I think you can really gain, which could become a great part of a design system, is creating front end code in isolation. So you talked about building it kind of integrated into the back end, and so then making sure you can kind of make tweaks on the color and all that stuff. And then you can see it live. I'm actually advocating a little bit the opposite. But only in the case of redesign. But to create the layouts and the patterns in a simplified form. So you can, kind of, share with the other developers what they look like, and they can see it.

46:35 Michael Kennedy: Are you suggesting they create that in HTML and CSS? Or that they create that as a Photoshop type of graphic? Put a little structure on that.

46:43 James Stone: I'll be quite specific. I wouldn't advocate just using like static HTML and CSS. And so, what I would say I am an advocate of, is if you're going to build front end code, starting from a framework, if you haven't already, because, why reinvent the wheel? Why do all that cross browser testing? Like, grab Bootstrap, grab Foundation if it's more appropriate, and use that. And then, with these projects, especially with Zurb Foundation, there's all this front end tooling that comes with it. And so, Zurb Foundation comes with this really interesting thing called "the Zurb Template". And what it is, is it's a bunch of tooling that Zurb used to use internally, that they open sourced. It's an agency. Now what they do is very interesting, 'cause they build different websites for different people. So, last time I heard, they produced something like a hundred per year, which is kind of crazy, I think. That's like one every three days. Like a new website coming out. And one of the things that they do, is they produce front end code for these clients. They don't just produce, like you're saying, the, "Here's the image. Build it." And so, it's very interesting. So this is what they do as an agency and they're working across a lot of different industries with a lot of variation in the visual design, the visual branding. And so, they've actually created their own internal toolkit to help them with that problem. And so, that's what this is. And it's basically a static site generator, similar to Assemble with some helpers that are specific for front end prototyping, that make the process really quick. So when you need to repeat things, like you have a bunch of images, and you're like, "I need 25 images.", you just repeat it. 25. So you don't have the pattern repeated a whole bunch of times in the HTML. It has partials, which are great. Because if you're building it with the intention of handing it off to a team, for example, like a Django team or whatever, you can understand what kind of partials are they going to use on the back end? You can build it in the same way the front end codes so it'll resemble that when you're looking at it. And then it also has this tooling for the Sass build, which has autoprefixer. And it could have UnCSS and other things. But you can build things really quick, live reload them in the browser and it's super fast. And so, this is how I build front end code. But the other part of it, it's also got a thing called Style Sherpa, which'll help you to build a living style guide. Which is basically this set of documentation. So if you've used Bootstrap. If you're not familiar, go check out the Boostrap website. Their documentation, it's fantastic. Check out Zurb Foundation. Look at their documents there, like, how do you use it? This is what Style Sherpa does. You just put, basically, a code snippet in a specialized markdown format with code fences and you call it "HTML example" instead of using just HTML, and what it does, it walks, it'll go and render out the live code in the browser, and then have a copy and pastable version right below it. And so you get this scene kind of, automatically built style guide that you would get from Zurb Foundation paired down a little bit. But specific to your project.

49:31 Michael Kennedy: I think this is a great set of really concrete things that developers and any designers who happen to might be listening to this episode as well, can take and use. So it feels like we've come a long way in the last 10 years, starting with these, sort of, front end frameworks. But also, in the developmental world, we kind of moved, I'd say around the year 2000, all this agile stuff that was going on, and whatnot then. And that maybe brought some other challenges with it. But it was quite a big shift and it feels like the design world is also finding really new, interesting ways to work together with the developers.

50:07 James Stone: Yeah. Absolutely.

50:08 Michael Kennedy: Yeah. Awesome. Alright, well, I guess we'll, we're getting low on time. So we should probably leave it there for the design stuff. But, let's go to the two questions. So, if you're going to write some code, either Python or maybe HTML, what editor do you open up?

50:23 James Stone: I always open up Sublime Text 3. I'm a huge Sublime Text fanboy. I've been using it since version 2, which I guess doesn't sound that long ago, but they have a very long version cycle. But,

50:35 Michael Kennedy: They do.

50:36 James Stone: Yeah. And I used to work with them and some other editors. And I just, something about it, it just, I feel like I don't even have to think. Like I can just work really quickly.

50:45 Michael Kennedy: As far as notable packages or libraries? What do you think?

50:49 James Stone: I would say the number one package that I use, and it's super old school. It used to be called Zen Coding, but now it's called Emmet, which I don't know that's a great name. But basically, it does two things. One, what you do is you can type in a shorthand syntax, which is going to be very similar to, for example, like Ruby Slim or Haml where you have a CSS selector. And you're just, kind of, combining them together like a UL. And then you've got the LI. And then you can multiply. And so you can build these structures really quickly in HTML.

51:18 Michael Kennedy: Let me give a concrete example for people who are listening if they haven't seen this, 'cause it's really awesome. So imagine you want to create a unordered list of 10 items. And you are an aesthetic editor. You could type, <ULclose<LIclose and hopefully your editor at least closing those tags for you. And then you could copy and paste it. Or you could just say, UL<LIstar10Tab and it goes "boom" and it just expands them all out, right?

51:45 James Stone: Exactly. And it's like, I think the first time when you do something that's complex, and you see the speed of it, you're like, "Wow. This is like magic." And I think the thing that it also prevents, is messing up on not closing the tags, or using the wrong closing tag, or these little mistakes. And I think, when you're using these frameworks, you start to have pretty large structures like this. Especially like the unordered list with all the the line items and all this kind of stuff. And so, it makes those structures really easy to build quickly, and then also error-free usually.

52:16 Michael Kennedy: Right, like grid rows for example. Or something like that. And you can mix in CSS. So you could say, like if you wanted the unordered list to be products, and the items to be product as CSS classes, you could say, like UL.products<LI.productstar10 and Tab and it would put all those classes on the elements as well, right?

52:39 James Stone: One thing, maybe, I'm not sure if it's because I do design, or because I do code, but I really like, there's a Lorem tag you can throw in there too and it just fills it with Lorem text. But it's even better than that, because it's programmatic, 'cause you can say Lorem10. It gives you 10 words of Lorem. But you can say like Lorem1, but you know how you're saying you can use the asterisks to multiply out. So what you can do, it'll actually give you different Lorem text for each of those items. So if you're building a menu, it's fantastic.

53:09 Michael Kennedy: That's awesome. There, that's like the Lorem Ipsum, sort of, meaningless text to just fill in stuff that, those stakeholders, they'll look at it and go, "Whoa but it's not supposed to say that." Get that out later, it's not what it's going to be there. This is just filler. So like, Lorem Ipsum is that thing. Do you know about hipster lor, hipsum, hipster, Hipsum?

53:25 James Stone: Hipser, Hipsum, no. No. What is that?

53:28 Michael Kennedy: It's hipsum.co. It's the same thing as Lorem Ipsum but it's hipster speak.

53:33 James Stone: That sounds fantastic.

53:34 Michael Kennedy: It's fantastic, man. It's beautiful. Here, maybe I'll read you a little if I can just pull it up here. Let's just do it. It says, "Shabby chic aesthetic subway tile pabst fogetto dream catcher narwhal" This just goes on and on. It's beautiful. I've been starting to move towards the hipster Ipsum lately.

53:53 James Stone: Nice. Maybe we should fork Emmet and integrate the hipster Ipsum in there.

53:58 Michael Kennedy: We definitely, definitely should. Alright, well, I definitely recommend that as a editor plugin as well. That's cool. So, a final call to action before we call it a episode?

54:08 James Stone: Yeah, cool. So if you've been listening, and you're interested in what I've been talking about, this, kind of, intersection between design and engineering, the best thing I have for you is, I've got a list. But it's kind of a secret list. You won't find it advertised on my website. But what I do have is, I have a free email course, where, what I do, like these two big wins I talked about using the front end code. And so, if that sounded compelling to you, or creating the coded style guide, you can learn how to do that at designsystemscrashcourse.com. But more importantly, after you're done with the course, you'll get on this, kind of, internal insider's circle list that I've got, and I send emails out daily and I talk about this stuff all the time. Like, how to use Grunt and Gulp and how to build code, how to work with Sass, like how to make sure colors are consistent. And so, if you've got that, kind of, design twinkle in your eye, or in the back of your head, it might be something you might want to check out. designsystemscrashcourse.com But, I also have something else, because I know this is a Python show, and I wouldn't want to leave empty-handed. I did a lot of searching on Zurb Foundation and Python, and I thought, "Wow. This a lot of confusion and people trying to integrate frameworks and not knowing what to do, and there's some packages that have gone stale." So I'm putting together a resource for using frameworks with Python. And so, I'm going to talk about the major ones. Bootstrap, Zurb Foundation, and UIkit. And so, if you're interested in any of those three, and you haven't been using them in your current projects, I'm going to put together a resource there for you, so that you can get started with it very quickly.

55:41 Michael Kennedy: Alright, yeah. I'll link to both of those in the show notes so people can check them out. James, it's been great to have you on the show. And really enjoyed this design focus conversation.

55:49 James Stone: Yeah, thank you. Thanks for having me.

55:51 Michael Kennedy: You bet. See you later. This has been another episode of Talk Python To Me. Today's guest has been James Stone. And this episode is brought to you by Linode and GoCD. Linode is bulletproof hosting for whatever you're building with Python. Get your four months free at talkpython.fm/linode. Just use the code Python17. GoCD is the on-premise, open source, continuous delivery server. Want to improve your deployment work flow but keep your code and builds in-house? Check out GoCD at talkpython.fm/gocd, and take control over your process. Are you or a colleague trying to learn Python? Have you tried books and videos that just left you bored by covering topics point by point? Well, check out my online course, Python Jumpstart By Building Ten Apps, at talkpython.fm/course to experience a more engaging way to learn Python. And if you're looking for something a little more advanced, try my Write Pythonic Code course at talkpython.fm/pythonic. Be sure to subscribe to the show. Open your favorite podcatcher and search for Python. We should be right at the top. You can also find iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm. This is your host, Michael Kennedy. Thanks so much for listening. I really appreciate it. Now get out there and write some Python code.