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 at Talk Python.
Talk Python to Me is partially supported by our training courses.
Do you want to learn Python but you can't bear to subscribe to yet another service?
At Talk Python Training, we hate subscriptions too.
That's why our course bundle gives you full access to the entire library of courses for one fair price.
That's right.
With the course bundle, you save 70% off the full price of our courses, and you own them all forever.
That includes courses published at the time of the purchase, as well as courses released within about a year of the bundle.
So stop subscribing and start learning at talkpython.fm/everything.
Hey, James.
Welcome to Talk Python.
Hey, Michael.
Thanks for having me.
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.
And 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.
Nice.
Yeah, absolutely.
So before we get into those topics, though, let's start with your story.
How did you get into programming in Python?
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.
And 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.
And 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 kind of kicked out of high school, or you might say like in air quotes, like asked nicely to leave.
They said, you know, you just can't stay here kind of thing.
Yeah.
Well, OK.
What was the reason for that?
It was maybe an ends to a means.
But I lived on a small island in Washington.
And this is at 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.
So there was a library system there.
So I started hacking their system.
I figured out a way to kind of break out into Telnet and start accessing interesting shell servers over in Seattle, kind of circumventing the long distance thing.
I basically kept doing the same thing in high school and had kind of a knack for finding maybe exploits or ways to kind of break software, use it in ways it's not supposed to.
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 the 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.
That's really interesting.
You know, I feel like a lot of times structured education misses opportunities to take people that are super creative and find like, you know, these rules, they don't actually have to exist, like whatever.
And like turn that into they probably could have like redirected your energy into something like super powerful.
But instead, they just said, we're going to unplug you.
Yeah.
I think I'm kind of a product of of that system, not really having a good a good avenue for those interests or pursuits.
So they were scared.
Yeah, sure.
Of course.
And it was all bizarre.
Nobody knew really what to do with the Internet anyway.
And that idea of like the way you got on the Internet was to find like something you tried to access over one of these dial up things that then failed and dropped you to a talent shell.
That's I haven't heard that from any other people, but I've experienced this as well.
It's interesting.
Awesome.
Okay.
So that was high school.
And you were going to start there in programming.
Yeah.
So I had kind of a start in programming.
And, you know, in high school, they had like a Pascal class.
I was super fired up about that.
I was doing some C and some things.
But but I wouldn't call myself like a professional programmer.
I certainly had a lot of interest.
And what happened is a friend of mine helped me get a job in the 1990s at a startup where I learned to kind of become like a professional programmer on the job.
And so basically they threw at me the Java 1.2 or Java 2 Bible, which was pretty thick in those days.
And they said, get to it.
And I think it was a few weeks later, I was writing production code and in charge of data classes.
So I started mostly doing back end programming and Java back in the 90s.
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.
Things like this.
Yeah.
So much more portable.
Byte code was going to be the future of everything.
You just wrote it once and it ran everywhere.
It was amazing.
Yeah.
It's so funny to think back about those those days.
You know, fast forward.
I've always been involved with programming computers.
I went back to school because, you know, I kind of dropped out of college.
Eventually went back to college.
I actually studied art and then found a way to kind of combine computer science and art after kind of having a short career.
As a professional programmer.
And so now coming from it from a little bit different angle, the lead into Python is always been interested in Python.
And recently my wife started doing astrophysics work and she did a master's and now she's working on astronomy, PhD.
And so she taught herself to code in Python, you know, for scientific purposes in about a month with some books.
And so it's very interesting for me because she never did really any programming at all.
And so now I guess maybe because 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 times.
That's a really interesting story.
Python has taken over astrophysics.
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.
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 for controlling a lot of the major new telescopes that are going up are done in, you know, basically the APIs for them are Python.
And a lot of the machine learning stuff to discover a lot of the stuff in the visual stuff is Python.
So yeah, it's really interesting to see that she taught herself that to get going there.
Cool.
That gives us a lot of what you've been, you know, what got you to where you are today.
But now what do you do day to day?
What I do day to day now, I've got a little bit of a split life.
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 that 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 be one designer or two designers in development teams, helping them to work on their web projects.
On the other side of what I do, I teach 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.
Okay, cool.
So the creative code part is basically simplified coding for creative types.
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, you know, 3D OpenGL animation and having things render quickly, like a kind of a game style 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.
That's really cool.
So the first thing that I want to talk to you about as 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 like 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 like design is basically colored terminal.
Maybe they work on web apps.
Maybe they work on other kinds of apps.
But I feel like there's 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.
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've maybe you feel you're creative in certain ways, but maybe design and art or maybe not your forte or you've never had experience.
It can certainly be daunting because there's a whole nother language.
And sometimes the way people are realizing things, it seems difficult to kind of 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 think even 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 kind of like born an artistic design genius and that's it.
Like 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, right, and software engineers.
They take my course because they want to do something created.
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 kind of have these little pieces that 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.
I totally agree with that.
And like, how do you think people should get started?
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 doesn't really do the UI stuff other than just, like, get it in place and pass it off, right?
What are a couple of steps people can take to really, like, get better at that?
Yeah, to get better at design, I think, you know, it's a couple 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's just, like, how we have variables and functions and all these types of...
Why can't I put it all in one function?
It's only 3,000 lines.
Exactly.
And so in design, there's, like, these principles of alignment.
So often designed elements will be aligned with each other.
So, you know, 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 there's, you know, balance and contrast.
And 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 the web.
So I jump very quickly from a sketch, for example, to, like, just building it out in code.
Like, sometimes I skip that whole using a visual design application.
Right.
Okay.
Yeah.
So you do your initial work with pen and paper or with a stylus type thing?
Yeah.
So in the past, it's been pen and paper with, like, Sharpies and, like, Copic markers.
And lately, it's been on, like, an iPad Pro.
And part of that's 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.
Yeah, that's cool.
I have an iPad Pro with an Apple Pencil, like the 12 point whatever inch one.
And I actually, part of this getting better 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 on this thing.
Even though drawing was something I thought I was very bad at.
And, you know, with a lot of practice, you can do it.
It's a pretty nice experience.
Yeah.
No, I totally agree.
And I think the experience in the iPad Pro is quite good with that.
The Apple Pencil.
I actually studied for a time traditional animation and illustration.
So I have a lot of experience with this like kind of like 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, you know, when I tried to get into this ranked program at San Jose State, those guys are hardcore.
Like I remember that they said, this guy draws like Michelangelo.
And so I think if you're thinking, oh, I can never be an artist.
Like 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?
Well, 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 like a digital artist?
So you also had a resource you wanted to reference about this sort of design as a superpower concept.
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 back end.
And you're, say, building out some smaller projects, personal projects, and 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, like, color choices, right?
Like, alignment, kind of basic principles of design.
But she explains them in a very developer-friendly format.
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, you say, okay, first thing you type is, you know, angle bracket HTML.
You also get a CSS file.
Design that.
Like, 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, 70% good with these front-end frameworks.
So maybe tell us about front-end frameworks and some of the ones that are great.
Yeah.
So my exposure with front-end frameworks happened kind of, like, in the early days of responsive.
And so this is kind of Zurb Foundation version to kind of bootstrap to simple stacking and responsive.
But, I mean, what they've done for the web is, I think, nothing short of amazing.
Because if you find pretty much any website that was built before these existed, because I think they've raised the bar in design for the stuff that's hand-coded.
It's like you look at websites, you're like, wow, this is, like, from the 1990s or from, like, the early 2000s.
There's, like, these two big gaps.
You can, like, really spot it.
The site has a Y2K problem, but it's not broken.
It just looks like it.
Exactly.
I think, one, they take these design kind of 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 if you 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 or Mosaic if you don't actually spend the time to style it.
And what the frameworks do is they kind of 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's a lot of complexity in, like, how you might use it to create visual effects.
And 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 float-based grids.
And so there's a lot of kind 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.
I think you're totally right on with that.
And there's also some of the underlying things that you get that are just non-obvious.
What you were touching on before about, you know, the subtle color changes, the topography, the line spacing, the reset CSS.
So Firefox doesn't look different than Safari or, you know, whatever, right?
There's just so many subtle little things that you can kind of 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.
I think that's what a lot of people are thinking, like these accordions and tabs and this kind of interactive, more sliders and that kind of stuff.
And that's certainly 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 is just handling that interaction.
There's a couple of really popular ones.
There's Bootstrap.
There's UIKit.
There's Zurb Foundation.
And you're actually pretty involved with Zurb, right?
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 in their philosophy.
And I think they're better suited to certain projects.
Sure.
My site's based on Bootstrap.
I've done a lot of Bootstrap.
Primarily, I've chosen Bootstrap because, well, one, it was pretty early.
And the other, there's a lot of themes for it.
So I go grab stuff for it.
But I'd love to hear your thoughts on, like, the pros and cons of each or, like, even just why Zurb is awesome over Bootstrap.
Things like that.
Because this is, a lot of times you have to choose that right at the beginning before you've even done a lot with it, right?
And then you're kind of like, well, I'm not redesigning it now.
It's done.
Sure.
I would say the reasons that you talked about are actually some of the great reasons to use Bootstrap.
Bootstrap is one of the, probably the most popular framework by a much large, like 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's 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 kind of 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, right?
Or you do hackathons.
Like, this is the perfect type of thing, because you can just use Bootstrap and build upon it.
And then I think, you know, you can make some pretty moderate changes and restyle it, but the themes are really kind of probably the more powerful way that you can get closer to the visual style that you're looking for.
Yeah, I totally agree.
But how about Zurb?
What's awesome about Zurb?
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 Zurb Foundation.
One of them can just be an aesthetic.
Like, some people like this very minimal aesthetic of, like, the Zurb Foundation, unstyled kind of look.
And there's 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 kind of like a wireframe.
And it's 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.
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, you say Engelbrack 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, like, keep doing their web stuff?
Yes. I think it's much more a framework for designers because, like, the emphasis is on design.
So if you're coming from, like, say, your app or your marketing site and you have fully realized, radically different than bootstrap visuals, right, for all the pages.
And this is, like, how you're starting your process.
And then you're trying to convert that.
So foundation is going to be a better framework for you, whether you're a designer or a developer working on a team like that.
Okay, cool. And are there some themes out there that you can go, Graham, that people built, like, landing pages?
Or is you really, you're starting from the framework?
You know, like, I know there's been some discussion on themes for foundation and, like, 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.
This portion of Talk by Thunder 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's a data center near you.
Whether you want to run your Python web app, host a private Git server, or a file server,
you'll 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-world examples that you've worked on with Zerb.
Yeah, so I've done some work for agencies, subcontracting, 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.
And it's a very interesting kind of solopreneur, self-funded startup.
And what they do is they create children's stories that are completely customizable, where there's a cast of characters that resemble your family.
And so we created this character builder that's kind of based loosely on the we, you know, the, I can't remember what it's called, the we, me, you know, we have the character we kind of customize.
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 kind of in the background.
But the styling of it is very visually distinctive.
So I think that in this case, Server 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 like UX design, kind of solving the experience and what that was like.
And then later on, we actually brought in a visual designer, a UI designer, Marcus Handa.
And he, we came together, and then we actually won an award called the Ippy Award for one of the best publisher websites for that year.
So I think it's International Publisher of the Year.
Yeah, that's a really nice idea as well.
Like have a book with your child as the character.
And 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 a person who owned the company, created the books, and had the idea.
And then they wanted to work with you.
I suspect they were probably not a developer or they would have like put something slightly less nice together or whatever.
But maybe let's focus it on like how developers should interact with designers.
So I suppose sometimes people see this as like a frustrating 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.
And, you know, like what can people do to maybe make these like really great interactions and where people are supporting each other?
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 this 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 because 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.
But 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, including 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, you know, not too many connections, like, you know, really smooth, really quick.
And so we're actually kind of working towards the same thing.
Like, so 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 know, you mentioned the wrong color are off by three pixels.
But I think what I've seen that can kind of be a bigger problem is when there's a little bit of a detail in the design where you really need to kind of let the design team know early on or the stakeholder in the project that it's going to be expensive, right?
Sometimes there's a little flourish, right?
And that flourish is going to be like 10 times, you know, 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, because 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?
For they really want that flourish or whatever.
And so they're kind of 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's some, I'll put in air quotes, like crazy thing that you're, like, freaking out, like, how am I going to even do this in our system?
Or is it going to be cross-browser?
Yeah.
They know it's HTML, right?
They know it's HTML.
It's not print.
Come on.
I want it always to be exactly the size.
It's not 8.5x11.
Come on.
Yeah, exactly.
Something like this, yeah.
Yeah, exactly.
And so, and 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, like, 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 weight, right?
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, like, you're going to hang out while they're sketching all the time, but just maybe to inject the engineering thought process a little earlier on so that it doesn't ruin your day, like, you know, a week or two weeks from then.
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, like, 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, you know?
Maybe, one, having some sympathy for the pressure that is on the other side of that story for the designers, right?
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 in earlier.
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, where, you know, designers are over there, we're over here, and we see them in the hallways, but we're not interacting as much.
Or, you know, some places have places where it's much closer, right?
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 a team, right?
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've 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 know, 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.
Because they have the designer, they've got the back-end team, and they don't know how to...
They bring you in to be the bridge.
Pretty much.
And so I think that's something that can be really quite useful.
And just to get involved more in the process earlier on.
From both sides, too.
Designers.
Designers, you know, should get involved.
Not telling you the nitty-gritty of what you're doing, but like 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?
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 there 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.
And like 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 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.
I'm 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 like say, here's how you get there.
What do you think about that?
I mean, there's this tension, right?
Not every designer is a web developer, for example, but what do you think?
Yeah, I think it's maybe in a lot of cases unfair to just tell.
Well, designers, look, we need you to code or we need the code.
However, you know, there's some more modern thoughts, right?
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 is 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, right?
There's a tool called Zeppelin IO.
There's another one that I like lately called Simply, 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 Avocode, like avocado, but with code in it.
And 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 stuff.
So for me, when I'm building stuff on the front end and I'm building out the CSS, like I need to
click on an object.
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 lock down 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 use or explain 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 a designer, but maybe it's someone on the dev team.
It just depends on who does it.
Yeah.
I really like the idea, especially of working within the constraints of like the CSS box
model and stuff in the grid system, because I feel like that's where it gets really hard.
It's like, I want it to go like this, but then you move it, it goes like this.
You're like, but that's so hard in HTML, right?
So you're kind of like, you're working with the same clay, not steel versus mud or whatever.
And it's getting better.
I think with flex box and CSS grid in terms of grid systems, some of this is getting a
little bit better and less, less hacked, but some things that I've done, you don't see that
many tables as front pages anymore.
Yeah.
I'm building all my websites, all the tables.
They're all like, like this cut up Photoshop from the nineties.
Yeah.
Or two thousands.
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 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.
I think when you're coming at this, right, like you have to think about like what's going
to be the most fluid process.
Like how can you help the people on the other side?
Like if you're a designer and you care about the design, like you want to hand this off
in a way that's going to kind of carry over the design intent.
Clearly, like we both, you were joking, like I gave you the image, like just build it.
Like 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, you know,
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 it's like, so I'm placed in the position and I obviously had 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 of like 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 like skip that whole part.
Like it's like, it's kind of like the modern day version.
I think of just handing off the image is like, oh, the mobile.
Yeah.
You just like put a hamburger menu on that.
Exactly.
Using the foundation, right?
So you'll be fine.
Exactly.
Yeah.
We're using foundation.
It's responsive.
It says responsive.
It says responsive right there in the design.
Yeah.
I've had people say, you know, this website is not responsive.
I thought you were using bootstrap.
It's like, you know, you have to employ the features of the thing that add the responsiveness
to it.
Right.
It's not just pixie dust.
You sprinkle on it.
Right.
Yeah.
And there's some patterns that are, they're challenging too, like mega menus and that kind
of thing.
Like how does that work on mobile?
Like that, it depends, right?
Depends on what kind of crazy menu you've thought up in the first place.
Yeah.
Yeah, for sure.
Smaller minimalist.
That's what I say.
One thing that you brought up is like having like named colors and things like that.
Like, do you recommend that the dev team use something like SAS 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.
Yeah.
I think it'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 SAS does a couple of things.
So it is programmatic.
Sorry, before we get too far, maybe not everyone knows less than SAS.
You want to just define that real quick for them?
Yeah, sure.
So if you don't know less than SAS or, you know, there's post CSS as well, but they're
CSS preprocessors.
And so what 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.
I mean, sure, you could start generating like tint lists and 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 like 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 that like things are named like
something, something like number two dash three.
And you're like, and you're going through this trying to make sense of it.
And it's difficult.
Like we have a 5,000 line CSS file and one of them.
And why?
Yeah, exactly.
Like, why is this okay?
Yeah, so I think that's a disaster.
Because like, how are you going to maintain that?
Like, that's like opening up a single 5,000 line Python program.
That's not any sort of order.
Like, what are you going to do with that?
Well, yeah, 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 and then like 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 like in this obscure page was depending on that thing?
It's just really hard to know that you can like clean up this dead CSS code equivalent.
Yeah, they do have a good tool for that now called un-CSS.
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 like shoved it in the closet, I think it's
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 on the file.
It just doesn't render out to the website.
So it's a good solution.
But that's cool.
How does it work with potentially like dynamic stuff like Chameleon or Jinja 2 templates?
How does it work with like, say something behind a login versus public?
You know what I mean?
You're like, oh, there's that admin page thing.
Maybe is it like, does it address any of that stuff?
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.
Right.
And so then you're like, okay, like, how can I program this stuff to sweep more stuff
into like 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 pared
down.
And I found when you keep things organized, just like in your room, if you had a clean room
is like perhaps you get older and you're more clean or organized.
You can find things very quickly, right?
Like you're like, where is this thing?
And so when you go and inspect it in Chrome, because you have a map, it'll tell you it's
in this file on this line.
It's like 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 like super obvious, like what's going on.
Yeah, that's cool.
A lot of times I'll try to have like a navigation CSS file, maybe like a store CSS, a homepage
because homepage, like the landing page always seems to have like a bunch of insane styles
that don't appear elsewhere on the site.
So yeah, I definitely think organization is important.
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 like 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, you know, 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 that you're using the wrong red.
And so this is, like I said, I went through like hundreds and hundreds of variations of those
reds to kind of clean it up.
And, you know, you find this like pound, like foo, you know, F zero zero, this kind
of red.
And it's like, that's not the right red.
And so the other thing that's really nice with SAS 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 preprocessor.
Oh, wow.
You could even like bring that into like a continuous integration workflow.
Yeah.
And you could either warn people or kick them out so that it won't render the CSS.
Actually fail the build.
That's crazy to fail the build because the CSS is like using the wrong color.
I think that's awesome.
Didn't know that was an option till just now.
Sure.
So maybe that's a good place to like touch on a few final things around methodologies.
Like one of the things you've talked about is designers, developers working together using
outdated methodologies that 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?
I've been doing stuff on the web for quite some time.
And I think like the old school way is, like you said, like the designers like huddle and
come up with some crazy design and kick it over the fence.
And then you're like, 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.
Like music when it came on a physical thing, you carried it around?
Yeah.
It was like all like on CDs and this kind of thing.
And so I worked at a music magazine and I remember that creative director came up with
this design.
And this is back in the days of tables.
And he had this like 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 like kept, you know, like this whole kind of argument.
And he didn't buy it at the time.
But this is like the thing, like kicking it over the fence and like developers, you're going
to have to struggle and make it work or else, right?
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 like kicking it over the fence and
the 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 like 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 like major changes.
So like not, not like you're building the app day to day, but like you're going, like 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 backend.
And so 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.
Are you suggesting they create that in HTML and CSS or that they create that as like a Photoshop
type of graphic?
Put a little structure on that.
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 as an agency.
Now, what they do is very interesting because they build different websites for different
people, right?
So last time I heard, they produce something like 100 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 that 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 like 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 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 like what
kind of partials are they going to use on the back end?
You can build it in the same way, the front end code.
So it'll resemble that when you're looking at it.
And then it also has this tooling for the SAS build, which has auto prefixer and it could
have on CSS 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 will 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 bootstrap website,
their documentation is 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, you know, just HTML.
And what it does is it walks, it'll go and render out the live code in the browser and then have like a
copy and pasteable version right below it.
And so you get the same kind of automatically built style guide that you would get from
Zurb Foundation pared down a little bit, but specific to your project.
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 development world, we kind of moved, I'd say around the,
year 2000 and 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.
Yeah, absolutely.
Yeah.
Awesome.
All right.
Well, I guess we'll, we'll get a little 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?
I always open up sublime text three.
I'm a huge sublime text fan boy.
I've been using it since version two, which I guess doesn't sound that long ago, but they
have a very long version cycle.
But yeah.
Yeah.
And I used to work with them and some other editors and I just something about it.
It just like, I feel like, like I don't even have to think like I could just work really
quickly.
As far as notable packages or libraries, what do you think?
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 Hamill, right?
Where you have a CSS selector and you're just kind of combining them together like a UL, right?
And then you've got the LI and then you can multiply.
And so you can build these structures really quickly in HTML.
Let me give a concrete example where people are listening if they haven't seen this,
because it's really awesome.
So imagine you want to create like a unordered list of 10 items and you're in a static editor.
You could type left bracket, left angle bracket, UL close, left angle bracket, LI close.
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 angle bracket, LI star 10 tab.
And it goes boom.
And it just expands them all out, right?
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 like 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 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.
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 dot products greater than LI dot product star 10 and tap.
And it would put all those classes on the elements as well, right?
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 because you can say like lorem
10.
It gives you 10 words of lorem, but you can say like lorem one, but you know how you're saying
you can use the asterix 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.
That's awesome.
That's like the lorem, some sort of meaningless text to just fill in stuff that,
those stakeholders don't look at it and go, whoa, but it's not supposed to stay there.
It doesn't mean 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, hipster, hipster, hipster, hipster, hipster, no, no.
What is that?
It's hip sum.co.
It's the same thing as lorem Ipsum, but it's hipster speak.
That sounds fantastic.
It's fantastic, man.
It's, it's beautiful.
And maybe I'll read you a little, like if I could just pull it up here, let's just do it.
It says shabby, chic, aesthetic, subway tile, pabst, a fagetto, dream catcher, narwhal.
It just goes on and on.
It's beautiful.
I've been starting to move towards the hipster Ipsum lately.
Nice.
Maybe we should fork Emmett and integrate the hipster Ipsum in there.
We definitely, definitely should.
All right.
Well, I definitely recommend that as a editor plugin as well.
That's cool.
So final call to action before we call it an episode.
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 created the coded style guide, you can learn
how to do that at design systems crash course.com.
But more importantly, after you're done with the course, you'll get on this kind of internal
insider 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 front
and gold and like how to build code, how to work with SAS, like how to make sure colors
are consistent.
And so if you've got the kind of like design twinkle in your eye or in the back of your
head, like it might be something you might want to check out design systems crash course.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 Zerb Foundation and Python and I thought, wow, this sucks.
There's 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, Zerb 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 you can get started
with it very quickly.
All right.
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 focused
conversation.
Yeah.
Thank you.
Thanks for having me.
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 workflow?
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 10 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 Python 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 the 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.
Thank you.