RWD Podcast Episode #29 : Jason Beaird

Justin Avery: Hi everyone and welcome to another edition of Responsive Design podcast. This week is episode 29. My name is Justin Avery. I’m your host and the curator of Responsive Design weekly newsletter, a newsletter all about responsive design, funnily enough.

  This week our special unofficial sponsor is MailChimp. If you are on the newsletter list you experience MailChimp at least once a week because that’s what I use to send my emails. It’s a very simple to use tool, very responsive. I’ve enjoyed using it over the past 146 weeks now. If you’re looking to send newsletters, I highly recommend going and checking out MailChimp. Speaking of MailChimp, this week’s guest is a very special guest from MailChimp itself, Jason Beaird. Welcome Jason.

Jason Beaird: Hi Justin. It’s good to be here.

Justin Avery: Whereabouts are you dialing in from, Jason?

Jason Beaird: I’m coming from our headquarters in Atlanta, Georgia.

Justin Avery: Oh, nice. Nice weather there today?

Jason Beaird: It’s chilly. The weekend was great, though. Now that it’s the week day and we’re all working it’s cold and wet.

Justin Avery: Doesn’t matter how it is outside when it’s when it’s [crosstalk 00:01:15].

Jason Beaird: Exactly.

Justin Avery: I have the [crosstalk 00:01:17].

Jason Beaird: We’re all setting in front of our computers.

Justin Avery: I have the exact opposite experience in the UK where all week it’s sunny, and my wife goes out with our little boy and enjoys the sunshine, and on the weekend it rains. It’s not all-

Jason Beaird: That’s usually the case here in Atlanta, but last weekend was glorious.

Justin Avery: Good to hear. Now, can you tell us a little bit about what you’re doing at MailChimp, maybe a bit of history of how you got into the web and your role currently?

Jason Beaird: You just cut out for a minute there, Justin.

Justin Avery: Oh, sorry. Skype. No, we were just talking before about Skype how their start of the call quality’s very good, and they might taper off. This might be one of those occasions. [00:02:00] Keen to know a little bit about your role at MailChimp, what you do there and how you got into the web.

Jason Beaird: Sure. My current role is the lead UX developer. I manage 3 other awesome front end developers that work on the MailChimp application. I’ve been there since March of 2010, so it’s hard to believe, but I’m coming up on 5 years now with MailChimp.

  How I got into that and my background, I went to school for graphic design, but I’d been writing HTML and was making hideous websites long before I started learning how to design. I started doing webdesign professionally in 2003 during the heyday of all the CSS gallery sites, where I managed to get featured a few times. As a result of some of that in 2007, I had the opportunity to write a book for Site Point called the ‘The Principles of Beautiful Web Design’ and just worked in web design for a very long time doing client-based web design development work. Then, started with MailChimp, like I said, in March of 2010 and been having fun since.

Justin Avery: That’s really cool. I bought that book.

Jason Beaird: Oh, really?

Justin Avery: Yeah.

Jason Beaird: That’s always weird to hear when somebody says, “Oh, I have your book.” It’s like, “You know something about me already and I don’t know who you are.”

Justin Avery: It’s weird to invite someone on to a podcast and start talking to them without knowing that they’d written a book that you’d read. You mentioned that you got featured a couple of times with the sites that you were creating. Are there any of them still up and around?

Jason Beaird: Not in the same form. It was mostly my personal site that I was working on. A few client sites. None of them are. This was, like I said, 2003, 4, 5. At that point I didn’t have kids yet, so I was re-designing my site every 6 months to a year. A lot’s changed since then. My site pretty much remains the same for [00:04:00] periods of years now. I try to write a blog post every few months.

Justin Avery: I was talking to someone the other day. There’s a new year’s resolution where you look at everyone’s blog, and there’s a post every couple of days for January and then one in December talking about how they’re going to do posts once a week for the rest of the year, the following year.

Jason Beaird: I’ve stopped doing that now. It’s been so many years of telling myself, “I’m going to write more posts,” and then it not happening.

Justin Avery: It’s terrible. With MailChimp, so you look after the front end crew. Now, there’s lots of front ends to MailChimp, right?

Jason Beaird: Yes. There is different aspects of the front end in MailChimp.

Justin Avery: I use MailChimp, the application itself, so I login and I go through. Many years ago when I was signing up I had a marketing site to it. Then there’s also the email templating side of it as well, I suppose, with design. What are the different areas of design that you look after?

Jason Beaird: The team that I work with is part of the greater product team at MailChimp. We look after everything that you see when you log into MailChimp. All the email templating stuff, that’s mostly Fabio. He’s our email template designer. He’s got another person that’s working with him on that. Then the front end dev team we manage all of the front end assets and aspects of the interface. We have 2 really talented UI designers that also create comps for us to pull from. Like I said, we manage everything you see at the login screen and beyond. Everything you see at MailChimp.com is part of the marketing sites, the marketing team handles all that.

  Then, we have various other products, even. We have TinyLetter and Mandrill. TinyLetter is managed by us. We kind of take turns working on bits and pieces of it, but Mandrill operates as it’s own separate company. Their marketing site [00:06:00] and their application are a completely different team that works on that.

Justin Avery: Oh, wow. I haven’t checked out TinyLetter. I need to go and have a look at that.

Jason Beaird: We basically call it MailChimp lite because it’s a very simple interface for creating and sending an email, usually for individual authors, to be able to send out a news letter, and it’s totally free.

Justin Avery: Oh, wow. That’s good. Everyone should go and check out MailChimp lite, and or TinyLetter. We’ll put a link in the show notes as well. I suppose, with all the different interfaces, everything still looks very similar across. It’s a good brand experience. Do you have someone who looks after the branding side of things, or do you guys work together when you’re working on the different sites?

Jason Beaird: We tend to work together a lot. MailChimp started in 2001, so there’s a long history of front end elements that that have come and gone since then. When I first started in 2010, we started on the first redesign of the MailChimp application that I was apart of. That was, actually, a part of the marketing team’s redesign of the site. We weren’t using the same front end crew at the time, but we were looking at what the marketing team was doing and adjusting what we were doing. They were doing the same, looking at how we were reshaping the interface of the app and adjusting what they were doing for the marketing site. That was back in 2010.

  We just redesigned again in 2013, again, based on some changes the marketing team were making to MailChimp.com to kind of freshen things up. As part of those last 2 redesigns, we ended up creating a pattern library that has come along and evolved. We’ve released it publicly at ux.mailchimp.com that shows the front end elements that are re-usable in the app. [00:08:00] The other products I mentioned, TinyLetter and Mandrill, both borrow from that pattern library. The marketing team, although they don’t use the pattern library wholesale, they have their own pattern library based on our patterns. That’s one way that we help keep that consistent look and feel.

Justin Avery: Oh, nice. With the patterns that you have, is that where you do a lot of your testing? Do you have another internal site? Do you test things out in the pattern library to make sure they work across all the different iterations and then push that up? How does the work flow work?

Jason Beaird: We have a dev environment that we create new interfaces in. The pattern library, it’s more a collection of common elements than it is a testing grounds for new elements. I like to say that the pattern library is for anything that’s used 2 or 3 times in the application. A lot of times we have a new comp for some new process or new campaign creation flow. We just build that up as if it’s a one-off, using as many of our existing patterns as possible usually. Then if we end up, say, extending from that for another component of the app we might … We don’t know if something will become part of another area. We don’t know how to generically write it and class it, because we don’t know how it’s going to be used. When we do find out that, we can take something that already exists and use it in another place, that’s usually the point at which we make it a pattern, and or pull parts of it out and put in the pattern library.

Justin Avery: Cool. Is there anything that you use to maintain the pattern libraries? There’s things out there like Atomic Design. There’s a couple of other, I think, roll-your-own pattern library stuff. Is it something you do just in-house, on the fly, or is that a system which you use? [00:10:00]

Jason Beaird: We’ve kind of built our own pattern library. When I started the original pattern library with the 2010 redesign, that was actually before Bootstrap even. When Bootstrap came out, we saw what Bootstrap was doing and we’re like, “Wow, this is kind of what we’ve been doing with MailChimp,” creating an archive of re-usable parts that we can assembly-line [features 00:10:22] off of. We looked at what Bootstrap was doing.

  Everybody has come up with their own solutions and roll-your-own systems for pattern libraries. It’s really been inspirational. It’s shaped ours, but ours is still very much our own. Like I said, it’s released publicly, but we don’t provide any way to download the code or fork it on github. It’s really built specifically for the challenges that we have at MailChimp and the interface that we’re working around. We don’t really feel like it’s something that somebody can take and use, as much as it’s something that might inspire people to create their own.

Justin Avery: It’s great that you’re publishing it live. I had an example yesterday where I needed something to work in a particular way and just ended up going to Foundation’s layout grids to workout how they achieved a particular interaction or a particular way of laying something out on a screen, found out the CSS, stole it, and applied it for my own stuff.

Jason Beaird: Exactly. Zurb’s another good system. Really, it’s part of my belief that that’s the way the web operates. As someone who learned everything that I know from looking at other people’s source codes, I wish everybody would do the same thing and release how they’re doing things to publicly show it. Anybody can look at the source and view it, so why not just show how you’re doing things? It doesn’t mean, necessarily, it has to be released as an opensource project, but at least that way other people can see what you’re doing and point out your mistakes and show you how you can [00:12:00] do better, or extend off it, take the good parts and do something amazing with it.

Justin Avery: That’s such good advice. People should write about it, too. I know that we both don’t do any blog posts anymore, but people should if they have time and don’t have kids running around, definitely blog about it.

Jason Beaird: We try to do that as often as possible on the UX team at MailChimp. We have a newsletter that we write. It started off bi-weekly, but that got to be too much work to try to produce a bi-weekly newsletter. We do once a month. It’s the uxnewsletter.com. We’re trying to have one guest author, so maybe we’ll have you, or somebody else awesome in your listening audience write an article for our newsletter. We try to have going forward one awesome guest author, and then have something within MailChimp about challenges that we’re facing. We’ve got an article coming up internally about IOS 8 extensions. We’re going to have a guest author from Center Centre, the new UX school from Chattanooga, is going to be writing a piece for us for the next issue.

Justin Avery: That’s really cool. If you do find you’re running short, I’d be honored to be able to write something for a MailChimp news letter. It’d be very [meta 00:13:14] right? Writing a newsletter for MailChimp?

Jason Beaird: While talking about it on a podcast.

Justin Avery: Exactly. You said you had a couple of awesome UI designers. The process of building something for a requirement, and then if that requirement occurs a few times, you put it into the pattern library. How does it look from a internal process point of view, from “We have a problem,” or, “Someone’s reported a problem,” or, “We’ve seen something that we want to be able to do,” to, “Let’s push it”?

Jason Beaird: The process varies quite a bit depending on the situation. We have a lot of those, “We have a problem.” People are complaining that this [00:14:00] process is confusing, or the onboarding, people are getting lost, or there’s some back end thing that needs to change in order to allow people to use MailChimp the way that they’re trying to use it. Those are bugs or support issues. Then we have feature requests, people want to be able to do something new. Then we have features that we have cooked up that haven’t been requested, but things that we’ve come up on our own. Depending on the situation, the process looks a little different, but, really, it ends going down the same pipe. We talk about it as a team, the whole product team we end up talking about a lot of the ideas.

  Our UI designers usually flush things out, several different options for ways that we can build it. It’s interesting because we have UI designers and they’re working in Photoshop and Sketch, but they’re not necessarily just creating things off the fly. They actually have their versions of our pattern library as reusable patterns that they’re drawing from most of the time. They try to avoid creating new patterns as much as possible. A lot of new features require new interfaces. It’ll go through them.

  Then, once we all agree that a comp feels right as far as thinking through the process, then we start prototyping, maybe building-out individual pieces that are new, and then start building out the entire feature. We’ll work with the engineering team to add the database tables we need to store the information that we’re trying to show, and just start building.

Justin Avery: Cool. I’m fortunate, I use it quite often, once a week. The admin interface is responsive, right? It doesn’t matter which size screen. [00:16:00] It’s not a fixed, rigid one, which I find a lot of administrative interfaces tend to be.

Jason Beaird: Right.

Justin Avery: When you’re coming up with the UI designs and stuff, do you have a strict mobile-first policy? Do you have an approach in that particular?

Jason Beaird: Our mobile policy and our responsive policy is pretty interesting. When we redesigned in 2013, the last redesign I was talking about, that was one of our goals, was to make the app responsive. The app was already fluid. It had been since the beginning. Since the beginning it was a fluid application, and we used a fluid grid. When we redesigned it in 2013 our goal was to make it fluid-responsive. We didn’t necessarily take a mobile-first approach, but we wanted to make sure that everything was accessible, down to phone size. That has been a little difficult because a lot of times you’re developing and working on new features thinking about it from a desktop perspective. Sometimes you’re checking on a table, but the phone size screen becomes an afterthought and it ends up becoming a QA support issue before it gets launched. It’s like, “Oh, it’s broken on this size.”

  The one thing that’s helped us a lot with that is actually the pattern library itself. When we started the redesign, in stead of starting with comps for the redesign, we started with the existing patterns we had and how we make those responsive. If we’re using one of our existing patterns, most of the time those will work fine down to mobile because we’ve planned the pattern to be responsive. We don’t have to worry so much about how it will look on mobile because it’s already coded to work that way. A lot of times when we’re adding new features and building new interfaces it becomes a bit of a maintenance issue.

  Then there’s some [00:18:00] things in the app that we actually have a separate view for phone size, for instance, creating a campaign, because CK Editor which is our WYSIWYG, HTML editor for building campaigns doesn’t work that well on a phone, at least the version of it that we’re using. To show a 600 pixel email campaign that you’re actually working on to edit in a responsive really much smaller interface, it becomes difficult. I would say we’re not mobile-first, but we’re very mobile-aware and trying to find solutions for those things that are still not quite there yet.

Justin Avery: There’s a MailChimp app that you can download from the IOS, from the store.

Jason Beaird: Right.

Justin Avery: Is that a separate, specific app? It feels as if it’s a wrapper to the web interface.

Jason Beaird: The actual MailChimp app is it’s own app. The IOS and Android version are both native apps that are not based on the MailChimp interface. They use the MailChimp API. We are working on an experiment API that’ll allow you to do more of the things that you do in an application, but it is a completely separate system. The mobile team is actually part of the product team that I’m on. We end up doing together quite a bit with them, so we try to keep things consistent across. We want it to feel like a wrapper. Both the IOS and Android versions are completely custom, native apps that are designed for that operating system.

Justin Avery: Cool. I was wondering, because, like I said, you’ve done well in terms of carrying the experience from one to the other.

Jason Beaird: Yeah. [00:20:00] The head of design for the product is actually over my team, and he was the head of design for mobile team before. Now he is managing design for the web apps and mobile apps as well, so we do have a consistent voice for all of those products.

Justin Avery: Cool. You were talking about going to engineering and creating database tables and stuff to be able to display certain information. A lot of the information in the admin stuff that is very tabular and is long lists and stuff, are there any challenges that you’ve been able to overcome and still being able to see or access all of that data on those smaller screens?

Jason Beaird: Yeah. We have worked a lot in trying to make, everybody’s been working on, making better, responsive tables, right? There’ve been lots of good posts about it. We’ve used a lot of the recent things that have come out to create our subscriber [table 00:21:03]. The subscriber table’s typically the biggest example of a table that you need to be able to see all the way across. In the mobile view you get a scroll box. If you’re looking at, for instance, a subscriber, you might just have first name, last name, email. That’s the typical lists of merge fields for a individual subscriber, but you can add as many merge fields as you want. You might have first name, last name, postal address, phone number, how you got into the web industry, check lists and check boxes, whether you’re a a designer and developer, UI person. The list goes on depending what merge tags you have.

We had to be able to make a table that can scroll to fit all those things down to mobile sizes. We have our own custom responsive table system that a couple of our guys, Alvaro [00:22:00] and [Marta 00:22:00] on my team, have worked on that quite a bit. I haven’t worked on that as much as they have. Yeah, that’s definitely a concern, is making things like tables and things that are normally extending way off the desktop screen work well down in small sizes.

Justin Avery: Part of the pattern library has the table stuff in there already. Is it something that someone can go and steal, borrow, see how well you’ve done?

Jason Beaird: I would say borrow away, at your own risk. Things change so fast in this industry. Best practices for things, specifically like responsive tables, change often. We try to apply things as fast as we can, but we aren’t as fast as some of the new front end techniques that are coming out. I would stay, steal liberally, but know that-

Justin Avery: [inaudible 00:22:58]

Jason Beaird: … we’re constantly changing as well looking for ways to do it better. We may not have the best solution, but right now it’s working for us and we’ll be updating it as we go along.

Justin Avery: Speaking of changing fast and iterating and the industry moving quickly, is there anything that you’ve seen recently that you’ve been like, “Yeah, that needs to be the next thing that we’re going to tackle.” Not even recently, but the next thing that you’re like, “Let’s put this into the app and the interface. Let’s solve this problem.”

Jason Beaird: A lot of the mobile patterns that have been coming up, or have become standardized for display of menus, we’re doing some things in the app, slide out a panel, designing on the Z index, having multiple elements that come in and out of the view depending on which mode you’re in. I feel like we’re not doing as good of a job as we can with that. At the same time, I kind of wonder how much we need the web app to handle that [00:24:00] mobile aspect, and how much needs to be put off onto existing apps.

  I was just having this discussion with Stephen Martin, the head of design at MailChimp. What is our goal for mobile support of the web app, and how much of it should be part of the native apps? Our original view was that you should be able to do everything in the web app, right? We’re the people that create the web app, so we want to make it as useful as possible. Even if you haven’t downloaded the app, but you happen to open a browser and login you should be able to do everything, right? Sometimes that’s not the case. Sometimes you’ll get a much better experience if it’s done in the native app.

Justin Avery: Yeah. In terms of just the usage of it, performance wise?

Jason Beaird: Right.

Justin Avery: That’ll be interesting to see which way you go with it. With regards to performance, that seems to be something which is the current in-thing, and it should have been for ages with websites in general, with the arrival of responsive design. It’s weird to say arrival. It’s been here for ages because we’ve built websites that can now work across all of the different devices and browsers and view ports, that we just, not we, a lot of people, just shoved lots of stuff in there. Of course, performance was one of the things which were then an issue with responsive sites. Not a responsive design problem, it’s a general web problem, and it’s the implementation of it. Are you guys focusing tons on performance? Have you got a performance team, or any bench marks that you need to follow?

Jason Beaird: We don’t have a performance team. I would say we’re always thinking about it, and we should be thinking about it more. [00:26:00] For a big, well-know location it’s really easy to sit on your heels and say, “Okay, everybody’s going to be on a desktop and have a decent internet connection, and all of those CSSs are going to get cached, anyway, right? We can make it as big as possible.” We’re trying as much as possible to cut as much of the CSS as we can, compress things. We use LESS and then compress our output as much as possible. We look for ways to reduce the number of requests on a page. Still, there’s a lot more that we could be doing for performance. Honestly, we probably should have somebody that’s focused specifically on performance because as a web app that is used outside of the desktop and outside of fast internet connections, it should be as snappy as possible.

  I feel like there’s a lot of things you can do to enhance the appearance of performance. It was really interesting, we just went through a redesign of the navigation of the app, moving the branding and the main navigation up to the top as a horizontal navigation and getting rid of the vertical navigation we had on the side of the app. We did quite a bit of clean up of our CSS. We looked at the load of a page before and after, and it wasn’t a significant reduction of kilobytes.

  We got tons of people telling us how much snappier it felt and how much and how much faster MailChimp was after this redesign. We just had to laugh because we felt like we were forgoing the performance and focusing on enhancing the UI. The changes to the UI actually had the effect of making it feel snappier and faster. It was interesting, but with that said, we do need to focus more on performance and, like I said, reducing more of our page load size and requests. We try to keep that as much as possible [00:28:00] to minimum.

Justin Avery: Yeah. I imagine it’s quite hard to monitor a web app for a front end performance, because it’s not really like a public URL that you can point something at and follow. Everyone has a different access kind of thing, almost. Somehow it seems different than just looking at a public website.

Jason Beaird: One easy thing to watch, especially if your version for each release is the output size of the compiled CSS, you can cut down the HTML size as well. It’s really easy to see that, “Oh, we cut 40k from the main style sheet with the changes and the cleanup we did on this last release.” Anytime that you can compile elements of the app that are used in a couple of places into a pattern, usually we get a little bit of savings here and a little bit of savings there in terms of file size as well since that’s one easy metric to watch, is the size of your CSS. Always reducing images helps a lot.

Justin Avery: Yeah. I think you guys are quite fortunate in terms of it’s a very visually stimulating site, but it’s not a huge use of images it never seems.

Jason Beaird: Right. Unless you’re looking at an email campaign that we’re working on that has a ton of images in it. Usually we don’t [inaudible 00:29:30] images in our interface that we’re loading. Even when you do have a campaign, we are serving all those images from S3 through, I can’t remember the service, it’s to make it as fast as possible as well.

Justin Avery: The CloudFront?

Jason Beaird: Yes.

Justin Avery: Yeah, that’s really good. The other thing I quite enjoy if I do a feature site of the week, [00:30:00] right, so that goes in the top, and I usually optimize that before I upload it into the campaign. Sometimes I forget, I just do a screen shot, and it’s like 1200 pixels wide, which is crazy. There’s a warning in the app, it just says, “This is 1200 pixels wide. You only need it to be 600. Maybe you should make it smaller.”

Jason Beaird: I believe the [inaudible 00:30:24] has a little [blurry 00:30:26] in boxes, you should re-size your images.

Justin Avery: That’s the other good thing. I do like the marker copy with MailChimp. You’ve got it nailed. Although, there used to be a page where you could stretch your campaign to see how wide it was, and you end up-

Jason Beaird: Freddie’s arm pops off.

Justin Avery: [Who 00:30:49]?

Jason Beaird: I said, and Freddie’s arm popped off.

Justin Avery: Yeah.

Jason Beaird: It’s too wide.

Justin Avery: You [tear 00:30:52] Freddie’s arm off. This is one of the reasons I loved using MailChimp.

Jason Beaird: [inaudible 00:31:00] I miss that feature a lot.

Justin Avery: Bring [crosstalk 00:31:02] back. Can I put in a feature request?

Jason Beaird: I wish we could. That joke just got old over time.

Justin Avery: Yeah.

Jason Beaird: It’s hard when a joke gets stale, you want to keep the fun and the attitude and the culture in the app. As things get old you have to pull them, and then you’ve got to find new ways to introduce fun things. We’re constantly looking for ways to introduce surprise and delight into the app. Sometimes it’s hard because you’re so focused on adding your very important feature that you forget to add some humor. We try to keep introducing things like that as well.

Justin Avery: Yeah, I think you do very well with those sort of things, so kudos to you guys. You mentioned using LESS. That’s for those that aren’t up to speed with-

Jason Beaird: You just dropped out.

Justin Avery: Oh, sorry. [00:32:00] I was talking about using LESS. For those who aren’t up to speed with LESS, or SAS, is a pre-processor for CSS, allows you to write CSS a little bit quicker and use things like variables and compress them. Do you use a tool for that like Grunt or [Golf 00:32:21], are there any other workflow tools that you use internally?

Jason Beaird: There reason why we decided to use LESS, one of our goals with the redesign of 2013 was to switch to a CSS pre-processor. For those of you that aren’t using SAS or LESS, the CSS pre-processor, it makes things a lot easier, especially if you have a large application with a lot of common pieces. You have things like variables and mix-ins that make it much easier to manager.

  We ended up choosing LESS over SAS mainly because the JavaScript library that we use, it’s called Dojo, they use LESS as the source theming creating method. Since we had our own custom Dojo theme for the library, it made since for us to use LESS instead of SAS. I’m kind of CSS pre-processor agnostic, I would say. It’s awesome as long as you can use one of them. We don’t use any kind of specific tools. We compile on our dev environments just like we compile on the production environment, our LESS down to one file so we can see it as it will be on production. Yeah.

Justin Avery: Cool. Are there any other JavaScript tools or plugins to aid your front end responsiveness?

Jason Beaird: No. The JavaScript library, I mentioned Dojo. It isn’t as intuitive as JQuery to pick up and use for a designer or front end person, [00:34:00] but it’s a very powerful interface. The widgets that they have, while somewhat bloated at times, are usually built responsive to begin with, so that does help us quite a bit. We don’t have any other JavaScript-specific solutions for making the site responsive. We do have a separate view handler that allows us to do things like I mentioned before about providing a view that says that if you’re trying to go into the editor on a phone-sized device, that it’s handled on the back end, just sort of a separate view for phone-sized interfaces. Really that’s about it. There’s nothing really specific on the front end or the back end that we’re doing differently. We try to make it as universal as possible.

Justin Avery: Cool. In terms of making things as universally accessible as possible and stuff, one of the most popular pages on the site and questions that I get asked for price-specific break points, or actually the most popular page on the site is Common Device Breakpoints, where I have a list of the different iPhones, the different iPads, the different Galaxies, the different Samsungs. I have a caveat at the top, it’s like, “Don’t use these please, but …”

Jason Beaird: “It will change next week”?

Justin Avery: Yeah. “These aren’t staying the same. Get away.” At the same time people-

Jason Beaird: We size to several different sizes and see how it will look. If it looks broken when you hit a certain size, don’t focus on break points. Focus on whatever size they happen to have the screen set to. That’s the best advice I can offer. If you get too focused on breakpoints and specific devices, then you’re going to be playing Whack-a-mole with your support.

Justin Avery: Yeah. That’s good advice. There’s a new site that came out a couple of days ago. I think it was [00:36:00] iamthefolds.com. Have you come across that at all?

Jason Beaird: I have not seen that. I’ll check it out.

Justin Avery: Yeah. It’s really cool. I won’t feel bad if you check it out now. You’ve got to be quiet. It was created by a guy, I think, Ian, I’m going to totally get it wrong. He’s @_iest on Twitter. It came from an article and a Tweet from Jordan Moore who we’ve had on this show before. It’s really cool. Basically, you visit the site and he writes to the database how tall your screen is, so where the fold line would be. When you visit the site it has a line drawn through the page for every single different height in pixels someone’s fold was. It’s crazy. He’s got-

Jason Beaird: Somebody’s fold is 234 pixels.

Justin Avery: Yeah, 234 pixels. The largest one I’ve seen is 2,732 pixels tall. That is a tall, tall phone.

Jason Beaird: There’s one there that is 3,112. Someone has a very tall vertical monitor.

Justin Avery: Yeah. I’m waiting for those 5k monitors to come out that someone puts on portrait.

Jason Beaird: That’s fascinating. I have not seen this before, but it’s very interesting. Yeah, the fold it’s very synonymous, right? For years and years now we’ve been thinking about the fold and telling people not to think about the fold. It kind of goes the same horizontally with break points. Thinking about the terms of device width, you’d have a very similar list of lines for the horizontal display of the devices that people are on. You probably get some groupings around desktop ideal widths and some around template ideal widths and some around phone ideal widths, but when you looked them all on parallel, you’d probably just see a bunch of lines horizontally. [00:38:00] It kind of goes the same with this. This ‘I am the fold’ site is fascinating. It does seem to be some groupings. There’s a thicker white area where you can see that’s the typical fold, but you can’t nail it down.

Justin Avery: No. There’s a whole bunch. It’s really strong between, say, 1300 and 500. It’s kind of hard to see anything in particular. One of the things he did say with this particular page is that if everyone comes on with a 768, or a 1024 fold line, it will only show up as one line. There’s no like, “It will become bolder because more people have it.” This is every possibility.

Jason Beaird: How many people have a browser that’s set to exactly 1024, 768? That’s not the way your browser works, even though that’s the way that we have been telling people to design for years now.

Justin Avery: Oh, exactly.

Jason Beaird: It’s like, “Oh, well think about somebody that’s on a 800 x 600 monitor.” Oh, I’m dating myself with that one. We’ve always given people specific pixel sizes of monitors to think about, but who has their browser re-sized to fill the whole monitor?

Justin Avery: Exactly.

Jason Beaird: Not many people.

Justin Avery: Not even just filling the full monitor. You might do, I’m sitting on a Mac now, and I’ve got a tool bar which takes up probably, I don’t know, 20 pixels, maybe 30 pixels? I’ve got a bookmark up there which pushes it down. You still can’t have a fold fold.

Jason Beaird: Then if you have Web Inspector open all the time like I do, then …

Justin Avery: Then nothing is cached ever.

Jason Beaird: Nope.

Justin Avery: I’m always like, “Why is this site so slow? Oh, I’ve disabled cached on Web Inspector,” really good, powerful tool. Oh, man I had a point about that at some point. It’s gone, it’s gone. [00:40:00] Oh, I know it was the thing-

Jason Beaird: We’ve gone off topic of responsive with thinking about the fold.

Justin Avery: I know. It’s more prevalent than ever, I think, with the fold thing. Oh, that was it. I’m going to get a bunch of responsive notebooks printed up shortly, and, fortunately, the guests on this podcast get a notebook. I’ll get one across to you one we get off this call.

Jason Beaird: Excellent.

Justin Avery: One of the things when I was building this site, I really like the Pelican Book site. I love the pelicanbooks.com, I think it is. It loads up the page and there’s maybe a 40 of 50 pixel space at the bottom where the background color will change. There’s a little bit of text which encourages you to move down to the next section. There’s also a button that has a click through action on the section that you’re at. Then you go to the next section and it’s a little bit more easier to go to the next section. It’s really well done, and they use Flex Box for layout. They also use the VH units for the view port heights unit.

Jason Beaird: Right.

Justin Avery: I’ve been playing around with that as well. I really like it. You can set a section to be 85 VH, and it will give you 85% of the viewable area within the view port, so you will always have a bit of space at the bottom.

Jason Beaird: That opens up a lot of interesting possibilities for designing interfaces that are really fluid and responsive.

Justin Avery: Yeah. With stuff coming, I could do it on the little notebook site that I have because, let’s face, 200 people are going to visit it, and most of them have state of the art browsers. You, on the other hand, have to accommodate a hell of a lot more. You have an application, you’re providing a service for people. Is there anything that you’re [00:42:00] really keen to check out and include, but it’s not quite ready? Is there stuff that you would really like to see come up and available through something like CSS that would solve some of your responsive problems?

Jason Beaird: I’m thinking, but I know I’ve pointed out a few of those things. Looking at future [inaudible 00:42:18] and things like that. We’re fortunate to only support IE9. I say that, but when I started, we had just dropped I86. I was so excited not to be designing for I86 and more. I had to deal with 7 for along time, and then stopped actively supporting 8. Having a lot of users and having to support older browsers it really limits a lot of what you can do. It’s hard to think of a specific example.

  One thing that I realize that we are not having to worry about anymore that we had to worry about with IE8 was setting background size. For [retina 00:43:03] devices that’s critical for using sprites in any kind of way that looks good. I just, for a future I was working on for the next release, I was creating a 2X sprite and I was thinking to myself, “Oh, I need to create a 1X version of this sprite sheet for IE9,” and I went back and said, “Oh, IE9 supports that, so I won’t even have to worry about that anymore.” It’s nice when you realize things like that have happened, that it’s something that used to bug you, it used to be an extra chore that isn’t there anymore.

Justin Avery: Yeah. Totally. I’m just wondering, coming up to about time that I’d have to start wrapping things up, or at least stay thinking about the fact that I have to wrap things up. I have a couple of questions which people have [00:44:00] sent through. Actually, I have one question that someone has sent through the newsletter and asked me about, which I thought I might pass on to you and see if you have any thoughts on the subject. Also, just to warn you, I’ve got a question from our previous guest. Each week the guest has an opportunity to ask the next guest a question. You don’t know who the next guest is going to be, but you’ll be able to ask them a mystery question. Yeah, you can ask them anything. We’ve had some strange ones, we’ve had some good ones.

  The first question was someone that sent something through and it was MJ. They’re asking, “Wondering if you can offer some tips on selling mobile-first workflow clients. Our clients have fully adopted and realize the necessity of responsive design, but they insist on seeing a desktop first in it’s entirety to sell it up the food chain for sign off.” This causes issues in the future because they then have to address mobile very hastily, and it’s either a huge development cost, or the website looks rubbish. Do you have any tips around trying to sell a mobile-first approach?

Jason Beaird: It’s an interesting question because we kind of had to do that with the last redesign. I don’t feel like we have to answer up the chain of command to do anything that we do on the application, but it took some justification that said, “Listen, the app needs to be responsive as one of the goals for the redesign.” Especially with clients, I don’t know if you need to deal with mobile-first, but you definitely have to make the case for making mobile a priority with the project. That’s one of the best things about going from client-based webdesign to working on a big internal application. I’ve been in that situation for 5 years now when responsive design wasn’t quite a thing yet. [00:46:00]

  Even in 2010, 2009, when I was doing client-based web design work, we had to convince clients to think about mobile. We did a website for a regional airport and we told them, “Listen, a lot of people are going to be accessing your website on the phone. It needs to look good on phone.” At the time, we ended up developing a separate site for the airport on mobile. That was us pushing the client to do that. I feel you’re in the same boat now with the responsive. It’s kind of an obligation for you as the person creating the site.

  You’re going to make more work for yourself if you don’t push the client to think about responsive from the get-go because you’re going to be the one maintaining that site or application. If you can get that out of the way at the beginning of the project, it’s much easier than going back and trying to redesign something to make it mobile-friendly or responsive. Like I said, I think trying to make a client think mobile first is probably hard to do unless you’re a site or application that people are looking for on their mobile device the majority of the time.

Justin Avery: Yeah.

Jason Beaird: Getting them to think about what the audience is, will they be accessing your site on a mobile. It really depends on the application and the purpose of the site as to how you sell it to them.

Justin Avery: Yeah, because there’s nothing wrong with MJ developing it for a mobile-first, but then still just sending through the desktop version for the sign-off, right?

Jason Beaird: I think it should be an upfront thing, otherwise you might be doing work [00:48:00] that you’re not getting paid for, right?

Justin Avery: Good point.

Jason Beaird: You’re not going to waste your time. It takes some time to think about it from a mobile-first. You want to let them know that that’s a priority of yours, and if they want to have the site developed, you’re going to do what’s best for their users, not for them, and you’re going to advise them to do what’s best for their users, not for them. It’s usually in the client’s best interest to take that way as well.

  You have to find the angle for what makes it the most appealing for the client. In most cases that comes down to financial. The little bit of extra time to make something work well on a phone will payoff if it’s e-commerce related. If you’re trying to drive traffic to a business, in most of the cases people are going to be accessing it on the way there. If you’re trying to drive e-commerce traffic, they’re going to be looking at when they have lull time on the train. Making the case for responsive I think is pretty easy these days. It’s not so much of an [inaudible 00:49:08] case anymore, it’s a standard.

Justin Avery: No, that’s actually a really good point, then, for MJ to go and make that case around why it’s a business benefit. Like you said, is it going to sell more when it comes down to money, right? That’s what clients respond to. “Will it make me more money, or cost me more money?” They don’t mind doing it if it costs them more money and makes them more money at the same time.

Jason Beaird: Exactly.

Justin Avery: Oh, well. That’s good, I like that. The next question was, actually, from our last guest, which was Kathrine [Farman 00:49:51]. It’s a relatively easy one for you to get into 2015 which is, “What are you most [00:50:00] excited for in 2015?” This, actually, wasn’t specific to web development, or responsive design. She was just, “What are you most excited about.” Cover either.

Jason Beaird: I am most excited about in 2015 about hover boards because ‘Back to the Future’ said that we would have them, and that should be coming along. In terms of responsive design …

Justin Avery: The hover boards, though, wasn’t there a Kickstarter campaign for an actual company that did hover boards in-

Jason Beaird: It was, I believe it was called Hendo that was doing-

Justin Avery: Yeah.

Jason Beaird: I saw that at Kickstarter and I was kind of fascinated. I’m such a ‘Back to the Future’ geek.

Justin Avery: Me too.

Jason Beaird: Really, this is kind of a cop-out answer, but I’m excited about the future. Seeing the things that are coming, even Microsoft’s latest announcement of new interface ideas, new devices, new screens and new places where our work will show up. In some ways I think it makes a lot of people poop their pants, but for me it just gets me excited about the possibilities of what we can do with those applications. I’m excited to see how things will evolve past mobile, past desktop into new territory.

Justin Avery: Yeah.

Jason Beaird: Is that a legit answer?

Justin Avery: Any answer’s a legit answer.

Jason Beaird: Hover boards, that’s my answer. Hover boards.

Justin Avery: It’s your answer. Any answer, no, that is cool. I agree, I think it’s very exciting what’s going to come up and how things are going change. Everything changes so quickly and in weird directions. It should be another good year. Back to table-based layouts.

Jason Beaird: Oh, boy. That’s where I started.

Justin Avery: It’s funny, you kind of go back to it. You started with [00:52:00] table-based, get into email apps and all the emails are sent table-based.

Jason Beaird: You don’t get this [not 00:52:05] thinking about it ever.

Justin Avery: It’s evil. You’re paying penance for something you did in one of your earlier sites. Having to-

Jason Beaird: Fortunately, I’m not doing table-based email designs. That is Fabio, and Alex is working with him on creating new email patterns for responsive. It’s weird, it’s backwards table-based HTML that is responsive for the email clients that support it. The things that they’re doing there is just fascinating. It’s like-

Justin Avery: Is that going to be something that’s going to stick around for a fair while? Are we going to be in 2016 and still table-based, it’s here for the long run?

Jason Beaird: Fabio can probably answer that better than I can because he’s been watching the support of email clients go up and down. When will Outlook disappear is the question of whether or not we’ll be able to get rid of table-based email. He would be able to answer that question better than I can. I really hope it goes away soon so we can start designing emails the same way we design regular front end applications and sites.

Justin Avery: Yeah, that’s funny.

Jason Beaird: I don’t see it happening soon. In the meantime, we’re using MacGyver methods to duct tape and bubble gum things together in ways that make them work well on mobile devices, but still working backwards email rendering clients like Outlook.

Justin Avery: Let’s design websites like it’s 1999. Go back to the old school. It will be interesting. I also think things like Gmail have an effect as well where they did something weird by stripping out CSS because their email essentially is a web [00:54:00] app anyway. It has some funky things where it has to strip any styles out. I’ve always had weird things happen with Gmail, the mail client and even the app client as well.

Jason Beaird: The thing about it in terms of designing like 1999, it’s like playing Mine Sweeper, dealing with all these different email clients and things that could potentially go wrong.

Justin Avery: Just bombs everywhere. The last thing is, basically, what’s your question for our next guest, Jason?

Jason Beaird: I’ve been thinking about that since you mentioned that I would have to ask something myself. I think the one thing that I would ask is, because you asked about the future, what’s the single most interesting current mobile pattern that’s come out, since I’m kind of a pattern geek. What’s the most interesting mobile interface interaction pattern that you’ve seen? That should be a fairly tough one that you can’t answer with just hover boards.

Justin Avery: I can have a list of answers that people aren’t allowed reuse, so you’ve now taken hover boards from anyone else that want’s to use it. Yeah, I’ll try and get someone to ask a ‘Back to the Future’ question then and that will make it very difficult for someone to answer without being able to use the word hover boards.

  Jason, thank you very much for joining on the call today. I found it really interesting. Like I said, I love the stuff that MailChimp does, and it, effectively, is what you do on a day-to-day basis. If anyone wants to get in touch with you, or follow what you do and read your blog post that may start again soon, how do they get in touch with you or find you on line?

Jason Beaird: First off, thank you so much for the invite. It’s people like you and your audience that are thinking about responsive design that shapes what we do as well at [00:56:00] MailChimp. We try to keep an ear to the ground as far as what’s going on and what we can do better. If anybody wants to follow me personally, I’m at Jason Graphix on Twitter, and that’s my website domain as well. The UX newsletter is where we write about MailChimp-y things, and that is the uxnewsletter.com. We recently created an e-book from the most popular articles that we did last year, and that is the uxreader.com, or, actually, uxreader without the dot com. We were selling it for $5 with all proceeds going to charity, but we just about a month ago made it available for free, so anybody can come and download it and check it out.

Justin Avery: Awesome. Can you still chuck in fiver if it’s going to charity, if they appreciate, or it’s just free now?

Jason Beaird: Yeah, we do still link to the charity that we were benefiting. We would definitely appreciate it if people went in, donated to that non-profit organization.

Justin Avery: Who is the non-profit, just out of …

Jason Beaird: Now I’m drawing a blank.

Justin Avery: That’s all right, go to the Uxreader.

Jason Beaird: It is Rails Bridge.

Justin Avery: Ah, cool.

Jason Beaird: They’re an organization that helps women and minorities learn to code. It’s a very interesting organization.

Justin Avery: Very cool. Actually, everyone should just go to the uxreader.com because it’s just a lovely, really pretty, simple site.

Jason Beaird: We had a-

Justin Avery: And responsive.

Jason Beaird: … campaign that went along with it. It was a responsive email that Fabio, the email developer I mentioned, created that looked exactly like the site.

Justin Avery: Very cool.

Jason Beaird: We’re trying to have fun and do things that are … It’s kind of hard when you’re stuck in an application that you’re stuck doing things a certain way to be able to experiment and do fun things. It’s products like this that allow us to try new things, which we try to do that often. [00:58:00]

Justin Avery: Yeah. Also, it’s just good to see you putting that sort of stuff up, sending a newsletter out about the things around UX. I’ve subscribed to that. I think it’s an excellent newsletter as well, and then putting them all into a nice little downloadable pack as well. It’s great. You guys do very well, and you do well for the community as well, so thank you. I think that is about it. Is there anything else you want to mention before we sign off?

Jason Beaird: No, that’s it. Thanks for using MailChimp for the past 146 weeks.

Justin Avery: I can honestly say it has been an absolute pleasure. Freddie the mascot, for those that don’t use it, every Thursday night, or Friday morning depending on how late I’m up, a little high five pops up every time I hit send on the MailChimp. I hear a whoosh sound as I hit the sent as well. Yeah, I enjoy using it thoroughly. Thank you for designing such a fun app online for being able to do, mine’s not really a business-y thing, but it’s kind of. Everyone uses it for different reasons, and it’s fun to use, so thank you.

  Thank you also to all of the listeners for joining in. Feel free to rate-up the podcast on iTunes and share it with your friends if that’s what you would like to do. I’ll join you again next week with another edition of Responsive Design podcast with all things responsive and another special guest as well. Thank you very much, Jason, for joining us, and thank you everyone for listening. Cheers.

Jason Beaird: High fives.