On this episode of the Boagworld Show, we look at the current state of responsive design and what the future may hold.
- Responsive Web Design Is
- How to squeeze the most from your images
- Responsive And Fluid Typography
Paul: On this episode of the Boagworld Show, we look at the current state of responsive design and what the future might hold. This season of the podcast is sponsored by Balsamiq and Fullstory.
Hello, and welcome to the Boagworld Show! I'm very confused today because we're sitting in a room with people! I'm not used to people! Human beings! So-
Marcus: Vaguely. Headscape people.[Marcus 00:00:38]
Paul: Well, yeah. They're a special breed.[Paul 00:00:40]
Dan: We're almost human beings.[Dan 00:00:42]
Paul: You don't have the rights of a human being, you're just driven into the ground like cattle.
Dan: Yep, yeah. That sounds about right.
Paul: That's how it is at Headscape.
Dan: That's how it is, yeah.
Marcus: It's so like that. Ed hasn't even got a mic.
Paul: No. Hello, Ed.
Paul: And take the mic back. [crosstalk 00:01:00] So we've got joining us today is Dan Sherman and Ed Merritt, which is really nice to have you both on the show, thank you for joining us.
Ed: You're welcome.
Dan: You're quite welcome.
Paul: You actually volunteered this time rather than being forced into it by our now borderline [crosstalk 00:01:14].
Dan: Sort of half and half.
Paul: Half and half, oh, I see. It was a bit like that, was it? Like I said … They're our slaves.
Dan: Happy to be here.
Paul: You're sporting a very impressive beard these days, Dan. You've gone full kind of hipster, it's awesome.
Dan: I haven't gone full hipster, I just sort of started growing it when I had some time off over Christmas and it's just sort of spiraled out of control from there.
Paul: I like it.
Ed: You did put beard oil in it, [crosstalk 00:01:42].
Dan: I have, yeah, semi-bought beard oil. But that was mainly because my mustache has now got handle bars and I'm quite proud of it.
Paul: Oh, that, totally should be proud of that.
Marcus: I mean, I have beard oil.
Paul: Do you really?
Marcus: Yeah, it was bought for me as a present for Christmas.
Paul: See, have you ever actually used it?
Marcus: Yeah, yeah, yeah. Cause I want it a bit sort of, like, gritty.
Paul: I feel very left out sitting around this table, because everybody's beardy except me.
Dan: I'm not sure how long this is gonna last, I'll be honest with you.
Marcus: Yours is by far the most impressive and should be kept, because you look like a 17th century nobleman.
Paul: Well, I think that's a good look. I think you should definitely be sporting that look.
Marcus: One hundred percent.
Dan: Flattery will get you everywhere.
Marcus: I know.
Paul: See, but my problem is I can never get past the itchy stage.
Dan: Oh, yeah. You power through. [crosstalk 00:02:24]
Ed: Just shave that bit, see, my beard grows down to there. So, just shave that two inches there.
Dan: Two inches there?
Paul: Is that the itchy bit then? Just down here.[crosstalk 00:02:35]
Dan: It's all itchy.
Paul: It's so weird not having beards at the moment. I feel like I need to join in. I'm just so out of date.
Dan: You'd be all salt and pepper like me.
Paul: Yeah, I would be, but it would look stylish I'd like to think.
Marcus: You would look very designer.
Dan: Speaking of style, you are looking very Steve Jobs today.
Paul: I am actually, this is very true. Yes [crosstalk 00:02:58]
Dan: You have the Levi's, the black turtleneck.
Paul: Yeah, actually, now I think about it. I really have overdone it today. It's the combination of the rimless glasses and the turtleneck. Yeah, yeah, okay. [crosstalk 00:03:13] I was being nice to you about your beard!
Dan: That was a compliment [crosstalk 00:03:15]
Marcus: He is an icon actually.
Paul: Do I look like a young Steve Jobs or the one that was about to die?
Dan: You look like an innovator.
Paul: That was very well put, Dan.
Dan: Tact, I'm full of tact.
Paul: Absolutely, seriously impressed by that.
So, just to explain to people because this show is going to quickly spiral out of control otherwise. Just to explain why Dan and Ed are on the show this bit, this week. We are going to be talking about responsive design and Dan is our front end … do you prefer developer, engineer, or coder?
Dan: Oh, good Lord! [crosstalk 00:03:54]
I've adjusted my job role on Twitter about three times in the last month. I think I'm now a UI develop designer.
Paul: Develop designer, I like that.
Dan: I just thought of that. It just fell out of my mouth. [crosstalk 00:04:11]
Paul: When you've got a beard that luxurious these things do just come.
Ed: I'm changing the Headscape website.
Paul: To say?
Ed: Develop designer. We are now all develop designers.
Dan: No, let's not do that.
Paul: What's that make you then Ed?
Ed: I don't know, I'm joining that. That sounds good. [crosstalk 00:04:27] I'll be one of them too.
Dan: Design developer.
Paul: Oh! It's the other way around?
Ed: Yeah [crosstalk 00:04:32]
Paul: Slightly more towards the design side.
You both still code? Well, you definitely code.
Paul: You do still quite a lot.
Ed: Yeah. With a whip.[crosstalk 00:04:42]
Paul: Is it when it's really busy?
Dan: I make him do it.
Ed: I'd rather be designing.
Paul: Well, of course you would. And at the moment is insanely busy, I'm surprised you've got time to sit in this room, really.
Dan: We haven't.
Paul: Okay, well this is your lunch break. [crosstalk 00:04:58]
Dan: I told the guys about a month ago that, it's looking like things might kinda quiet down in a couple of months. I dunno, over the last two weeks I have constantly got interesting leads coming through.
Paul: Well, you need to just stop accepting them. Just say, go away, we don't want your money. Or we'll take the money but we won't deliver anything for it.
Dan: One of them, that I'm speaking to after this, it's about … talk to the guys about it … it's mapping the entire sea bed. [crosstalk 00:05:27] Or the presentation of the mapping of the sea bed [crosstalk 00:05:31]
Paul: You're not sending [Davin 00:05:33] out with his snorkel.[crosstalk 00:05:35]
Ed: That doesn't sound like-
Dan: That's how I'm going to get holiday. I'm going to be part of that project. I'll get the snorkel, I'll get to swim but, also at the same time, I will be mapping the sea bed.
Paul: Yeah, yeah, you don't ever get any real time off.
So, we're gonna be talking about responsive design, that's the plan. And in some ways I almost left this out of this season because I kinda thought, well everybody knows about responsive design. But, when it comes to responsive design, really, the devil's in the detail. It's the little things, isn't it, you have to do that … where it all goes to shit and becomes a lot more complicated. So, we're gonna talk about that a little bit.
Before that, I did want to quickly mention the newsletter cause I keep meaning to mention the newsletter on the show. It's a really good way of keeping up with everything that's going on. Well, not everything that's going …
Marcus: Everything in the whole world?
Paul: Everything in the whole world. I have replaced the BBC News now. News service. No, it's just interesting articles, stuff that I've read, stuff that I've written, stuff that I care about, probably of no interest to anyone but me.
Dan: I subscribe to all.
Paul: Do you? Do you really get mine?
Marcus: I read the top of it.
Paul: I know that you don't read it because every time the stats come out I look at whether you've opened it. No, he hasn't again. [crosstalk 00:06:50]
Marcus: I don't need … I can just scroll down it. [crosstalk 00:06:53] like a modern email client.
Paul: You don't click on it either.
Marcus: I don't need to, it's kinda … I'm getting the synopsis of your thoughts and your feelings. That's enough.
Paul: Bullshit. Right, so, yeah, you can subscribe to that despite Marcus not reading his copy. I'm not even going to ask Dan and Ed whether they subscribe because I don't wanna know the answer.
So, you can subscribe by going to boag.world/subscribe and sign up there, or at least check it out. I would never sell your email address unless someone pays me a lot of money to.
Marcus: That's totally fair.
Paul: I know, it's good isn't it. Nobody has offered me a lot of money so.
Okay, talking of money, we have-
Marcus: Paul who works to [inaudible 00:07:36]. Saves your credit card details on a bit of paper. In a drawer.
Paul: Yes. I keep it in my back pocket in case I'm mugged.
Talking about people who give me money. Let's talk about Balsamiq. My first sponsor. They are sponsoring the entire season. So, Balsamiq is an easy to use wire framing tool with a really low barrier telemetry and basically most people know about the desktop app but they also have a cloud based service as well, which is really good for collaboration and that kinda work. It's priced per active project or per space as they call it. You can have unlimited users, you can have unlimited wire frames per project, so it's really easy to get started. The bottom man, if you just want to take two projects running at the same time. Because, it's only active projects obviously, it's going to cost you $9.00 a month, which is hardly anything. But, you could just buy the desktop version outright if you wanted to but if you want to get clients feeding back or put comments in or any of that kinda stuff then the cloud based one's better.
Marcus: How much is the desktop version?
Paul: I don't know.
Marcus: I'll look.
Paul: I'm not supposed to be selling, they didn't tell me to sell either of them really, they said, can you talk about Balsamiq a bit?
Marcus: Well, that's a legitimate question of mine.
Paul: It is a legitimate … I'm not knocking the question. So you can download projects for back up if you don't want to keep them online, that keeps your number of projects down and it also does this auto hibernation feature that I don't claim to understand, but that helps as well to keep price down. So, they've put in a lot of thought … they are not one of these things that, yeah, it's only so much per project and then, you know, basically they delete your project.
Marcus: Very reasonable. $89 one off fee.
Paul: Yeah, I mean that's great. So, because there are some people that get really annoyed by these subscription services, you've got a choice, it's great. So, if you wanna check out the cloud version, you can get a 30 day free trial and then, after that, if you go in to the Balsamiq cloud interface and you enter the code balsamiqboag alongside your billing information then you get three additional months for free, which is excellent.
Marcus: Most excellent.
Paul: It's really off putting because you're sharing a mic with Ed. Who … Ed is just ignoring the mic entirely, but you're having to lean over every time you want to say something and you make all that [crosstalk 00:10:02]
Marcus: Is that annoying you?
Paul: No, it's the fact that you make all the effort to lean over to go "most excellent".
Marcus: You know, that's the way it is Paul.
Paul: You just felt I needed to be interrupted. [crosstalk 00:10:14]
Marcus: I forgot to lean over.
Paul: So you can check it out at Balsamiq.cloud. Okay, so that's Balsamiq.
Now, I bet you, both you two have used Balsamiq at some point.
Paul: Everybody has. I haven't found one person yet that we've had a guest on this show that hasn't used it at some point. Its like the oldest wire framing tool I think. I don't think there was anything before it, was there? It was designed specifically for that.
Dan: Nothing springs to mind.
Paul: Okay. What you've-
Dan: Pen and paper. I love pen and paper.
Paul: Why is he, he never mind me. It's an audio podcast. That doesn't help-
Dan: Oh oh, he's in a box, he's in a box! He can't get out, no, lock him in the box. Keep him in there.
Ed: We look like your backing singers. We're the Supreme's.
Paul: Oh, that would be so awesome.
Marcus: It's a good job there is no video, isn't it?
Paul: Can we just take a drink? This is really professional.
Marcus: Paul and I did videos for a while. Years ago. I can't remember why we stopped.
Paul: Cause it was too much work.
Marcus: You had to be together, that was the hard bit. Together … which … we had a hard time getting together-
Paul: It wasn't too long ago, actually. I was in here for some other reason.
Marcus: You came in for Christmas.
Paul: Awe, yes. That was it.
Marcus: Which is only a couple months ago.
Paul: Yeah, exactly. I didn't think it was that long. So, yeah. Okay. So, let's talk about responsive design, I think what most people think about responsive design, they think about responsive layout and designing for different screen sizes. But, there's a lot of broader challenges are involved in it and even when you are just talking about layout, there are lots of little bits and bobs and problems that you might encounter. So, there's a few things that I wanted to really to talk to Ed and Dan about simply because obviously, I don't do a lot of coding these days, I don't do a huge amount of design and I feel like I'm a little bit out of the loop. With where things are at with responsive design, so I thought, why not. Why not use the Podcast for me to learn something rather than Marcus for a change.
So, let's start off. If it's alright I'll start off with you Ed?
So, I mean, one of the things that I think is most challenging about responsive design, from a design point of view is, where do you start? Everybody says, well you should start mobile first, right? I don't know about other people but I find that quite hard to do. Is that what you do?
Ed: I kind of do it in tandem. I think a lot of it depends on what clients are expecting to see first.
Ed: So, you kind of present what they are expecting to see, while in the back of your mind, planning how you're gonna build it in all various states.
Ed: And, probably don't show them that immediately, until you sort of ironed out the details.
Paul: Yeah, okay. So do you tend to work … so you're planning all different states at the same time?
Ed: Usually, yeah. You're mocking something up in Photoshop or whatever and every bit you're doing, you're planning how it will respond.
Paul: Yeah, okay. So, do you start with a grid system and then … what's the kind of … you are thinking about all the different steps but, you know, obviously if you're doing a high fidelity mock up, or something like that, then that's a lot of work to do simultaneously.
Ed: It is yeah. I don't tend to mock everything up at every different stage. I just look at the bits that might be a problem later and kind of focus on them.
Ed: It's kind of predictable now.
Paul: Right, so it's a lot of …the main challenge is one presumes to like, what's going to go above what and when it fits down on-
Ed: Yeah, a lot of that comes to wire framing and you know the order and then it's just right. Gotta get it over there, how big it's gonna be, how we gonna get it in the right order.
Paul: So, you tend to start kinda of wire framing it first before going into Photoshop or-
Ed: Yeah, wire framing is already done by then.
Paul: Okay. Cool. Notice he says Photoshop. Did you hear about Lee?
Marcus: Lee uses Sketch.
Paul: Yeah, I know. Well, he was having a go of … Ed, wasn't he?
Ed: He was. He's given me a full lesson of it. Yes, that's really good and immediately went back to Photoshop. So, yes you are right.
Marcus: And Lee tends to do mock ups of everything as well.
Paul: Right, he'll mock up all the different states.
Ed: It's because it's quicker in Sketch.
Paul: It probably is, but you know, I don't actually think it matters what tool you use, you should just use whatever tool you're comfortable with.
Marcus: Although probably not Photoshop.
Paul: Do you not ever hand projects between the two of you.
Ed: Not often. We have done occasionally.
Paul: I'll bet. It's a lot of swearing when that happens.
Paul: And so you, Dan, as the person who gets stuff from both Ed and Lee, you've got to deal with both ..
Dan: Primarily, I mainly get stuff from Lee-
Paul: Right, because Ed's capable of coding.
Ed: I code my own so I don't mention all the problems I create for myself.
Dan: Wow, if I'm putting words in my mouth …
Marcus: Can I just step in here? Just think nice calm thoughts.
Dan: I'm thinking nice calm thoughts. Yes, so primarily I'll get stuff from Lee because he will tend to work on the projects that will require more working out …
Paul: Different, more complex.
Dan: More complex organisms and more complex organizations with more internal politics. So there will be a lot of work that will go into that side of things. And then he'll do sort of a design looking feel that will get passed to me in whatever format. They use Sketch or something that's been mocked up in Browser. I think because of that, those kind of clients want to see, like Ed said, it depends on what a client's expecting to see. Most kind of clients want to see the website. They want to see what the website will look like. They don't necessarily care how it's going to look on mobile. So it could be that I'll end up getting something that is mostly desktop. I could end up getting a Sketch file of many, many things. And I tend to sort of have to pull that together.
Which is nice in some ways because sometimes you need to see sort of how … I mean … We've been looking into it internally a lot about topic design lately and using sort of more constructive blocks of things. It's weird because you can say okay it's going to be easy to start off and do desks and then we've got building blocks and master that and we build it up from there. But sometimes you need to see how the organism works as a whole to see how the individual building blocks work. So sometimes getting a more complete "website" design is actually helpful. It's a real toss-up. It's difficult.
Paul: The problem I see with … I'm a great fan of atomic design, design systems, patent library [inaudible 00:17:26] whatever you want to call it. Actually, we're going to talk about them … is it next week … no, a couple of weeks time we're gonna be talking about them. The downside of them is that you don't … you can get buried in the details and lose that kind of visual hierarchy and how everything fits together and the flow of stuff.
Ed: An overall aesthetic for a site.
Ed: Yeah, you can get very focused on details quite early on.
Paul: So do you tend to start by doing the big picture. This is kind of what the overall feeling will be like and refine those blocks?
Ed: Generally yeah, I think I'm in an easier position than Lee and Dan because they obviously gotta hand over at some point from one to the other whereas I can talk to a client and say this is getting slower for me to mock up each bit. It'd be great if I start prototyping if I move it into code at this point. And I can transition that on my own because I'm doing both parts.
Paul: I guess, also, once you get into the browser as well then that kind of forces you to address responsive issues as you go.
Ed: Yeah, cause they're always on a different screen or look on their phone on the way home. And it doesn't work.
Paul: So going back to you Dan, with the organisms and modules and the bits of atomic, whenever you build a component … I always get confused about the different … when you build a chunk of functionality … and call it a new listing, do you always build that so that it's responsive from the outset bearing in mind you could drop it in a side column, which is half the width of a main column, that kind of thing?
Dan: So this is one of the most tricky things, is deciding … this is why it's almost nice in some ways to have the big picture rather than considering things sort of just component first because you're able to see where that component is repeated and if it needs to … if you need to be able to drop it into a really, really tiny column and things like that. So trying … that's what building mobile first is really, really helpful because you have a tiny column so you have how that's gonna work and its almost how that then grows, scales up, and what you can do with the layout and layer on top of that. We don't have content queries yet unless there's many, many sort of things that can be shootable and Ed had a decent solution that we've used on one project but generally you end up_
Ed: You end up using it less-
Dan: It worked really nicely but the problem with that is you have to cater for all possible eventualities and that produces a ton of code.
Paul: What do you mean by content query? What are you getting at there?
Dan: You've got media query so you can say when the screen is at this size, do this thing. But you can't say when a box is in a grid of three columns so when that box is only 300 pixels wide do this. When the box is 1200 pixels wide, do this.
Paul: Okay, so it's only on a kind of page … individual-
Dan: Then you end up sort of trying to fudge it with okay, when the box is in three columns or when the box is in that … if your writing primarily … with that. So that's kind of tricky. So having the big picture from the start does tend to help.
Paul: Because, you're right there is a fine line, isn't there, between kind of reused ability that we want this code to be flexible in the future so that if someone comes along and decides to do something you weren't expecting with a bit of a component or whatever that it won't break but on the other hand, you don't want to create crap loads of unnecessary code.
Dan: It's always … it's a toss-up … it's an "it depends" situation … it's how much flexibility do you want to be able to provide for the time that you have and the likelihood that someone's ever going to use that.
Paul: It's a tricky one isn't it.
Dan: It really is, yeah.
Paul: Okay. The other thing I wanted to talk about was typography because it strikes me that typography is a tricky area of responsive design. We had Jason on a few weeks ago who was talking about variable fonts and the fact that that works quite well but that's not necessarily where we're at right now. One of the problems … are you just taking … you can't just dump typography in the works on the desktop version you switch over to a mobile version and suddenly the line lengths are really short and stuff like that. So how are you guys dealing with typography?
Dan: One of the first things that I like to do when I'm starting, sort of picking up the design, and starting to build a good base is have a really good set of base typography. Not necessarily that carries across from project to project but something that is for that project. You sort of sit down you also do … sort of mini boot strap for each project.
Paul: Right, okay.
Dan: You'll pick out the typography elements. I think there was a tendency a little while ago to do things like as the width increases, you bump up a font size to take up the extra space. It very quickly transpired that that doesn't work.
Paul: Why don't you think that works?
Dan: Because a) people don't use their devices like that just because it's a bigger device you're not necessarily seeing further apart from that and b) as you have more screen real estate its more sensible to try and add layout rather than just increasing the size of the text. You're sort of increasing the size of the text while trying to add layout and you're ending up with a text that doesn't work in terms of context that you're designing for. One of the things that I do still have in a sort of base rules is vertical media queries to increase font size, which can also help address the "below the fold" issue as well. It does seem to be fairly reliable that if you're on a shallower screen you tend to want the website to be a little bit smaller and it's sort of … you can see it resizing and everything … it helps address some of the fold issues that we get with clients and things like that.
Ed: We tend to pair those a bit down as well and say that if its at least this wide and that tall, then we know we've got a bit of space to play with. Just height or just width alone isn't-
Dan: It sounds weird we're using sort of moderately complex base media queries for typography before you start layering on too many components can actually provide a really good base for how those components inherently behave before you have to start styling them.
Paul: That makes perfect sense. I get it. Cause as soon as you then start dropping components in, those components … the typography within the components are gonna resize appropriately out of the gate.
Dan: And then you can think about how those components behave when they are in different situations as opposed to you know trying to control the sub-
Paul: Yeah, yeah, yeah. Makes a lot of sense. Marcus what do you think about this?
Marcus: I think Ed needs to think about his base font size more often than he does.
Paul: Yeah, I agree Marcus. Thank you for that really profound comment.
Ed: That's actually true.
Paul: Oh, is it?
Ed: It's getting closer actually cause my eye sight is getting worse. So year by year the fonts are getting bigger.
Dan: It's difficult though because one of the first things I ask for whenever I get design is a typography page with all the face typography for an article because if you think about, the bulk of a client's site, the bulk of the user generated content is gonna be text pages of some form or another. So getting everything nailed down. But clients don't wanna sign that off cause it's a really boring thing to sign off. It's like "How is this page of text looking to you?". Great, okay. Well the best feedback you can get is sort of no feedback.
Ed: Or if … recently as well though that they see text alone and it kind of depends on the context as well cause when you shouldn't adjust the lump of text because, yup that's readable. In a particular layout, it could be surrounded by a load of white space and it looks a lot smaller than it did on its own.
Dan: You need the whole picture and all the little building blocks all at the same time.
Ed: Which left us with a last minute bump of the font size the day before launch.
Marcus: That's what I was referring to.
Paul: You got to take into account those kinds of things in the design process that you might get further down the line and suddenly go, "You know what? The Font size isn't right" or the typeface isn't right even. How do you code for that kind of thing or do you not … you just swear a lot?
Dan: To some degree it should theoretically be easy because we're using ends for media queries. It shouldn't be that much of a big deal to be able to increase the base font size. But then you would inherently have not got affects on that. With things like main nav … you design a main nav with a horizontal set of nav items, which obviously you decide at a certain point where that will break dawn to a different-
Ed: If it was any other element, changing a font size is a piece of cake and you can spot it. It's one off. It's five. Change the base font size … I've just got a day of checking everything else again. It's probably fine but-
Dan: It's the going back and checking it and just the paranoia of oh that thing in that very specific place is gonna break.
Paul: Which is fair enough. It's interesting what you had said a minute ago about how type sizes are getting bigger the older you get. I've become very aware of that recently where I'm now at a difficult point where if I'm trying to read on the screen I have to take my glasses off because I'm short sighted. And I've become very conscious of that kind of thing. There's a kind of related accessibility issue alongside that where depending on the device somebody's using depends on what is readable and what is not. So, for example, if you're on a mobile device, you might not be in as good an environment in terms of color contrast … Do you sit and think about that kind of stuff. At which point, do you just go "I can't cope with any of this anymore!"
Ed: On a mobile device, it's likely that their resolution is going to be much higher. Things will be clearer even though their smaller. It's another consideration.
Paul: At some point, you just got to go-
Ed: You just have to throw it in front of bunch of people. See if anyone objects.
Paul: That's the other trade off with all of this kind of stuff. You can make it … you could put so much energy and so much effort into optimizing the responsive experience but the end of the day you have to cut the cloth depending on the budget and time-
Dan: And that's a very, very big factor. Everything's a trade-off between … you know we've got "x" time to build this … you get the base stuff right. And it's how much time do you have to but into optimizing everything later.
Marcus: We have a list of stuff that we say, browsers and devices, that we'll test on but I always encourage clients … if you've got anything else, test on that as well. Yes, you have to take a pragmatic view otherwise you'll be doing it forever.
Paul: And that's the thing that often annoys me about when you read articles on responsive design. Some large organization will outline and they've been working on it for months and you think that's great that you could spend that much time fuffing around with the typography but in the real world that doesn't happen.
Dan: It's great to have those ideals to work to and big organizations and sort of product projects, I guess, have the time and resolve so anything … if you're working on a big project where that stuff is kind of important is a great influencer for us to sort of have a set of tools and a set of rules that we can consider. I think keeping that in the back of your mind is always good. When you're working on a small project, it's not feasible to do that all of the time. And I think that's okay. There's a lot of sort of you much know everything, you must do everything, you must do as much as possible in this industry particularly at the moment. I think sometimes it's okay to take a step back and just sort of say everything has its use case, but it depends … you got constraints-
Paul: A lot of time good enough really is good enough. It doesn't need to be perfect-
Ed: And you don't need to test it a hundred times, just lean on the side of caution and you know you're gonna be okay.
Paul: Talking about mobile devices and the differences, obviously we've got quite a lot of input devices that people don't often think when they think in terms of responsive design. They immediately go, "Oh, well we just rechecked the layout and it's all done and lovely." You've got track pads, you've got fun fingers, you've got mice, you've got all that kind of thing. I mean what factors do you consider, from a design point-of-view, when worrying about that stuff.
Ed: I don't know, there's basic stuff like hit area if you're using fingers and losing rollovers things like that how much information you're showing people based on rollover. You can lose context of everything. I don't know, a lot of its become second nature I don't know if I consider it anymore, I just know that that won't work or that will work.
Paul: Packing links too closely together is the big one I always see people making the mistake of … I remember working with you back in the day, long time ago now when we were working on WFF where you had this tendency to pack links. This was obviously before I Phones and things like that. But because we were designing for an elderly audience, which didn't have the best motor control probably it was a problem. But now, it's like you wouldn't do that anyway because-
Ed: You still find it [inaudible 00:30:35] on a responsive site. You still want to pinch and see … to be sure you're hitting the right things. I shouldn't need to do that.
Paul: No, absolutely. It's a huge thing. What about imagery? Obviously, this has been a big month for me on Boagworld because I want my site to perform as well as it did but I'm still happily using the design you guys built ages ago. I had a good one, you'll like this. I was looking at my analytics yesterday and its screen size, and someone must have been viewing it on a watch because it had the dimensions of the watch on it … really tiny screen size. And I remember right back in the day you showed it to me Boagworld working on a watch. [crosstalk 00:31:24]
Dan: I don't think it was working on a watch but I pushed it right to the limit and got it down to something like 180 pixels wide just because I was bored that day. Just to prove that this sort of thing-
Paul: I pretty sure … whoever it was … that immediately grabbed my interest … they looked to multiple pages so they didn't just view it and then go "this is unusual" and bugger off. So somebody is actually benefiting from that bored day-
Dan: Awesome! Oh God, I wish I had days like that.
Ed: It was bad.
Paul: It was a show just to see how bad we had screwed up the site. So obviously, I've been working a lot on performance recently, and the big one is with imagery. And imagery on different devices. Now one of the best ways of impertinent performance is obviously to keep image size down but equally you don't want images to be shit on a nice retina displayed device and equally you don't want to load a bigger image that's available …. How do you deal with this mess, Dan?
In terms of quick fixes, one of the things we use on a couple of sites is Lazy Loading. Trying to invisibly as possible so a huge [inaudible 00:34:39] offset so a couple of screen heights maybe so that the image is almost invisible when you're doing it and obviously have a full back foot and job script because that same … I know you reviewed a product called Sirv. Is that what you're using?
Dan: That looks like an excellent technical solution but at a cost. I wouldn't like to be the person that had to go an approach the client that just went, "Hey we need to throw this amount of money just to get your images to work."
Paul: We'll get Marcus to do that, that's his job.
Dan: Again, everything's a trade off. Unless you're working sort of on a site that is for a specific market that's gonna be always on a really slow day … I'm in no way saying obviously it's not important to optimize your stuff. Yeah, everything's a trade-off.
Marcus: It's a balance isn't it? What we've found … we've been trying to find, or you been trying particularly Dan, to find this best way of doing this. What it comes down to is you've got to make a judgment call of quality over size of image.
Paul: The interesting thing I find about it … I find it really weird if you turned around to a client and say we want to use this image optimization service that will detect the resolution we're working at and deliver the appropriate image, which it does with Job Script, but it has a full back obviously. It'll handle the lazy loading, it will do all these great things and they'll go, "No, I'm not paying for that." But, if you say to them, "Do you want your site to rank higher on Google?" They'll go yes and they're willing to pay a lot of money for that. No, of course in truth, performance is one of the biggest indicators of your placement on Google. One of the biggest … it's a big one. So perhaps that's the way to sell it as we're talking to clients and say if you're willing to do this, if you're willing to pay this a month, it will help with your rankings. I've really done well out there and it's worked really well for me.
Dan: It does seem like a really nice technical solution.
Marcus: How much does it cost?
Paul: Do you know I don't know because they give it to me for free. Let me-
Marcus: We'll just get Paul to get it for all our clients.
Paul: They were very specific conditions. Let me have a look. It's very nice of them to give it to me for free. It's not-
Dan: It's not cheap.
Paul: It's not cheap. 20G of imagery being served up a month is $59 per month.
Marcus: That's quite a lot of imagery.
Paul: Yeah, that would be enough for most people. I mean if you go down to 5G it's $!9 a month. So it's not obscene.
Dan: Most clients would pay that.
Paul: You reckon?
Paul: Certainly your kind of clients or our kind of clients.
Dan: $20 a month, absolutely.
Paul: It would save these guys a lot of hassle about it at worrying about imagery if you just used a service like that-
Dan: And that's it … That's what it comes down to I guess, how much time we're putting into it and we're obviously billing out for that or whether you've got a solution that's extensible and saved us the trouble of having to debug things to some extent as well if you can shift that to a third party service.
Marcus: It's a thought.
Paul: Moving on from that, I just solved your image compression problems, well actually Dan already knew about it but that's no problem. Talking about navigational mobile devices, Ed, there's been a lot of 'hamburger menus are evil'. Now I have a version of hamburger menus online, which you guys designed and I still think works very well because it's very discoverable in navigation. As soon as you start scrolling, you see the navigation it goes away so you're exposed to it. How are you tending to deal with mobile navigation these days?
Ed: Quite certainly to laugh most of the time. If you can reveal it when you got the space it's a great plan if there's not a surprise then when it expands from somewhere else. We kind of tried a few times to hide it as if it was mobile navigation but all the time, even up to desktop and … It felt like a bit of a surprise or it takes over the screen. I think the less surprises the better usually.
Paul: So essentially, the way it works on Boagworld, is worth going and checking out if you haven't seen it, is that when it loads on a mobile device to begin with I think it shows the navigation, I can't remember now I haven't got my mobile with me. But then as you start scrolling down to the content it then hides it away under a panel that you can click on the hamburger icon-
Ed: You just keep a fixed bar up so-
Paul: Actually I think it's a really good thing.
Ed: I don't strongly dislike the hamburger menu as much as other people seem to. I think it's so widely used now. It's quite well recognized. People are pretty used to it.
Paul: People … it goes through trends.
Ed: People like to pair it with text saying Menu, Nav or something-
Ed: It kind of dilutes it. It really annoyed me the other day. I was looking for a burger restaurant-
Paul: I remember discussing-
Ed: There was this menu … to find another link to menu, then shows you a line of burgers. It was really confusing. But that confused me and I could see how they would've designed it and come to that decision.
Marcus: I would rather see the word Menu than the hamburger icon.
Ed: Even if it then had another link to Menu inside it?
Dan: No, that's just … I think restaurants are a bit of an edge case. Especially specifically burger bars.
Paul: That's quite an unusual situation.
Dan: It can come down to use cases where I guess you don't have to have traditional navigation as such. We've got sites that are almost navigation as content or around the content. Thinking about user flow in the page. When is your user likely to want to use the navigation. I mean we've done stuff like sort of sub-navigation would be at the top below the header on desktop, but we've moved it sort of to the bottom of the content on mobile because when the user finishes reading the article they want somewhere to go. Something like that. Then you've got a toss-up between having massive index pages where you've got tiles of stuff that's loading a load of images just to take you through to another section. If you end up wanting to show that.
Paul: In that kind of situation, I try and float content up from underneath to fill in that space. THere's nothing worse than going to a page that's essentially just a list of links. Yet they've made them look pretty but there's no actual content on the page. So if you can take bits of what is below … the key things that people are likely to want to know from that section float out, then at least it adds some value to those pages. Which is good.
Okay last question. I have no idea how long we've been going for Marcus-
Marcus: Three-quarters of an hour.
Paul: Probably last question, which is what things should people consider when building with responsive design in mind? As your coding and your designing it, what are the big things that you want to leave people with?
Dan: I feel like reviewing often helps tease out the "Have you thought abouts". That's something that I try and get involved with early on in the project and often they can be very, very annoying.
Dan: They'll come in and say "Oh have you thought about how that's gonna work without a mouse or have you thought about how that's gonna work … when this happens?" Trying to co-work as much as possible I think can be useful. It helps tease out that stuff. Distilling things to components and trying to discover the minimum level of repeatability as quickly as possible. Like your saying, trying to work out where that thing is going to be used across the site and naming things. It's one of the most difficult things.
Paul: What you mean naming things?[crosstalk 00:42:29]
Dan: Naming things
Ed: How many times have you used box or tile or[crosstalk 00:42:30]
Dan: You end up with 300 different kinds of boxes and trying to come up with names for things helps you. It almost helps you reuse them to some extent as well. It registers in your head as well as sort of registering in a design system.
Ed: Specific … helps you design-
Dan: Helps you sort of apply a design rule to it. And don't reinvent the wall.
Paul: Walls … they can be reinvented just as much as wheels … Makes no difference.
Dan: Don't reinvent the wheel. My toolkit of base components and those things that you do find yourself reusing … consistency and rules should be a help not a hindrance. We're designing to a purpose. It's a contentious point to say good design works within constraints and adheres to rules but it should at least be creating rules.
Paul: That shouldn't be a contentious point, should it? I think that's the foundations of design. It's not art. It works for a purpose.
Ed: It's created to work within and it's the same with-
Paul: You can still break those rules but you just got to do so in a new form way I think. That's my opinion anyway.
Ed: The only other thing I'd say when building is assume that things are going to change. If you build something that feels a bit flaky, a bit 'one of' it's probably a bad idea because someone will change it later anyway. It's gonna give you a headache.
Paul: This is jumping back a bit, but it's a question I want to ask. One of the problems with responsive design, when it comes to imagery that in certainty for normal images content images that are in the page, that's fine they scale when the text scales but if you've got stuff over the top like it's a background image and you start scaling it, certainly after someone's head's cut off … I mean, is there anything you can do about that.
Ed: A number of approaches.
Dan: It depends and it kind of comes back to what I was saying about the client whether … it's going to take a Content Editor time to do that. I remember on a project for one of our law firms I spent ages building this huge range of options that the client could use. Like they had this big panel area and it was just … you've got essentially nine options you just define the focus point of the image and then background sizing will take care of it. It's just like oh okay, right, that they've left all the images that they've uploaded as default so they're all just in the same place. It takes time.
Marcus: If you need to educate them, where not to put the focus of the image. That's kind of like, it's going to be cut at this particular kind of size then you're likely to lose this and this, and lose that and that. Make sure your focus stays … I think you even put it into like a,b,c,d, and e.
Dan: I ended up-
Marcus: A is perfect, b is okay-
Dan: I ended up doing them sort of a test card type thing that you see on the TV of safe areas of certain images.
Marcus: Safe areas. That's what it was all about.
Paul: Interesting, that's quite an interesting approach to it.
Dan: It did work.
Marcus: It did work. It did work.
Dan: Technically it worked. Again it takes a Content Editor time to actually go through-
Marcus: It educated … they were a hard client to kind of get to the top of. It was almost like you'd go in to speak to the people you were dealing with and you knew there was this step up … that they had to go through every decision … and then developing that gave them the tools to educate people that we never really got to speak to.
Paul: In an ideal world, you'd build into the back end that when they upload an image, they could see what it would look like at different sizes and whether they set the focal point. But again, it's budget … at the end of the day you can only do so much within a certain budget. There are tools out there, I'm sure I've seen a tool where you can set the focal point-
Dan: You can visibly set it. Yeah I can't remember what it's called.
Paul: I can't either. It's a tricky one that one. I'm never quite sure about it. Anyway, let's talk about our second sponsor before we wrap up today's show.
Marcus: All of us.
Paul: What do you mean?
Marcus: We're all gonna talk about-
Paul: No, I'm … this is me … this is a special moment between me and the listener. Don't ruin it. Hello listener. I wanna … Actually it just sounds creepy.
Dan: That's quite a shift in tone.
Paul: Okay. So we are gonna talk about Fullstory. The best session recorder out there. I absolutely love Fullstory. We all know that session recorders allow you to watch back user sessions and they are incredibly useful for getting inside center natural user behavior. But session recorders can be frustrating. For example, you can be overwhelmed by the sheer number of sessions that you can watch back and it's hard to figure out what you want to see and what you're looking for and that kind of thing. And then often you have to plan ahead as well and gather data on a particular behavior. So let's say you want to know how many people have signed up for the newsletter you have to set that specifically that that's what you're looking for, then you have to wait around for a couple of weeks while you get enough people doing it before you can watch it.
Fullstory solves both of these problems. For a start, it records everything about all sessions, meaning you don't have to plan ahead and you can search for almost anything from what text people have clicked on to what dom elements they've interacted with so you can put in the class of an element and say I want to see everybody that's clicked on this class. It's incredibly powerful from that point of view. You can also go in and even track moments of frustration like when they start repeatedly, aggressively clicking on elements on the screen.
It really kind of gives you the ability to filter through all this massive videos and get a good look at what people are doing. So you can sign up today for a month's free trial. No need to get a credit card out. No obligation and you can just try it out. At the end of that free month's trial, you can actually continue using the product up to 1,000 sessions per month. It's still a really useful tool even if you don't want to pay for it. But pay for it, it's great. It's Fullstory.com/boag if you want to check that one out.
So if you want to know a little bit more about responsive design, I've got a couple of links that you might want to check out. The first one is responsivedesign.is which is a nice kind of summary of all things responsive design. Like there's articles on it, loads of opportunities to learn stuff, etc. etc. If you want to learn about my personal approach to squeezing more out of images and how I use that Sirv that we were talking about earlier, then you can find out more about that by going to boag.world/responsive-images. And then finally, if you want to know about responsive typography, which is another area we talked on today, there's a great article over at Smashing magazine that you can get to by going to boag.world/responsive-type.
I like to, at the end of each show, leave everybody with a few next steps that they can take. This one is a nice easy one on this show, which is on the next project before you do anything stop and think about your layouts. Start thinking about how you're gonna scale your imagery and typography in particular and adjust it for different devices. And really, I think both Ed and Dan have said it, review often, look at it a bit … constantly do … don't just do the desktop and then think about the mobile afterwards. Do them in tandem, hand-in-hand, and everything in between. Alright, I think that wraps us up for this week. Marcus, do you have a joke for us?
Marcus: This is from Bob Salmon on the Slack Channel. Which Spice Girl can hold the most petrol (or gas if you're an American)?
Paul: Which Spice Girl can hold the most petrol?
Marcus: Jerry can, It's quite good, come on. Good one, Bob.
Paul: I like Bob, I like Bob a lot. He's a really good contributor to the Slack Channel. He's got a lot going for him. That was not one of the things that he's got going for him.
Marcus: He's got no taste, Paul.
Marcus: Maybe it's me.
Paul: It could go either way. I wanted to say, before we completely wrap up, I'm really looking to gather some feedback on the show. Is there anyone listening to it? Is it just being downloaded by apps all around the world and no one's actually listening to a word we're saying. I'd love to hear from you, if you listen to the show, what you like about it, what you don't like about it, so that as we start planning future seasons we can bare all those things in mind and adapt them. Please drop me an email. I know it's a pain in the ass, you've got enough emails in your life. But if you can spare me two minutes to email firstname.lastname@example.org it would be much appreciated. Any thoughts on the show whatsoever. Next week it'll be talking about embracing the exciting future of grid layout with the traitor, Andy Clark, who's left our fair shores-
Marcus: You're better off without him. I'm going to save the insults for tomorrow. Next time we record.
Paul: Next time, which happens to be tomorrow. All right, so that's it for this show. Ed, thank you so much for coming on.
Ed: Thank you.
Paul: And Dan, thank you as well.
Dan: Thanks for having me.
Paul: And, and, I'm not thanking Marcus.