Stephen got started in 1995 and his first website was build using Server Side Image Maps. Want to see it? Unfortunately he isn't able to locate the site to share with us, but let your imagination run wild.
Since then he's built a web design company called Cinnamon which he ran for 10 years before deciding to leave his own company and go out as an individual contractor.
We talk about writing a book, the challenges, and the beauty of reading a real physical book over using a kindle.
Responsive Design Workflow
Start out with readable structured content. If you start from here then at the very least people will have the content to read.
When people jump into responsive design start thinking about designing at each breakpoint. Sometimes they start with a framework as well so now you have to learn the concepts of responsive design as well as a Framework. What is worse is often these frameworks were born from people solving their own problems and sometimes you just need to roll your own framework.
The good thing about frameworks is that you can quickly mock up layouts that are responsive and you can show your clients exactly what you mean.
- Susy is something which you can use to define your layout without having to update your markup.
- Zen Grids: Place a class into our HTML that matches a certain naming convention and the element gets laid out in our grid. Instead of dealing with a plethora of CSS properties, we dealt with class names. Simplification, FTW.
- GridSet allows you to create your own grids that aren't just based on 12 columns, but instead you can roll your own.
Mobile first design
Starting from mobile, or a single tube of content, can mean that you lose sight of what the desktop experience could become. Stephen recommends putting the desktop design out of your mind when starting off and focus on the mobile task because at that point the desktop just doesn't matter. When the project requires more desktop focus then sketching out the different layouts on paper before starting with mobile layout can help cover off any issues that might arise.
If you're given a mockup from a designer with only a mobile and desktop layout then do exactly that. Build the mobile version and don't switch that layout until it reaches the desktop proportions (only one media query).
Introduce margins to keep your line lengths at a readable length. The designer will see what is wrong and help fix their broken design.
When you show a client the design on a device, or a suite of different devices then they start to get used to them looking different on each device.
Show your clients the website on some really old devices so they get a real understanding how different the content can look. This could be as simple as showing the lack of support for web fonts.
It's about how you present it to the client. It's not "This is our website, but it looks a little different on these, but instead this is our website and look at all the devices it can work on.
Using ImageMagick allows you to change whole folders of images and change them all from JPG's to PNG in 3 seconds. Photoshp wouldn't have even loaded the title screen in that time.
- Set your base font size to 100% and let the device determine the most appropriate size
- There are no general rules for this. It's based on your content, typeface, color, multiple typefaces, many or a few images...
- Use a tool like Typecast to set your type, experiment with different typefaces and real content.
Read the full transcript
Justin Avery: Hey everyone and welcome to another Responsive Design weekly podcast. This is episode 17. My name is Justin Avery, I'm your host and the curator of Responsive Design weekly newsletter. This week our sponsor is by a fantastic book, it's called Responsive Design Workflow. This piece of literary genius takes us back to the bare bones of a basic site like the actual content and it teaches us about how to build up a site from the content out. A mobile first approach to responsive design, talking about starting with gray boxes and building things out to a more a complex design. It's a really great book. You can go and check it out at responsivedesignworkflow.com. All of the code is on GitHub as well and you can actually purchase it through Peach Pit Press. There's a link on the website. You can either buy the hard copy book or the e-book bundle.
I've read it twice and gone through and implemented things. I pick something up new each time I read it. So I highly recommend going out and purchasing that book. It's very good, responsivedesignworkflow.com. This week is also a special week because we have a special guest on, who is the author of Responsive Design Workflow, Mr. Steven Hay. How are you Steven?
Stephen Hay: I'm fine, thanks for having me. That was a great introduction and sounded really professional.
Justin Avery: You can put that on your website, you can use that as a sound clip. You can use that for anything.
Stephen Hay: Sounds good. Justin Avery Clip Sounds, right?
Justin Avery: .com. That's exactly it. So welcome along. If there's people out there who haven't been to a conference in the last 3 or 4 years or haven't been reading the web or following twitter, or looking at things [00:02:00] responsive and they may not have come across your name. Do you want to tell us a little bit about yourself? How you got into the industry, what you've been doing, and what you're doing these days?
Stephen Hay: Sure. I was born-
Justin Avery: A long time ago.
Stephen Hay: Actually, I studied as a designer, so a graphic designer. I used to work in print. I worked my way up from just doing layout stuff to eventually doing [inaudible 00:02:39] and I did mostly corporate identity and packaging, like consumer packaging. Then I started doing websites in 1995, tried to learn it. I thought it was interesting just to make my own stuff. My own portfolio was like the first thing I ever made with server side image maps believe it or not.
Justin Avery: Is it still online?
Stephen Hay: Oh, no. I can't even find it actually which is unfortunate. I don't even know if I could get it working because the technology is different. I'm sure someone could help me out with that. I have to find it first. I kind of know what it looked like. Sorry I can't show you that. I started in 95 and started playing around at the agency. We started doing a couple of websites and it was very expensive to make those things back then. I started playing around with CSS as soon as you could. Eventually I did more and more web stuff [00:04:00] and I liked it so much that I decided to just leave the print design thing and just do web stuff.
So I joined a company with a couple of other people and about 2 years later, that was in 2002, we started a company called Cinnamon. I guess the whole idea is we thought that [inaudible 00:04:28] and accessibility were two things that go hand in hand. We did [inaudible 00:04:36] compliant websites and we discovered that it wasn't too much extra effort to make them completely accessible as well. And that it's possible to make accessible websites that look good. Back then, accessible websites were almost just plain text.
We got a little bit of notoriety with that and that's how I first started reading about Zeldman. I think he posted something about some stuff that we did. I had read Zeldman's blog from 98, 99 I think and it was totally in to the whole standards thing. I thought that seems like the logical approach. Starting simple and from the basics and working your way up. You can even see that in the book. That's just kind of a philosophy I guess, of mine. So I had this company for 10 years, front end design and development company and 4 years ago I decided I was doing more management than the stuff I really liked to do. That's when I started my own independent consultancy and left my own company.
Justin Avery: Oh wow.
Stephen Hay: Now I get to, I'm not doing as much design, but I'm helping [00:06:00] design teams and I'm helping clients who want to approach design responsively and they're just not quite sure how to do it. So they want an approach- I do some design and I love to code so I do some code when I can. Yeah. That's pretty much it. So I do a lot of different types of projects. I also do a lot more speaking and writing, like the book. I have to say that after you're done writing a book- I don't know how a lot of authors are, but as a first time author-
Someone once told me, the best part about writing a book is being done. I concur with that. There might be a new one coming but probably not anytime very soon.
Justin Avery: It didn't scare you away from writing in general did it? Speaking with Jeremy Keith a few episodes ago and he was talking about the great thing people write to write lots, because even if someone else has written about it, you provide a different perspective. You didn't give up writing completely, just books.
Stephen Hay: Oh no. I have a great respect for people who write all the time. I think it's one of the most sacred of arts. It's certainly one of the art forms that's stayed around. That's pretty much how we know everything about every single period that we know about, is writing. It's incredibly hard to do and I [00:08:00] think people who do it well, they deserve all the money and fame they get.
Justin Avery: It's a shame publishing isn't doing as well these days thanks to the industry we're in. But at least people are writing on different mediums now. Not losing the art of writing, just the [inaudible 00:08:21] side of things.
Stephen Hay: I like having a book and holding it in my hands. I have a Kindle Fire and I love it. It's probably my favorite device. But there's something about reading a book on a device like that that's just- it's more like eating just to get food into your body, as opposed to going somewhere and really enjoying the meal.
Justin Avery: That's a good analogy, I like that.
Stephen Hay: I do enjoy the writing, I enjoy what they're talking about. It's mostly just information, or if it happens to be fiction then it's a great story, and stories happen in your head. But there's something about a book and the way people choose to type set that book. I enjoy that.
Justin Avery: I have your responsive design work flow book as an e-book. But I feel I've cheated you and I need to go and buy the physical copy to see how well it's been type set. Were you designed in the art direction of the book because your background was print and graphic design?
Stephen Hay: Yeah. They did offer me the opportunity to do that and I declined because having worked in print design for many years, I know there's a huge difference between book design and the type of work I did. While I probably could do it, I think [00:10:00] it would have taken me a longer time. I'm not sure it would've been the type of thing that would fit with what a publisher would want to do. Pierson is a big publisher. There are people who know what types of colors you need to use and what things will sell and what type of things will be appropriate in a university type situation. I didn't feel inclined to write the book and think about that kind of stuff. I figured there are people there, the publisher, who do this kind of thing every day. And let's just leave it to them.
I got to see what they were doing and I had a veto power but I'm not one- I was never one of those art directors who would go and tell people to move that a little bit to the left and change that and change this. That's designing through someone else and I don't think that's the function of an art director and it's certainly not my place as an author to tell people what to do so I just let them do it.
Justin Avery: Very nice. I understand around the print stuff. I picked up a copy- I've got it here with me at the moment, The New Perspectives of Web Design, the Smashing Magazine book number 4. It's got some nice articles, Tim [inaudible 00:11:34]'s in it, Harry Roberts, Matt Markey and-
Stephen Hay: Who are those guys?
Justin Avery: I'm not sure.
Stephen Hay: Who's that last one? Who's Matt?
Justin Avery: Matthew Marcus I think it is. How you pronounce it. It's his birthday today apparently.
Stephen Hay: Oh really. Matt if you ever listen to this, happy birthday.
Justin Avery: And how do you finish [inaudible 00:11:58]? [00:12:00]
It's a whopping 495 pages but it's really beautiful. It's got a hard back, it's textured, the illustrations are beautiful. But to carry on the [inaudible 00:12:13] back and forth from work is not fun.
Stephen Hay: Oh is it heavy?
Justin Avery: It's heavy, it's bulky, it doesn't fit in your bag, it's kind of hard to flip pages. But I do like it. There's folds in the bits that I really liked. I've got rabbit ears on pages I'm going to go back and copy the code from. It reminds me a little bit of- you know Antonio [inaudible 00:12:40] the guy from Barcelona who designed all the-
Stephen Hay: Yeah.
Justin Avery: I bought a book, a biography on him, when I was traveling through Europe at one point. It was a beautiful, really nice book in terms of the story, to learn all the things he did. But apparently he used to get in trouble because he didn't like carrying a full book around. He would tear chapters out of the book and just carry those pages around with him to read and then just stuff them back in the book afterwards and rip out the next section. Then he would return the book to the person he had borrowed it from and the book's just in tatters. I kind of feel like doing that with this Smashing Magazine Book.
Stephen Hay: Yeah. I know a lot of people who do stuff like that, they circle things. My dad used to do that. He'd read something and he'd circle things, highlight them, write notes in the margins and stuff like that. That always intrigued me but I always felt like I can't deface this book. That's the cool thing about something like a Kindle or whatever, any kind of e-reader device, is that you can highlight things and write notes and stuff like that [00:14:00].
Justin Avery: And it's electronic right? Technically you should be able to access that again even if you don't have your Kindle. If you've got that residing on a 3rd Party somewhere on the interwebs.
Stephen Hay: Right. And you can look at websites on it.
Justin Avery: But they weren't looking at those unless they've been made well.
Stephen Hay: Which is I guess what we're talking about in the series. But if they've been made well, that's correct. And the Kindle is a great way to look at websites, by the way. There are a lot of nice devices to use to test websites.
Justin Avery: I inherited my wife's Kindle because she's a book fiend as well. She loves the feel of a book and just can't get the electronic stuff going. So I've now got that as a test suite that I use to check how websites are rendering. Which is nice. It's good to see how it comes across in monochrome and on the print ink paper.
Stephen Hay: Oh okay. I've got a Kindle Fire which is-
Justin Avery: Oh that's the flash one isn't it? The color and everything.
Stephen Hay: Yeah it's nice color screen and it's got a decent browser on it.
Justin Avery: I'm going back old school. The original-
Stephen Hay: The old school ones, those are pretty cool to look at as well.
Justin Avery: Yeah, but if you build it right, like your book points out, if you follow the steps of starting with the content first, then it should render nicely on devices like that.
Stephen Hay: Yeah, at least readable. If you start out with just readable structured content then that should be readable on any device that can read HTML, so I think that's step 1 all the time. Which kind of unfortunate. We had had a conversation, you and I, [00:16:00] about how people get into responsive design and then they start thinking in terms of break points and designing at each break point and they look for solutions that other people have come up for their own projects, at least frameworks and things. So you get all this baggage. It's not- you don't- now you're not only learning about responsive design, but you're also learning about a framework. Because if something goes wrong then you have to know the framework to be able to fix it. What happens if you decide I don't like this framework, I want a different one, even though you have to start the whole process over again.
Not realizing that these frameworks were born out of people solving their own problems. Sometimes you need to make your own framework, not because nothing else out there is good, but just because it's good to learn.
Justin Avery: Yeah.
Stephen Hay: That's one of the big problems nowadays.
Justin Avery: Do you see any benefits around the frameworks- the popular ones are things like BootStrap and [inaudible 00:17:21] Foundation, they're probably the two biggest that made their names for themselves. Do you see any benefit in those in a responsive design workflow?
Stephen Hay: Oh sure. If you're really good to you and they're just a tool to you and you know them so well that you can manipulate the result to the way you want it to be and that fits within your team. Then I suppose they're just fine. I have, in a version, 2 class attribute base frameworks. Now I think both of those frameworks have [00:18:00] [inaudible 00:18:01] and less alternatives, or options. You don't have to use all those class attributes you can just do everything with a pre-processor and then have clean markup.
If you do all that I think they're fine. I don't prefer that but that's mostly because of the reason I just mentioned. People put this obstruction layer on top and they just complicate things for themselves without knowing the basics. If you do know the basics and you know these frameworks and they work well for you, just great. I think [inaudible 00:18:40] Foundation, the [inaudible 00:18:43] have done it really well. I don't know how they do it now but they promoted [inaudible 00:18:49] Foundation as more of a prototyping framework so you can quickly mock things up and the mock ups would be responsive. Which is great.
If you did all that from scratch, it takes awhile because you're basically doing a static website. Like I discuss in the book, because I think it's important that people hear about the basics first. But once you get past that point something like Foundation is fantastic for doing quick mock ups and you can do it pretty quickly that kind of work. Yeah, I think they definitely have their place.
I guess a hammer can help build things and help break things, it just depends on the person wielding it.
Justin Avery: Yeah that's true. That's a good point there. Have you seen [inaudible 00:19:47] the Inuit CSS. Have you ever tried that or seen that all?
Stephen Hay: I've seen it but I haven't ever tried it.
Justin Avery: It's supposed to be like that, like you were saying, how [inaudible 00:19:58] [00:20:00] and BootStrap have gone to less and [inaudible 00:20:04] way to try to clean up the mark up. I think that Inuit CSS is more around that. It provides you the ability to do columns and stuff but you have to define them all yourself. If gives you a couple of short cuts to accomplish a few things. I'm the same I haven't actually tried it so I'm not going to pretend to explain all of it how it works.
Stephen Hay: Something I like to use for layout, which I think is really easy to use because it's so configurable is Suzy for [inaudible 00:20:43]. Do you know Suzy?
Justin Avery: I've seen that. Again, it's another one which is sort of on the list of things to try out but waiting for the opportunity and project to do it. What's the theory behind Suzy?
Stephen Hay: The whole idea is that you can create this whole layout without having to touch the mark up basically. I like the way it's set up. You define what your grid is basically. It doesn't get as complex as something like GridSet. Do you know GridSet?
Justin Avery: Yeah.
Stephen Hay: Mark Bolten and his team had done that. Grid Set is pretty cool because you can create grids that aren't just 12 columns or 8 columns or 16 columns, you can-
Justin Avery: It's based off some well known print grids right? They've got a whole bunch of-
Stephen Hay: Yeah and you can do your own. So you can take one as a base and go from that. Suzy gives you the power to do that but you pretty much end up having to nest equal columns. You have a base of equal grid units which are [00:22:00] columns and you can keep them smaller and you can determine how large certain elements would be on this grid. I think smartly done. I tend to like it. Not something that I use or need to use for every single project. But if I needed some kind of grid system, which basically, a grid system like that helps you do- it makes the math a bit easier. You can say, this thing should be 4 columns wide and it should be put into the 2nd column without having to come up with all the math. It doesn't affect your mark up at all which is really interesting.
There are some other ones like Zen Grids, which John Albon Wilkens has done. His approach is really good as well, so it's almost like a toss up. The differences are pretty small. I think the people who are really into these things and have to use them for their projects, they'll do the research and figure out which one's better for them, but both are really good.
Justin Avery: I kind of get stuck sometimes. I really liked that Grid Set app. I didn't come from a graphic design or any design background. So I struggle with layouts that look nice. I don't know, what do you call it, the ones that feel right. Like, this is well thought out, this layout, these bits match up here. I can write a hell of a [inaudible 00:23:48] thing for the HTML but when it comes to the spacing and having the design side of things I fall down a bit. [00:24:00] I like things like Grid Set app but I don't like the classes it gets you to use every time you want to put something within the grid.
What's the type setting one?
Stephen Hay: Type-Cast.
Justin Avery: I love Type-Cast as well because that's the same kind of thing for getting your type sizes right and getting the page looking beautiful. I think it's a terrific tool.
Stephen Hay: I think you can use both. Something like Grid Set is great to come up with a grid. I definitely- I just ignored the code that Grid Set put out. What I ended up doing is just looking at the grid itself. So it was like an environment to create a grid and once you knew what these proportions were then you take the percentages or convert pixels to percentages in the time that I used it. Then just go ahead and do your own CSS based on that. Just ignore the code that the app puts out. That's one of the things that I think is important about learning the basics first is you don't have to rely on everything a tool does. But the stuff the tool does really well. Like Grid Set is really great at creating a grid. It's not necessarily something you have to use it's code.
I think Grid Set is great for that kind of thing- when I did print design, we always did type specimens. We would spend a bunch of our time at the very beginning just exploring type faces and weights and different types together. We would just print all these things out. Type-Cast kind of allows you to do that but on your screen and I wouldn't, again, use [00:26:00] Type-Cast to create any kind of code I'd use in an actual site but it's to figure out what I want to do. You see what I mean?
Justin Avery: Yeah.
Stephen Hay: I don't use Type-Cast regularly. But when I've played with it, that's what I've used it for, is type specimens really. If you go to the Type-Cast site, they have video and the video is on the home page and it shows you what you can do with it. It's pretty much what I'm talking about with those type specimens. You're taking representative content and playing with the type and how these things fit together and how close the headings are to the paragraphs and things like that. One of the things we tend to do, especially designers who have a technology background. We latch on to this whole idea of grids. Grids have been around for a long time but when I did print design, grids were this underlying thing that no one ever talked about but everyone kind of used. It's like the coat hanger.
Now everyone's like "grids, grids." What kind of grid did you use for this and that and sometimes you don't need a grid. There's an implicit grid in anything you make. It's a grid that just comes into existence because of what you've made. But we don't necessarily always have to start with a fixed grid and put stuff on it. Sometimes you can use the grid and break your own rules by breaking out of the grid. That's just basic graphic design stuff.
Justin Avery: For the non-graphic designers that are listening, and me, when you're approaching [00:28:00] a design or approaching a responsive site based on the work flow that you've written about, you sort of go, it's the content first right. You approach your content, you get all the content bits in there, so you're working with real content. So that's a tube of content, there's no grid there. Then you move into major breakpoints as you go through. When you're putting that content in that tube, think about what the giant desktop is going to look like or the medium size in terms of how you're going to proportionalize things or do you do it as you go and deal with the problem as you get to bigger break points?
Stephen Hay: It does depend on the project. Sometimes I try to force myself not to think about what the desktop will look like because it's not important until you get there. You're going to get there eventually but it's not always important to have that all set in stone before you get started. But often times I'll have an idea in my head, a rough idea of what it would be and I'll usually have some sketches of what I think it might be. And those are just hypothesis really that I'll get to test once I get to the desktop. Most of the time nowadays, it's other designers that are doing that and I'm just helping out with that whole process. That's the big thing that's hard for people to get used to working because they're used to thinking about let me get this desktop thing down. They feel like that's the more complete version of the website. We know what we all think about that. [00:30:00]
I don't usually have a very clear view about what it is. Sometimes when I'm helping more development teams then designers have already thought about it. So they have photoshop comps of the desktop and of the mobile version and the tablet version. They usually have about 3 mock up variations. Or even worse, they'll have very set mock ups for desktops and a linear smart phone type thing and then just leave the rest to the developers-
Justin Avery: And nothing in between.
Stephen Hay: Nothing in between. You guys figure that stuff out. I'm like, oh man, that's the place you should be as a designer, is in between the break points.
Justin Avery: At the end of this as well I'll ask you to do the same. But I'll ask you this, Jeremy has asked a question for our next speaker, for our next guest, which is yourself. So I'll ask you to ask a question for our next guest as well. I'll ask you that just after this one.
Stephen Hay: Did he know that I was the next speaker?
Justin Avery: I'm not going to say whether or not I let that out or not.
Stephen Hay: If he did I know he's going to make it really hard for me.
Justin Avery: When you do have that where a designer give you those 2, like a 1600 pixel and a 320 pixel and the developers have to make that stuff up in between. What would you suggest is the best way to approach that?
Stephen Hay: That's easy.
Justin Avery: Have you seen that?
Stephen Hay: Yeah.
Justin Avery: That's not the question he asked by the way, that's mine, that's why it's an easy one.
Stephen Hay: I would just say, make that smart phone [00:32:00], the mobile first version first, and allow that to expand not worrying about what it does. Basically your text is just going to get really wide right. You're going to have this really wide text column. Then suddenly when it gets to the desktop break point, do the desktop implementation and leave it as it is. It will look terrible on a lot of tablets and stuff like that. Then send it to them, send it back to the designer. Say, you might have missed something here.
And maybe not. You can actually go pretty far by having a text column just by increasing the margins on either side. You can go quite far. You can almost go to, on some devices you might get to almost landscape before it has to change to something else.
Justin Avery: That's a good idea. It raises another question about type across major break points that I wanted to ask, which just occurred to me then, because I want to know the answer to this one. Do you want this question or do you want Jeremy's? Jeremy's question was, and this is the only question that I have.
How do you handle clients that expect to see high fidelity comps on a responsive website? Do you try to give them what they want or do you try to change their expectations?
Stephen Hay: By the time they become my client they know how I work because someone hired me. In the first meeting that we have, the interview I have [00:34:00] before they become my client, before they hire me, during that session or maybe more than one session on some occasions, I'll talk about that whole process. It's also easier for me to say, I wrote a book about not doing it that way so it's going to be hypocritical of me to come in and give you photoshop comps. I don't even own photoshop.
I can understand where they're coming from. I understand usually why they want something like that. But I try to explain to them the benefits of doing an alternative approach which allows them to be more involved in the whole design process and be more in touch with it as well. They're not deciding things as a designer would but they're in touch with the project so much that by the time you get to a full blown comp, which I recommend is done in the browser, to them, that's the most logical outcome. They're not surprised by what you've built. The whole photoshop comp thing. That stems from the creative pitch, where you would go in, unpaid, pitch your design and you'd just show a full blown design which basically was hit or miss if it was relevant to the project or not. Because you don't know enough about the client at that point, that's usually in the pre-sales process.
It's kind of this idea what we have to show the client what they're going to get before they get it and I think that clients could be convinced to start with content, which they're going to need anyway and be so involved [00:36:00] in this design process. That doesn't mean they're in meetings everyday with the designers but they're just really in touch. The communication is really important. If you do that well and you explain it well, I find that most clients can deal with that. If they can't then I tell them during that first meeting, if you want comps from me they're not going to be photoshop comps, they're not going to be static comps. I'm not going to make 3 different, or 4 different breakpoints and not let you get a feel for what's happening in between.
Interaction design and visual design, they're intertwined, I don't even think those 2 things should be separate job descriptions really. If you do have separate people doing that they should be working together, side by side. I think it's weird that interaction designers make wire frames and those describe interaction, when you have the opportunity with this medium to create a design that you can not only do usable and accessibility testing on, even though it's not a full blown site, but just the design, you can also test and improve all your interactions, even before the site gets built. It's hard to explain to the client.
We show them a photoshop comp and say, when you hover above this thing it's going to do that but you can't hover on mobile so what's going to happen is you're going to touch it there and it will flip around and it will do this thing and they're looking at you like you have 2 heads. Why not just show them?
Justin Avery: Give them a mobile and say here you go, touch-
Stephen Hay: Let them use their own. Go in with several devices and say, go to this address and look at it on your own device. That takes a little bit of [00:38:00] courage to do that because if you haven't tested it on their device.
Justin Avery: You have faith in what you've built.
Stephen Hay: Yeah and think about the fact that- I always say that photoshop is the best way to show a client how their site will never work. If you have a bunch of different devices and the client sees this design in all these different devices. The first thing they notice is that it's different. It's the same, but it's different on all these devices and they get used to that idea from that moment on. I like to wire frame in the browser as well, so they're already used to the fact that these things are going to be different. Not only that the layout is different, the type face is different often times. If you're not intent on embedding fonts all across the board for performance reasons, some of the type might look different.
Justin Avery: Do you only go that far? When you're showing the designs and stuff, cut that out of mobile and not load in-
Stephen Hay: Not on designs. I usually don't worry about that kind of thing.
Justin Avery: It's a great idea actually. I think sharing, this is what happens when there's a poor connection, you can still see the connection but it's in Arial or Times.
Stephen Hay: You can usually cover that by using a device that has shotty support for something. If you want to show how it will deviate. What does this look like in black and white? Show it on your old Kindle. The difference in type size as well. Get a couple of [inaudible 00:39:55] devices that will screw up most websites and show it on there [00:40:00]. Just so they can get an idea. It's not showing them- it's also the way you present these things. It's not, this is our website but it looks a little bit different on these.
It's like, this is our website and it works on all these things. It's the way you present that to the client. It's a benefit to have a website that's built responsively, in a proper way and it works on all these devices and doesn't look the same. But it's still readable, it's still usable, that's a benefit. That basically means that more people will be able to see this thing that you're building. Any client that's worth anything at all will know that that's a benefit. And they'll appreciate the fact that they can see this design on actual devices. There are other things to worry about at that point like impressing upon the client that you're not actually done. This is just the design.
That's one of the dangers.
Justin Avery: [inaudible 00:41:10] go live with it and stuff.
Stephen Hay: I'm sorry.
Justin Avery: They sit back and say, "yes this is excellent, we'll have that tomorrow."
Stephen Hay: Yeah. That's the danger. It looks done. If you do it- some teams that use a similar approach to this responsive workflow thing that I do, they'll do that whole process but they're making sure that the code is production quality as well while they do it. So they end up having the front end templates done.
Justin Avery: Yeah then you just put it to the-
Stephen Hay: Then they just start hooking that into their back end, yeah. If you have- if you're a designer who is a developer as well. Or you have designers and developers [00:42:00] working on these comps together, then it shortens the process a bit. It's almost impossible when you follow that iterative workflow that I discuss in the book. It's almost impossible that the client will say, I totally hate it you have to go all the way back to square one. It's just not possible because content has been done, they've seen wire frames about this thing, they've looked at how the content relates to one another. It'll be stuff like, I'm not sure that this element has enough emphasis. That type of thing.
Justin Avery: Real feedback that you can use.
Stephen Hay: Yeah. And if you're doing what Dan Mall talks about, he does these element collages and stuff. You have style tiles and all these branches off of [inaudible 00:42:57]. If you show that kind of thing if you're not show what direction the client wants to go. Then that information in addition to all the other information you have, gives you enough to be able to move on to a full blown comp in the browser.
Justin Avery: I'm sure Jeremy will be very happy with that actually. We were talking earlier about advanced techniques before we kicked off with this. In the book, although you go from quite basic- it goes from quite basic like collecting the content and doing the gray boxing and then building it out from that. You do go into some, what some people would consider some more advanced topics. You talk about using a system called Dexy? Also using Phantom and Casper JS on the command line [00:44:00] for doing screen grabs and stuff.
Stephen Hay: Yeah.
Justin Avery: Is that where you- would you consider those things more advanced techniques for people building up these sites?
Stephen Hay: I was trying to scare people into a different career choice. I don't know if they're advanced techniques. I think they might feel advanced to a graphic designer who feels scared of things like the command line, which I can understand. That's basically a lack of understanding about what the command line is and does. It has nothing to do with the actual, factual reality of the command line, you know what I mean? It's just people's perception. I don't know if it's advanced, anyone who uses the command line interface that a lot of things are simpler. For example, there's a tool- a suite of tools called image magic. There are all these command line tools in this package that allow you to manipulate images. With one line on the command line, you can take an entire folder of the images and let's say you have 50 images and you can change them all from .jpeg to .png in 3 seconds.
I don't even know, photoshop, if I were to open photoshop, I don't even think that title screen thing that says photoshop, I don't even think that showed up yet by the time all those images have been changed with the image magic.
Justin Avery: And you can do optimizations on those things using- I know image optim- I don't know if that's part of the image magic but doing optimizations on images on the command line, the same kind of one liner [00:46:00].
Stephen Hay: Right. Image Optim has a graphical interface as well. Or at least one, a few. They're not the same thing, but similar in what they do. Image Magic is more multi purpose I guess. The fact that you can script these things and put them all together. A designer wouldn't do that. But a developer could string these things together in a workflow for the designer to help them out. It's just an extra tool. It's not something you need to learn.
In the book, I talk about this process. If I don't actually explain how I use this process, then it's just theory and no practice. I also decided to put the tools in there that I use. I think I have a whole side bar in the book that talks about, these are the tools that I use, just to give you a realistic example of how I do this and how I've don't it on real projects. It doesn't mean you have to use them.
Justin Avery: That side of the book is what makes it a really good book because it is real examples of how you're doing it for clients. It's not, this is the theory I believe it should be done. It's like, this is actually how I do it and this is how you can do it if you want to use the same tools and the same process that I've got.
Stephen Hay: Right. It seems hard but it's kind of a lot of hand holding in there. I think if you're a developer you might even feel insulted. [inaudible 00:47:44] what the hell is this java script.
Justin Avery: There's no code for the first half- or very little code for the first half of the book. I think the developers are just happy to see code by the time they get to the 2nd half. They're like "oh I understand." [00:48:00]
Stephen Hay: I hope so.
Justin Avery: I had a question around- remember we were talking about that concept of getting a desktop design a mobile design and working out what's in the middle. In the book as well, and on stage, you've talked about major break points and minor break points and the difference between the two. There's certain rules you change at particular break points and type is something you are very passionate about and you pay quite a lot of attention to. Are there any rules around the size- any general rules you've found around the type and how it changes, both in size and headings and margins and line links and things between the small screen to the very large screen?
Stephen Hay: Honestly I don't think there are any blanket rules for that kind of thing because there are so many factors at play. The type face, if you have more than one 1 type face, which ones are they and how do they work together? What sizes are you using? What type of content? What language it's in? Are there a lot of images or not many? All these things come into play. What colors things are? I don't think there's a blanket rule.
One thing I try to do is usually, I won't say all the time, but usually, the device manufacturers, the default browsers on devices, they have their font set at a nicely readable size on that device. That doesn't work for every single type face. So if you would say 16 pixels on a desktop browser and I guess 22 pixels on my Kindle Fire [00:50:00] and you get those variations. If you were to set your body type to 100% which would take the default of that browser, then that's what I usually try to do. Depending on the type face you might have to make it a little bit larger, or even a little bit smaller, although I've never had to make it smaller. I know some people, like on mobile, because it's a smaller screen, they make the type smaller. Which is kind of weird.
I would be like, you'd probably need to make it bigger. I think that would be the only thing. Is to see if the default size works well with the type that you've chosen. If it works well, be done with it. That's one of the advantages of not working in photoshop first where you have to make a choice based on how something looks on photoshop as opposed to how something looks on different devices. If you already know what type face you're using, take a bunch of real content, put it into a page, load it up on a bunch of devices and look at the default size.
If it's readable and it looks good you might have to adjust the line height a bit or margins a bit. But looking at it at that point on several real devices might lead you to those decisions because you'll be like, this needs more line height, this needs more margins on either side. That's because you're actually responding to how it looks in the real situation. That's not any less design than doing something in photoshop.
Justin Avery: Yeah. That's the exact reason why you wouldn't use photoshop I suppose. [00:52:00] a very good reason. We've reached towards the end. Before we- earlier when we were chatting you did promise that you had the greatest advanced technique of all for responsive web design that depending on how our chat went you were going to share or hold back forever.
Stephen Hay: The ultimate advanced responsive design technique.
Justin Avery: Yes.
Stephen Hay: You want to hear it?
Justin Avery: If you have time. Are we over time now?
Stephen Hay: It's short.
Justin Avery: Okay.
Stephen Hay: The ultimate responsive design technique. The advanced responsive design technique, is to start off by not using any advanced responsive design technique. That's it. Just start with the basics and go from there. Start with structured content and build your way up. Only at a break point when the design breaks, when the content dictates it. That's it.
Justin Avery: Advanced in it's simplicity.
Stephen Hay: The anti-advanced.
Justin Avery: The anti-advanced. That's awesome Stephen. Thank you very much for your time this afternoon. It's been really cool having a chat. There's a ton more things that I'd like to talk to you about as well but we might save that for another time down the road if you'd be happy to jump back on and have another chat. That'd be awesome.
Stephen Hay: I'd love to.
Justin Avery: Before we go, is there a part from the book. Is there anything else you want to plug or if you've got things coming up, are you speaking anywhere soon, or workshops coming up?
Stephen Hay: The first thing I'll be speaking at next is Artifact Conference in Providence, Rhode Island at the end of September. That's artifactsconf.com. We'll [00:54:00] be doing design day in November in Amsterdam, so the same crew that did CSS day in Amsterdam will be doing that. But that's pretty much it. It's a slow period. Which means I'm doing a lot more client work, which is good and bad.
Justin Avery: Good for the business.
Stephen Hay: Yes.
Justin Avery: But the responsive design workflow book is always there and without plugging it too many times, I highly recommend anyone that's listening go and grab that. It is very cool and you will learn a ton. If you liked what Stephen had to say during this, you'll be even more impressed with the book. And now you have a voice that when you read the book it's like you talking. I always liked that, when you hear the author speak you can read it in their voice instead of your own.
Stephen Hay: I wish I had more of a radio voice.
Justin Avery: It's fine. Face for television then.
Stephen Hay: Okay. You can cut that out right.
Justin Avery: We will. Thanks for coming on Stephen, it was awesome.
Stephen Hay: Thank you for having me.
comments powered by Disqus