02:29 - Sean Fioritto Introduction

02:52 - Design and Sketching with CSS Background & Overview

06:34 - Developer <> Designer Communication

12:23 - Using CSS Over Photoshop, Alternative Programs, and Frameworks

15:29 - Grid Systems and Resets (Frontend Tools)

17:27 - Prototyping (Workflow)

23:14 - Documentation

26:14 - Adopting New Practices (Progressive Enhancement)

45:33 - The Modern Web Moving Forward

47:30 - Keep Up with Scott

Picks

NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence by Pramod J. Sadalage and Martin Fowler (David)
RoT.js (David)
The Spatials (David)
The User is Drunk (Saron)
Drunk Kitchen (Saron)
The Reckoners Series by Brandon Sanderson (Chuck)
Bootstrapping Design: Roll Your Own Design by Jarrod Drysdale (Sean)
The Ruby DSL Handbook by Jim Gay (Sean)
Ryan Castillo: 7 Recurring Recipes for Consultancies (Sean)
ExpeditedSSL (Sean)
The Life-Changing Magic of Tidying Up: The Japanese Art of Decluttering and Organizing  Marie Kondo (Sean)

Special Guest: Sean Fioritto.

 

Well then, what makes you so special?

Hang on, Chuck. That’s the question I want to save for the show.

Hey everybody and welcome to episode 203 of the Ruby Rogues podcast. This week on our podcast, we have Saron Yitbarek.

Hey everybody.

David Brady.

There once was a man from Peru whose limericks all ended on line two.

I’m Charles Max Wood from DevChat.tv. We’ve got a special guest this week, and that is Sean

Fioritto.

Hey guys.

Did I say that right?

Totally. You nailed it.

You want to introduce yourself really quickly?

Sure. Let’s see. I’m a developer. I’ve been a professional developer for the last ten years. About two years ago, I quit my day job and started working fulltime on a couple of different products that I do. I do a little bit of consulting as well. That’s basically what I do in a nutshell.

We brought you on today to talk about design and sketching with CSS.

Right.

And I know you have the book ‘Sketching with CSS.'

Right.

Do you want to give us a thumbnail on that and then we can start talking about some of the design stuff?

Totally. I’ll give you a background of the problems designers are facing these days and then the challenges that they run into and how the book helps them. But the issue is designers for the longest time, a web designer’s job used to be to create what they called comps with Photoshop. So, they get a project, they’d create a design comp in Photoshop, and then they give this picture of a website and they hand it off to a frontend developer who’d then slice it up and create a version of the website with CSS and HTML. So, that worked for a very long time because for the longest time the web was running on basically the same machine over and over again. It ran on those beige PC boxes with the floppy disk drive that’s running IE6, IE7, standard monitor, very homogenous. And, of course, that is not what the web looks like anymore at all today. It’s running everywhere.

And so, websites are expected to run on all different kinds of devices. And so, that’s a challenge for a web designer who is still using Photoshop as their primary tool. In fact, it doesn’t really work. And so, for a while now, for a couple of years there’s been this, I guess I’ll call it a mantra that web designers should design in the browser. And so, this is this idea that web designers should skip using a tool like Photoshop altogether, maybe do some sketches, something like that, and then start creating their comps in code directly. And it’s a good idea because as you’re writing code, you can actually see the site as it develops and load it on all kinds of different devices and see what it’s going to look like and build it from the ground up to work on all these different devices.

The problem [chuckles] is that the adjustment going from using Photoshop all day to all of a sudden going straight to code, that’s a real big problem for a lot of web designers. And that’s because a lot of web designers, most of them know how to code enough at least to get some version of a website working. But the big problem then comes when they need to sit down and be creative while writing code at the same time. And a lot of web designers find that nearly impossible. And that’s because there’s just this whole wall of technical stuff that they have to get over in order to get a pixel on the screen. There’s just so much work that they have to do before they can even see any sort of result in their browser as they’re starting.

And then there’s also a huge learning curve. If you guys do frontend stuff, you know that the [chuckles] world of frontend development has exploded in the last couple of years. And if you’re experienced with it, it’s hard to see [chuckles] that it’s really complicated if you’re just coming at it as a beginner. So, there’s this huge massive learning curve.

So then, the book is essentially, it’s like a light version of frontend development. It’s specifically designed for web designers who are creating prototypes in the browser. So, it’s like, all the tools that you can use, picking and choosing only the stuff that’s going to help you get pixels to the screen faster. And it’s basically, I’m creating a set of tools that’s easy to learn and gets out of your way pretty quickly once you get the basic idea of how they work. So then, you can, it’s a lot easier to be writing code and then see these results as you’re working. So, that’s the notion of the book, if that makes sense. So, does it make sense now that I’m not a designer?

That is actually very cool. And yeah, I was waiting to pounce on you with, well if you’re not a designer, what are you doing writing a book about design? But that actually makes total sense to me as a programmer, which is probably a bad thing from a design perspective. [Laughter]

I was actually going to say, “This sounds really great for complicating the lives of our designers.”

But I’m a programmer. So, does it work the other way? Like, for me…

To more design?

Moving more toward design to make design more approachable.

Ah. Well, we’re not…

Because I look at design and I’m just like, “Yeah, colors.”

Yeah.

And images.

And colors.

Well, okay. So, think of it this way. I think that there’s…

And fonts. Don’t forget about fonts.

Right. I think that there’s…

Oh fonts, yeah. That’s bad.

A limited language that developers should learn in order to be able to communicate with designers. And it doesn’t mean you have to be an expert designer. But I think that there’s a core set of concepts which you can learn to a certain degree which would then make it easier for you to work with designers, if that makes sense. And so, it’s the same thing applied the other direction from designers to developer, and that is once they… because that is one of the things with the book is that, and that was sort of controversial [chuckles]. A lot of frontend developers complaining about this. But it’s not the code that I say they should create. At the end of it, it’s not something that’s necessarily going to make it into production. Like if you’re only working with modern browsers then probably. But I [skew it] to talking about or worrying about maintenance, worrying about performance, that sort of thing, code readability, stuff like that. I think that stuff is not important to designers creating a prototype.

But the big thing is, and the thing that I tell everybody is that, okay, a designer that can actually do that, that can give you code that works and understands how this stuff all fits together, they may not be able to think about it at the level that a more experienced frontend developer does eventually. But the designer that knows how to do that can have that conversation with… can work way better with a developer, if that makes sense. So, in my opinion I would rather get code that’s not necessarily ready for production versus just a Photoshop comp. [Chuckles] I don’t know if you guys have ever had to do that, but it’s not… there’s a lot of gaps between a Photoshop document and a website, and then designers that don’t know how websites work. So, I think this is a big move forward for a lot of web designers.

I completely agree. I can tell you that I’ve had nightmares about, “Hide this layer. Hide that layer.

Hide this other layer in Photoshop,” right? [Laughter]

Yeah.

So that you get all the text off so that you can get the background. And then if you don’t slice it just right, then it’s almost the right size. So then I have to go back and get the original and blah, blah, blah, blah. And the other issue is with responsive sites, that’s effectively two, three, four designs.

At least, right.

And so yeah, so then you’re dealing with all of that. Okay, well now I have to go into Photoshop and figure out how to squeeze it all together. And if it a designer was just getting in there and it’s like, “Okay, make your browser half the width of the screen. Okay, now what we want to do is make it look pretty again.” And those are the words that I use, right?

Yeah.

Is pretty and usable.

Right.

Those are the words I throw at designers.

Right.

But you know, so then if they can just see it and understand, okay, you just put this… I can manage the media query.

Right.

Just save it off to somewhere else.

Right.

But yeah.

And so, have you had a lot of experience sitting down and working with designers and creating the code as they’re telling you what to do? Is that something you’ve done?

Not really.

Because that’s where I’m coming from. I did that…

That would be nice.

For years at my last job. They, for some reason, well I don’t know. It’s kind of smart, actually. The managers at this last, this company I worked at, figured out that an interactive prototype of something was way more valuable to convincing other people to do a feature than just pictures and mockups and stuff like that. So, they would send designers over to me, sit next to me, and then designers would sit there and tell me what they wanted. And then I would have to try and make it happen on the screen as fast as possible while writing code. [10:44] to do… create a really quick turnaround on the [inaudible].

That sounds awful.

It was challenging.

It sounds really annoying.

It was really challenging. And at first it was, it would be like, oh one of the designers, her name was Kiki and she was always really annoyed with me. Because she would sit there and start messing around on her iPhone or whatever because [laughs] it was taking me so long to actually get something to show up. But eventually I figure out that I needed to toss out a bunch of stuff that I was doing that had nothing to do with creating this prototype. And when I did that, it really freed me up. and actually, I totally enjoy working that way now, because there’s all of this stuff that I was used to thinking about while I’m creating a site that goes out the window when you’re just creating a prototype.

So, cutting back the tools to the very basic essentials and stuff that you get used to using. It’s something that I talk about in the book, like muscle memory. Once you get to the point where you’re comfortable enough with the tools then it just happens. It’s a lot easier to get the code out to get the design on the screen more quickly. But anyway, I don’t know. I like it. I actually, I really do like cranking out prototypes like that.

Sean, be honest. Did you write this book so that Kiki can code her own stuff? [Laughter]

Is that what it’s all about?

They haven’t bought the book.

Ah!

I’ve been waiting for them to buy it but they haven’t. [Laughter]

That’s actually kind of a very programmatic way to do it, right? It used to be, go away or I will replace you with a very short Perl script. Well now it’s, go away or I will write a book to teach you how to replace yourself with a very short Perl script. [Laughter]

And I’ll make you buy it.

Yes. [Laughter]

So, I completely understand and appreciate the pain point. I was very, very comfortable with Photoshop for many, many years before knowing anything about code. And I would naturally do my mockups and my design stuff in Photoshop and then translate it into code, which was annoying and painful and very, very slow. I had nightmares about layers as well. And when I talk to designers they told me that they actually don’t use Photoshop anymore. They use things like Sketch and InVision and all these other tools that were meant to feel more web-y.

Right.

But not, and you know, be a lot, lot more simple and not do, they don’t really use Photoshop anymore. So, I’m wondering. Why is understanding CSS and doing it your way, why is that better than those other not Photoshop alternatives?

Well, okay. I wouldn’t… I don’t know if I’d say that it’s better. It’s a different solution. The tools are basically solving the same problem that I’m going after, right? So, there’s a couple of ways that you could go after it. I think, and I’ve messed around with some of these tools not too much, but a little bit, but I think that they still are too… one layer of abstraction too far for the most part. And I think that it would be okay if you were familiar with what was happening. If you actually understood what the tool was doing at a deep enough level, then fine, use the tool. It’s like this with programming stuff too, right? Like the Law of Leaky Abstractions.

Yeah.

You can only go so far up the chain of abstraction before, eventually something pops through and you have no idea what it means. And so, that’s a problem. So, I think that you should be comfortable with the one level below and actually know what’s going on. You don’t necessarily have to do that at that level. Maybe the tool is faster for you. But you should at least be comfortable with it. So, that’s always what I think about with these tools. There’s another one called Macaw which you didn’t mention but that one’s pretty popular. And then tools that generate HTML always scare me. I don’t even… [Chuckles]

You know what I mean, like I’m a little dubious about that.

Yeah.

We’ll see what happens. But, oh I guess that I haven’t seen what these things do. And then also, in the book I don’t recommend using frameworks at all, like Bootstrap, that sort of thing. And that’s because I think that, and frameworks and tools sort of have this same problem, that they put you in a box because you have constraints of the tool. And so, your designs end up being constrained by the tool or the framework or whatever it is that you’re using. And it’s hard to think outside of it. So, as soon as you run into a thing that it’s not obvious how you’re going to do it with the tool, then you’re not willing to, or there’s a lot of resistance to figuring out how you’re going to make it work. And so, a lot of times you’ll just end up going with the grain of the tool and therefore that limits the design.

I think that’s one of the reasons why Bootstrap sites and sites with other frameworks and stuff end up looking the same, because it’s just easier to do what it has laid out for you. Which I think is good, it’s good for code, right? [Chuckles] But I don’t think that that’s necessarily good for design. I guess it depends on how you think about it.

So, how do you feel about things like grid systems and CSS resets?

Okay, so a reset is incredibly helpful from a prototyping perspective. So then, I don’t necessarily think that you should have a reset in production code. But to start with a clean slate where you’re not battling… you end up, basically if you don’t use a reset you end up resetting all the stuff every single time you do it anyway, right? So you might as well just start with a clean slate and then add on with the resets. So, from prototyping perspective, cool with resets.

And then grid systems… okay, my problem with grid systems is that again, this goes back to this, it’s one level of abstraction too high. So, I do teach in the book, I teach designers how to create their own grid system. And I think that’s a big difference, versus use your own grid system, or use a grid system and learn how to use a grid system versus build your own. Then you have a much deeper understanding of what’s going on. And then also, it’s not that hard to build a grid system that does a lot of stuff for you. And I think a lot of designers don’t know it because they’re scared of, these kinds of things seem really intimidating.

One of the reasons I think these things are really intimidating is because a lot of times these frameworks and tools are built by really, really experienced developers for much bigger problems. So, a really experienced developer can see, they could take all of the problems that they’ve run into in the course of their career and then abstract it so they have this tool that can cover all of these problems. And that’s awesome. That’s amazing. So then you end up with a tool that can work in a lot different situations. But then that’s very intimidating for somebody who doesn’t have that level of experience, because there’s all this stuff in, what do you ignore, what do you need to know, how does it work, et cetera. So, that’s one of the big challenges with all these frontend tools.

So, as a developer let’s say that I have some app that I want to build. So, if I want to start prototyping in this way, where do I get started?

Okay, you’re prototyping a…?

Let’s just say that I’m going to prototype forum software online.

Okay, okay. Okay, so [chuckles] this is something that a designer might call a workflow, right? And designers need to have this notion of, how do I… and this is something people ask me all the time, is okay, so how does this fit into an actual project? Where do I start? And at what point do I write code? What point should I write code? And I think that, and I’ll try and answer you more specifically, but general answer here is that the way you approach this totally depends on the company that you work for, your client, the project. And I think every company, agency, studio needs to sit down and to decide how they’re going to work with clients. If it’s just you and it’s only you that is working on a project, that’s a weird scenario. But say you’re building this for someone else, right? So, can I do that? Can I say we’re building this for someone else?

Sure.

Okay. So, the important thing is, the way I would do it, is I would start with actually just talking about the functionality of what I want this forum to be able to do. So, we start that. And then we start with sketches, like on paper. Again, not a designer, right? So, [laughs] this is like, I know this is what designers do so I could say this. So, I would start with these sketches. But then okay, the point that you get to code, and I think it should be sooner rather than later, would be once you’ve uncovered some of these main features. And then I think what you should do is start picking off small components that you can start knocking out as prototypes.

So, you start talking about the interaction of what does it look like when, probably for a [forum] you’re going to look at what does it look like just to display all of the threads and all the information that we talked about displaying? How is it going to look like when somebody replies? Are we going to have nested threads? All of that stuff, right? So, I’d just start with that. And no ability to actually add posts or anything like that. Then I would just start with what is this initial… laying out the posts and then getting rapid feedback on that. And then go from there to adding on the other stuff, like adding posts. What’s this form going to look like that we’re going to actually be adding stuff into?

And what’s great about that is I have a friend who’s an interaction designer. And it’s amazing to me whenever I talk to him all of the things, the thought that can go into a form. Even the most simple form. And then the ability to knock out a prototype that you can actually see how this might play out and what this might look like, is really, really handy to have. But anyway, so that’s my suggestion. It’s like the overall, my thought is you should create small components and build the site one feature at a time, if that makes sense.

Makes sense to me.

You know, one tool that you probably all use that I talk about, that I teach designers how to do, is Git. And one of the things I think that’s interesting is, so all these tools that I talk about that I teach designers how to use, they’re designed for developers by developers. And that’s a really huge problem for somebody who’s not a developer, especially a tool like Git. [Chuckles] So, one of the things I like, I like to joke about… well [chuckles] it’s not really a joke. It’s reality. Linus Torvalds wrote Git for himself for the Linux kernel, for merging thousands of lines of code every day. That’s what he does. And every freaking Git tutorial starts out with learning about the DAG and [chuckles] all this stuff, which is interesting to me and probably you guys too, but for somebody that just needs to use the tool on their project it’s ridiculous. That’s totally not what they need.

So, what I do for Git and for some of the other tools too is basically, “Here are the commands that you should use. And you should use them in this order. And you do these things in these situations.” Basically like this cheat sheet. And so, you don’t actually need to know how it works and you get most of the bang for your buck with Git. And then what I’ve discovered happens is, because a lot of people have a lot of success with learning Git this way, they get really excited because finally they can actually use Git. [Chuckles] It’s been, they’ve probably tried before and it hasn’t worked. And then they get excited and then it’s a lot easier for them to go on and learn.

And so, at the root of this I think is developers suck at writing documentation. That’s basically how I make a living is what I’ve discovered, is developers are just terrible at writing docs for everything, which I find disconcerting. Because it’s like a basic communication skill, right? It should be also in our code too. I think about that a lot. [Chuckles] Developers I feel like should know more how to communicate how they’re tools work, why they work, and how to teach them to people. And that should also affect I think how they write code. What do you guys think about that?

I’ve never been good about writing documentation. So, whether or not I’m good at writing documentation is a completely other question. But mainly it’s because I’m focused on solving the problem. So, once I have the problem solved, I go refactor my code, I just want to be done. I want to go write more code. Writing documentation is a whole lot less fun. And I think several other developers that I’ve spoken with feel the same way. And to be honest, I’m just lazy about it.

Yeah, I don’t mind writing documentation because I’ve been on the other end of that fairly frequently where I’m the one being frustrated. So, I appreciate it. It’s more of maintaining it. It’s more of, if I decide to do it, I’ll do it for an hour or however long it takes to have everything ready. But then when things change, remembering to go back and keep it up to date, that’s the hardest part for me.

Keeping documentation up to date?

Right, correct, as things change.

Yeah, totally agree. One of the ways I like to think about that, I think there should be two kinds of documentation. And I see this a lot, but it’s not done really well. But there should be like, so there’s documentation where you’re saying how literally everything in your entire codebase works, which you need, right? Describing all the APIs, describing all of these things. So, that’s describing the ‘how’ which is, you need that. Once you’re familiar with why the tool is organized the way that it is then you need to be able to go back to these. You need a reference.

I’m going to push back on that just a little bit.

Sure.

I think the documentation is definitely important for some of that in certain circumstances. But I have seen teams make great use of things like style guides and just understanding the way that they craft their code and put things together, and then good naming to make it so that for the most part you really don’t need the documentation. You could just go look at the code. But…

Right, okay. But that’s just another way to have that kind of documentation but in your code.

Yeah, fair enough.

It’s the same thing.

But there are…

But they’re still missing…

There are always instances where there’s just not a good way to make the code communicate what it’s doing. And I think with more practice some of those can get better and with some of those there’s just no way. And so in those cases, yeah you need something that says, “Here’s how you use this.”

Okay. But that’s helping you understand how the code works, not how to actually get things done.

So, I guess in this case I’m talking about tools that you use.

Mmhmm.

Not necessarily, like documentation for tools that we use, so that’s a little different.

Okay.

Okay. So, what’s missing is, I think most of the time what’s missing is having a person in mind, an objective that they would like to achieve, and then getting them to achieve that objective with your tool. And that’s the big pieces that I see missing from documentation all the time. And then I see a lot of tutorials, getting started guides and things like that, and most of them are terrible for most tools unless we’re lucky.

If they’re even up to date.

Exactly. So, there’s this challenge of finding an up to date tutorial and then finding one that actually is going to help you achieve the goal that you’re looking to achieve, something that doesn’t make you feel like an idiot. And that’s another problem. [Laughs] For some reason, I don’t know. It’s just the way we are as developers but a lot of our tutorials and guides tend to make people feel dumb, especially when they can’t understand what’s going on. A lot of it’s just assuming too much, basically. Yeah, so that’s a lot of what I do. And it’s what I love doing, actually. I love helping people figure out how to use these things to actually get stuff done that they want to do.

I’m curious. Let’s say that you’re in an organization where they do the methodology where they go and Photoshop stuff… or even if you go to 99designs you wind up getting a Photoshop a lot of times. But let’s just go to the company. So, their designers do the Photoshop thing. They throw it over the fence. You just spend a week chopping it up so that you can get all the pieces looking the right way. So, the CEO is happy because he blessed the design and he’s super excited to see it out there. How do you get them to start adopting practices where they, for lack of a better way putting it, start making the designers write code?

Piece of cake. All it would take is one presentation with a working example of something that… like an interactive example of a feature or something that they’re doing. And this is more valuable when you’re working with an application, something that’s going to have interactions. So, the place that I worked at where we did this, it was actually, it’s an industrial supply company, which sounds super boring. But it is actually a really fascinating place to work at. But they had this huge website. They sell hundreds of thousands of things. And it’s a real challenge to help customers find the exact thing that they want. So, they had all kinds of little features and doodads and things to help people narrow down the exact little screw or strip of metal or whatever it was that they were looking for. And so, they were always coming up with different ways to help people do that.

So, when you’re working on that kind of problem, it’s basically like, what would happen is the designer should be like, “What if we change this interaction to be instead of a list of 50 checkboxes, we made it a sliding box, something like that?” And we do stuff like that all the time. And then when you do something like that, what you want to know is how are you going to… because as you’re changing the sliding box, the data on the screen is changing. So, how should it change in a way that’s not confusing to the person that’s using this and that actually helps them narrow down their choices? So, that’s usually the kinds of questions that would come up when they would propose these ideas to the CIO who was really hands-on at this place.

And so, what really helped with them was instead of what they used to do is they would create these, and they create these beautiful documents. It was really amazing what they did there with really pretty pictures about how everything would work. But then they take it in and then it was like, so what’s going to happen? It was impossible to visualize or explain what’s going to happen as things change. And so then, all I did was, I remember for one particular feature they actually just had me implement it so that it would work. We knew it wouldn’t work on every browser or whatever but it was enough that in this meeting they could be like, the executive would have a question like, “How would this work?” and they could be like, “Well, check this out,” and, “We already thought about this.” And they could actually show it.

So, when you’re talking about stuff like that, as soon as they started doing that, they got over the idea of having pictures of things. And everybody wanted an interactive demo because it was so much easier to actually talk about and see how the things would work with something that was moving. So then, if you have a site that’s not moving, that’s static. And you’re just creating four different versions of it, I don’t see… you’re not going to get that much bang for your buck in going straight to code for doing something like that.

So, it depends on what the company is doing, I guess, to kind of answer your question. If it’s a standard design shop and they’re just cranking out responsive sites for lawn mowing services or something like that, small businesses, and they’re not dealing with how to display tons and tons of data, so real big challenges, and it’s just like, “I need this to look good in four different screens and it needs to look good on an iPhone,” that sort of thing… I’m a pragmatic person. That makes sense to me that you could have, if you have the skills in your shop to have somebody just crank out four different things in Photoshop and then give it to developers and they just create four different versions, then do that. Do you know what I mean? I still think there’s a place for that, I guess, is what I’m saying.

Yeah, that makes sense. I think thinking about it, yeah what I see is, and I’m just going to basically restate what you said, but yeah. When you get a PSD which is a Photoshop file, or some other mockup, it’s a static thing.

Mmhmm.

And so, yeah, you can’t get the design on the interaction without a whole lot more work or forward thinking. But if you can actually sit down with somebody and basically say, “Look, let’s try this. Let’s try and interact with each other and build this up together,” then you can get the full experience that you want and make it all work out for you that way. I like the idea of going and proposing that you work together with somebody and then having it go your way. And also, then you get smooth transitions between states in your application.

Right.

And this makes a lot of sense for the single-page applications that seem to become more and more popular.

Right, exactly. Yeah, and that’s what we were working with there. And that’s what a lot of people are working with now. But you know the thing is [chuckles] designers do way more than make things look pretty.

Yes.

That’s not really what they do. Obviously that’s part of the end result, is things look good. But it’s more about achieving the objective of whatever this site is. So, even… I feel like even companies, even places that are making mostly static images, they would still benefit from having designers learn code, even if they still use Photoshop. Because I would think that as a designer I would want to know the medium that I’m working with and know the limitations and constraints of that medium.

And even a static site that’s relatively simple would benefit from that, from knowing web fonts for example are particularly slow to load on mobile sites, depending on how big it is or whatever. So, there’s a drawback to using tons of different kinds of fonts, or knowing that you can’t just have an image-heavy site if a lot of your users are loading things up over very slow data networks. So, you need to know about that. That’s going to come back and impact your design.

So, I guess it’s going back to what you were saying, like how do you convince somebody to take on this approach? That’s kind of another line of reasoning you could use with somebody. It’s like, your designs are pretty half-assed, sorry, [laughs] if you don’t actually know the impact of the design decisions that you’re making. So, that’s part of it. That’s a big part of it, too.

I know that the book is made for web designers, not developers. But it also feels like a really good way to get started in development. I know that a lot of frontend developers start off doing design work and slowly find their way into code. And this seems like a really good first step for that, kind of like an intro to code, doing things that you’re already familiar with.

I agree. Although when you’re doing something like writing a book, you really have to pick an audience and you have to in your mind know who’s going to be using this, and then have the courage to stick with it. So, the whole time I was writing it I was thinking, yeah, this could be incredibly useful for even, for beginners, also for developers that mostly do backend code that want to add some frontend stuff. It’s a great place to start there. But yeah, so I had to pick. [Chuckles] And I… those people do still buy the book and use it, but I feel like the more of a designer you are and the less you know about code then the more value you’ll get out of the book because I put more thought into moving that direction. But yeah, I totally agree.

Going back to the, how do you convince people, I think sometimes if you push back on what people are doing with a negative criticism sometimes that… yes, it can challenge them but it also often can entrench them a little bit, get them to dig in their heels.

Mmhmm.

And one of the things that I found really useful is to just give a killer demo and have somebody see what it can be like in this other way. So, you take somebody who’s spitting out PSDs and you say, “Hey, can we talk about how this is going to work dynamically?” And you sit down at your computer and you bring up the Flexbox, whatever, and you start fiddling with stuff. “If it’s here and they’d animate and they’d hover over this. And this thing moves over here,” and blah, blah, blah, and then you basically say, “Can you make me a PSD that has those elements?” They go, “Yeah, I can do that.” But they go away also thinking, “Holy crap, that was awesome. That had all the pieces to it.”

You had talked earlier… these two thoughts are joined in my mind about the persuasiveness of a killer demo because you talked about sitting down with a customer and working through the objective. And that’s what a designer does. And it’s not just making things look pretty but it’s also making things work right and making things useful. And I worked with a client about 10 years ago that had a website that you had to click on 17 different things to get to anything. And they only had three different models in their backend. So, there was no reason to click more than twice on anything to get anywhere in the entire website. And I rebuilt it with this in mind. And this is… I learned CSS back in the late 90s. So, when I design a website it looks like it came from the late 90s.

But I’m tempted to pick up your book just so I can learn what all the cool kids are doing these days.

I hear you’ve got rounded corners now.

Anyway, but I put up the site and a demo for them. And I got on a conference call with them because I was remote. And we started walking through this. And I knew I had nailed the design and I had convinced them of my process and of the way things are going to be when I heard the customer lean back away from the phone and shout into the other room, “Sandy! Get in here! You got to see this!” [Chuckles]

And then they asked for, “Well, what about if we did this change?” And of course this was one of my first Rails projects. So, I made the tweak and redeployed it and I’m like, “Okay, hit reload.” And the change was there. And they were…

[Inaudible], right?

Yeah, they’re blown away by it. They were completely abuzz with it.

Yeah.

Because the previous developer, anything that they wanted took a month to get the wrong thing every time.

Right. Yeah, so even I’ve done… [Chuckles] so my neighbor, he runs a limo company. And so, he really, really wanted me to help him with his website. It’s not a thing I would normally do [laughs] but I was like…

Yeah.

“Okay, fine. I’ll help you with your site.” So, it’s a very simple site. The last time he had it done was in the 90s I think. And this guy took months and months to make it. It has [laughs] It had this Flash animation of a limo driving back and forth along the Chicago skyline with this music that he invented for the [laughs] website with sparkle images and things.

Oh.

And my neighbor’s pretty [clueful]. He knew that a lot of his customers are surfing the web on phones and he knew this just wasn’t [chuckles] this wasn’t working very well on phones. He was loading it up on his. And so, he knew he needed it to work on different phones. It needed to work on laptops. So, I did this approach with it where I, even though it was again a very static site, I didn’t have a limo animation on it [chuckles]. I just created a nice static site. We talked about from the very beginning what the objective of the site was. And for him it’s very simple. He wants it on the phone as fast as possible because he’s very confident in his salesmanship. So, that’s how we designed the site.

And then I knocked something out that was like, “Okay, here are three different…” So, I use something called style tiles which is something that designers do that a lot of designers that are taking this design in the browser approach, they create something called style tiles which is like, “Here’s look and feel, what direction we could go.” And it’s a lot easier to break this out into, “Okay, here’s this combination of typefaces with these colors and these kinds of lines and borders, and things like that, and these kinds of images.” And so, you could get a feel. So, throw those at him.

It’s like paint chips, like paint chips for the web.

Exactly, exactly. And then I knocked out a version of his site. Then we sat down. And it was exactly the same experience that you had where because I was… and again, I just created a prototype. I knew this needed work on lots of different browsers but I didn’t care about that. Because the next step that I needed to get to was get this in front of him and then let’s actually make sure that this is what he wants.

And a lot of it has to do also with just getting confidence, developing confidence in your abilities as a contractor. And so, a lot of that has to do with communication. And having a prototype that works that you can change on the fly while you’re talking with a customer goes a long way [chuckles] towards developing that confidence in your ability. And yeah, so he was blown away that A, it took a couple of days, and B, that we could sit there and just make changes that he wanted to do right there in one or two lines of code change, that sort of thing. So yeah, there’s a massive, massive benefit to doing it this way.

The other thing I think a lot of consultants that do design in the browser, I read a lot about this and one of the big things that they say over and over and over again is that a Photoshop comp is just a picture of a site. It’s only useful to a certain extent. Because sites, even the most simple website, is interactive. You’re going to do stuff on it. Scroll, read, click on things. There are interactions with this thing. It’s a thing that you interact with. And so, you don’t get that at all with a comp, with a

Photoshop document. And even the most simple website, like my neighbor’s limo website, which is like two pages, you just simply don’t… I don’t think a Photoshop document would have achieved the same effect as an actual website that he could see and load it and know that it was an actual, “Here it is.”

Also I think there’s a fluency that’s forced upon you at that point or upon the designer where, I joked earlier that I hear you kids have got rounded corners now. And if I don’t know that and I’m a designer, well Photoshop’s going to let me make arbitrary curves. So, I’m going to design a website that’s got elliptical rounded corners or it’s got some weird… and if I’m fluent in CSS and HTML layout, then I can go into that knowing what’s already there. And I can go in there and I can make the right call of, do I want elliptical corners bad enough to have an image border versus having the browser actually render rounded corners for me? And if you work in this tool, the fluency’s forced upon you, which is great. I can’t speak for other people but I know the best designers I have worked with in the past that have been pixel Nazis, well that’s the wrong term for it, but people that are…

That’s a good term. [Laughs]

People that really want their design to match pixel for pixel.

They call it pixel perfect design, yeah.

Pixel perfect design, yeah, and the developers… I just know the term for the developers that have to work for them were called pixel pushers.

Yeah.

Because you’re pushing things one pixel over, right?

Yes.

And so basically, you can make that decision of, do I want to push pixels around or do I just want the sketch to go and work? And if you really are a pixel pusher of a pixel perfect design, then knowing exactly what the rounded radius will give you for free to the pixel level is perfect.

Right.

And you can trade off for more expensive fancy stuff if you want. You have the information to make the right decision about that choice now.

Right. So, there’s this idea of progressive enhancement. That’s something that frontend developers like to talk about. And what’s really frustrating is when, and not everybody understands the limitation of the environment of the web, [chuckles] when people don’t understand that okay, that particular feature only works in these browsers. And so, if you need to support something like IE7, IE6 [laughs] whatever (hopefully nobody’s having to do that anymore), your rounded corners are not going to work. And so, it’s going to look like this. And I think it’s a lot easier to get, or would be a lot easier to get designers on board with this idea if they knew and were more comfortable with what you can actually accomplish ,like you’re saying. Because that’s, honestly that’s the way you should design for the web, with this idea that you should have everything looking exactly the same in every browser and every device.

You can try to do that, but there’s a huge cost to going about that. Every polyfill is another download, and another source of potential bugs and problems, and another potential source of slowdowns and maintenance later, right? So yeah, you can pretty much make JavaScript do everything that you want. But there’s this huge tradeoff. And so, I think the more fluent designers can be in code and frontend development, then the easier it is for frontend developers to have these kinds of conversations.

We did, what was it Chuck? The other conference that we did up at the ski resort. The Ruby Web?

Was it [inaudible]?

Yeah. It only happened one year.

Yeah. But the Ruby Web Conference back in 2011 or so, or 2010. And BJ Clark spoke at that conference. He’s @RobotDeathSquad on Twitter. He’s freaking awesome. And he just stood up and he talked about this notion, and this was five years ago, and he talked about this notion of trying to make it look the same in all browsers. And he said, just don’t. Have this progressive enhancement and stop worrying about IE6. And I actually wrote this in my journal which is why I still have the quote memorized. He said, “People who run IE6 are used to having half the internet look broken anyway.”

Exactly. [Chuckles] Yeah, the last place that I worked at, that was their approach. So again, taking a pragmatic approach to that. So, even though I am a huge fan of progressive enhancement and think that that’s the more natural way to create websites and web applications is to think about it that way, there are cases where maybe it makes sense to put a little more effort into making the experience the same for other people with crummier browsers, especially when 40% of your business is IE7 or something like that. And when you can do a little bit of extra work… so, the conversation I had a lot was, is the benefit that we bring to the customer worth the tradeoff of the extra time and hassle that we have putting together this code?

So, it always does have to come back to the question of the customer or user, whoever’s using it, whether you think that the benefit is worth the cost. Most of the time I don’t think from a business perspective, you don’t care as much about your IE6, IE7, IE8 customers, and your website can get the job done for them and you don’t have to have all of this massive overhead of maintaining [chuckles] different versions, essentially different versions of your site for different browsers. But yeah, so it’s always a tradeoff. It’s always worth thinking about.

But I think again, the reason… I think that even at this place, if my managers had known more about code and the cost of all of these things, or I guess another thing is if I had been better at communicating that, if frontend developers are better at communicating, then maybe they would favor doing less features for the older browsers more.

Unfortunately there is a non-zero number of people on this call who still have to support IE6, believe it or not.

No, no kidding.

Yeah.

Oh.

Yeah.

Did you see…

I’m so sorry.

Who is it?

David, did you see BJ reply to your tweet?

Oh, I did not.

He said it’s still true up to IE8 now.

Yeah, yeah.

What’s true up to IE8? I missed that.

Oh the, I just tweeted. I’m live tweeting parts for the show and I tweeted the quote about IE6 users seeing half the internet be broken.

And he says it’s still true up through IE8. That’s awesome.

Yeah, totally. IE8 is pretty crummy. IE8’s the next IE6 that we have to…

Yeah.

Move on from. I think their next version is going to auto-update. I think so. I don’t know if that’s totally [inaudible].

Microsoft actually announced three or four weeks ago that they are killing Internet Explorer.

Well, they’re like renaming their browser. I don’t know if they’re rewriting everything. I doubt. That doesn’t sound very Microsoft-y.

Yeah, I don’t know.

Yeah.

But yeah, renaming it, rebranding it, and hopefully thinking about it, giving us auto-updates. Because you know what, the web is actually really exciting now if you subtract Internet Explorer. Everything is up-to-date. Most features roll out pretty much at the same pace. JavaScript is faster. CSS is actually, the Flexbox layout module exists now. So, there’s an actual layout module for CSS, which is amazing because that didn’t even exist unbelievably for years. We just messed around with floats and clears and [chuckles] whatever nonsense we needed to do to get the layouts working. And all of that stuff exists now.

So, it’s like… and animations are making just stunning progress, CSS animations and transitions. And then even in JavaScript they’re doing a lot of work for animation performance and all of that. Yeah, the modern web is moving quickly. But yeah, Internet Explorer is just this thorn in everybody’s side. It’s totally ridiculous that we still have to deal with that.

Alright. Well, before we get to the picks, if people want to pick up your books, I think you have one or two other products. Do you want to just tell us about that real quick?

Oh yeah. So, the book, that’s at SketchingWithCSS.com. And the other thing that I do is, I call them escape plans, I only have one right now. But it’s basically training for advanced developers to get up to speed with new stuff in a couple of days. And the one that I do now is Angular. So, if that’s your thing you can go check that out. That’s, let’s see, training.PlanningForAliens.com/Angular. And my blog is PlanningForAliens.com. I blog about mostly frontend web design stuff there, sometimes business-y stuff. I like talking about that, how I go about doing that.

So picks. I’ve never actually, I don’t really, I’ve never listened to a Ruby Rogues Podcast before.

That’s fine. We’ll do the picks and then you can come…

It’s okay, neither have I.

Blasphemy. [Laughter]

Well, I’m not a Ruby developer.

Okay.

Never was on my radar.

Fine. We forgive you.

I’m a Python developer.

Alright.

Whoa, okay.

Blasphemy again.

Yeah. We’ll have to insert some significant whitespace into the podcast.

Yeah.

That’s his pick. That’s his pick today, is whitespace. [Laughter]

Whitespace. [Laughs]

Alright, David. Do you have some picks for us?

I do, actually. I’m going to pick a book. Addison-Wesley sent me a copy of ‘NoSQL Distilled’ by, I’m going to say this wrong, Pramod J. Sadalage and Martin Fowler. And I just want everybody that thinks they know what NoSQL is, just get this book and just read the first three chapters. I don’t care if you finish the book. Just read the first three chapters, because they tell you what NoSQL is and what NoSQL isn’t. They explain why it’s an unfortunate name. They explain why all of the things that you think are great about NoSQL like you don’t have to have a schema, you don’t have to have migrations, you don’t have to have data consistency, all of those are false. Those are myths, absolutely not true.

And all of the reasons that you hate on NoSQL, like it being inconsistent or it not being controllable or it not being fast or whatever, if you’re cutting across the grain or whatever, also false. It’s all about how you use it and what the tradeoffs are. They get into, in the first couple of chapters, they just explain. The first chapter is just what they are and what the myths are. And then the second, chapters two and three talk about key-value stores, column stores, vertical data stores, graph databases, and that sort of thing, and how they work, what they’re better at. Like, why a document database is actually better or what a document database is better at than a key-value store, even though conceptually they’re the same thing. So, that’s my first pick, is ‘NoSQL Distilled’

My next two picks are a little bit more playful. The first one is RoT.js, which is the Roguelike toolkit for JavaScript. So, this is a toolkit that you can use to build basically Rogue-like games that will run in your browser. And it’s completely open source. And you can basically go after the Amulet of Yendor in your browser. And then it’s a toolkit that you can then write your own tweaks and hacks on top of the Roguelike genre. And so, very, very cool bit of retro gaming that you can get in your browser.

My last pick is a new game. I have picked in the past the game Towns. If you can imagine Towns being set in the distant future, you end up with a game called The Spatials. And The Spatials is freaking awesome. You spend half your time playing SimCity setting up a starbase on an asteroid that visitors can come to. And you keep them happy and they bring in money. And the other half is you set up, you build up your officers so that you can have away teams that go down to planets and do missions. And so, there’s an RPG element where you have skills and abilities. Every away team has to have a scientist and has to have a doctor and has to have that sort of thing. And like Star Trek, you beam down and basically violate the Prime Directive left and right. And it’s awesome.

And it’s almost a casual game. It’s easy to pick up and put down. It’s easy to start and stop. And it’s also very, very, very addicting. So, be ready for that. You might want to pick it up on a Friday because I ended up playing it all weekend last weekend. And my wife was mad at me by the end of the weekend. But the game was freaking awesome. So, I’ve had it for about seven days and I’ve logged 82 hours in the game. So yeah, I was in trouble.

So, those are my picks.

Very nice. Saron, what are your picks?

Sure. I have one. I don’t know if you guys have seen TheUserIsDrunk.com.

Uh-uh.

Yes, awesome! Okay.

[Laughs] Oh no.

[Chuckles] I’ve seen it.

[Chuckles] I was worried that you already knew what this was. So, it’s actually a really good idea. And it’s an idea that I’ve had in a different format before. And I’m saying this to scare you before I tell you what the idea really is. So, the concept behind it is that your website should be so simple and so well-designed which kind of fits with the theme of today’s podcast, that even a drunk person should use it. And so, this guy who’s a UX professional and full stack developer, he will if you pay him, get drunk and use your website.

[Laughs] Wow!

[Chuckles] Yeah. And he’ll give you notes and feedback on what his experience was like. And the difference between him and I think someone off the street doing it is he actually knows what he’s talking about when he’s sober. So, what he says in his feedback is actually valuable and based on experience in his own work and stuff. But yeah, I thought it was a really cool idea. And actually, have you guys heard of Drunk Kitchen?

No.

No, but it makes me think it’s got to involve a lot of sliced off fingers.

[Laughs] I actually don’t know. But I would guess that, too. So, Drunk Kitchen is, that’s going to be my second pick now. Drunk Kitchen is this woman whose name I can’t remember. And she basically gets drunk and cooks. And it’s just a video in YouTube of her trying to cook while she’s drunk. And it’s hilarious. She falls on the floor and just slurs her words. It’s really, really funny. Not that… you know, alcoholism is not good and drink responsibly and all that stuff. But within that context, they both seem awesome and very entertaining.

So yeah, definitely check out The UserIsDrunk.com and take a look at it. If you’re interested in seeing how drunk people will use your site, there is a service out there for you.

You know how that business meeting went, right? It’s like, you know what I really like doing, is getting drunk. [Laughter]

I wish I had a business model where I’d get paid to get drunk. [Laughter]

What’s funny is it started with him charging $100. And now he charges $500 because apparently he’s in demand at this point.

That’s awesome.

So, there’s a market out there for people looking for drunk people using your site.

He’s got to get to $80,000 before he can get a new liver. [Laughter]

Yeah, he’s got a ways to go.

Price yourself accordingly to your capital assets.

Very cool. I’ve got a few picks that I want to share. I’ve been reading The Reckoners series by Brandon Sanderson. And I’ve really been enjoying those. They’re kind of, I’m not sure if they’re like, it’s like a sci-fi but people have super powers. I’m sure that there’s a science element to it because they’re trying to figure out why people have superpowers and how to stop them. And they kill some of them that are called, they call them Epics. Anyway, really, really interesting series and I’ve really been enjoying that. So, I’m going to pick those books.

I want to have a technical pick but I can’t think of anything right now. I’m usually a little more prepared but I was rebuilding a transmission with my father-in-law yesterday and I just didn’t get time. So, I will hand the microphone over to Sean. Sean, what are your picks?

Okay, so that Spatials game looks awesome. I’m totally going to waste [the weekend] playing that.

[Chuckles] Yup, sorry.

That’s awesome. That’s okay. [Chuckles] That’s awesome. Okay, so I run a very small product company and I have a lot of friends that do the same thing. So, I wanted to mention a couple of their small little things that they do that I think are pretty awesome.

One was, actually at the beginning Chuck, you mentioned so I go from the designer to programmer direction. What about from programmer to designer? And my friend Jarrod Drysdale does that very thing with his book called ‘Bootstrapping Design’ which I think is an awesome read for developers that want to just get up to speed on just enough about design so that they can become more fluent in that, in design language. So, that’s one thing.

There’s another one. There’s no way that you guys don’t know about Jim Gay. Do you guys know him?

Jim who? I’m just kidding.

Yeah, okay.

He was a regular on the Freelancers’ Show for a while.

Yeah.

Okay, alright. So, then you guys know about his new DSL book which he’s just finishing up. That’s called ‘The Ruby DSL Handbook’. So, that’s a new thing that he’s doing. He’s got another one called ‘Clean Ruby’.

Then my friend Ryan Castillo wrote a book called ‘7 Recurring Revenue Recipes’. That’s at RyanCastillo.org. It’s not done yet. It’s still a work in progress. But I’ve been talking with him about it. And I’m just going out and doing consulting myself, too. And there are some really awesome little nuggets in here for people building their own consulting businesses.

Okay, and then this one you guys are all going to love if you ever do anything with Heroku and SSL. My friend Michael Buckbee has a company called ExpeditedSSL which essentially equals you click a button and he installs your certificate for you in your Heroku instance. And it automatically renews and everything. So, none of the hassle with installing your SSL certificates.

Nice.

Yeah. That’s a pretty awesome tool.

The Japanese Art of Decluttering and Organizing’ by Marie Kondo. And it is actually life-changing. I am currently sitting in a completely decluttered basement right now, which is, I just did it yesterday. It’s blowing my mind. It’s totally awesome. So, if your life is filled with clutter, I highly recommend this book. She has everything that you could think of, a reason for you to keep something, she has an awesome reason for you not to. And it’s usually deeply philosophical and challenges you’re thinking about the stuff that you keep and have in your life. So, that book is totally worth checking out. Alright, those are my picks.

Awesome, very cool. We’re going to have Jim Gay on the show on June 2nd. We already have him scheduled.

Oh, that’s awesome.

I just thought I’d put that out there. I don’t think we have any other announcements. So, we’ll go ahead and wrap up the show. Thank you for coming, Sean.

Oh, thank you for having me. Great conversation.