Episode Sponsor:
JM: Welcome this is the very first interview on Web Payload and today's guest is the hugely talented and all round nice guy Brad Frost. Welcome Brad.
BF: Thanks for having me John.
JM: Can you tell people a little about yourself both professionally and your other interests?
BF: I'm a web designer from based in in Pittsburgh Pennsylvania in the States, for those in Europe which is 6 hours West of New York City, smaller city which is great and a wonderful place. I was Born and raised here but was in New York City working in agencies and RGA and now i’m on my own and do a bunch of different things. I do front end development, consulting, workshops, speaking, i keep busy! I live here in Pittsburgh with my wife and my dog Ziggy.
JM: Great so this is going to concentrate on mobile navigation and the first question is what are the biggest pitfalls and things to watch out for in a mobile nav?
BF: Navigation on mobile web experiences is a tricky beast especially when we consider responsive web design (RWD) and a more traditional horizontal menu and collapsing it into a small screen where you don't have that luxury of space and spreading it out in a horizontal line. I’ve been doing a lot of thinking about it and the main goal is to find that balance between accessibility and in being there and simultaneously be tucked out of the way. It’s there when you need them but its cool enough not to get in the way. Especially in a lot of responsive sites that's one of my biggest frustrations in sites that take up a screen and a half of navigation on a mobile phone. At the end of the day people are not coming onto your site to stare at the navigation, they are coming for your core content. So that's the biggest thing that i see, is the navigation burning up a whole lot of screen real estate. It’s not to say that its not important or anything and the user might want to get to the website and pivot right away but there's a mini mantra in the community by people like Luke Wrobleski and Jeremy Keith saying “Content first navigation second” where we are trying to serve the content first and foremost and give the user the option to pivot after they have glanced over the content.
JM: You have a fantastic resource on your site with some patterns, can you go through some of the most popular?
BF: There are are about 100 different ways to slice navigation and really with any interface patterns there are a 100 different ways. On my blog i wrote about some of the more conventional ways that were emerging. In order of popularity there's the do nothing approach where basically you have a couple of links and it stays as a horizontal list and that's good for navigation that only contain 3 or 4 links. You might be able to squeeze them onto 1 line but eventually that's going to wrap onto a new line. So it doesn't scale well but its super easy to implement and there's no Javascript its just HTML. So that's certainly a popular one.
One of the other options is collapse the horizontal list into a form menu but its a little awkward. You see a form menu in a place where you are not used to seeing a form. While it technically works its an awkward interaction.
Another one that is interesting and guys like Luke Wrobleski popularized where you have the navigation in the footer, so again content first and navigation second approach, and in the header you have a link that jumps down to the footer. It clears up a lot of space in the header and gets people to the core content faster. My biggest issue with that one is that its pretty disorientating for the user, they tap a button and theya re in the footer of the website! So i think of it as a clever development technique but there’s no javascript involved and its well supported but the awkwardness of jumping them into the footer they are not going to make that connection.
So building on that pattern of content first navigation second is the something i call the toggle which is a common approach seen on StarBucks and Microsoft. Where you tap an menu icon or it may say Menu and it slides the rest of the content down and it exposes the navigation. So it’s a nice little toggle where you can expand and collapse the navigation list. I really like that as its eloquent and it slides down, it keeps the user in place, its still tucked away but it exposes the nav as you need them. So that's my go to where you have this toggle and you can collapse and hide it behind an icon. It’s just a tap away and it keeps the user in place. You need to watch out for and for any other pattern that requires Javascript like the left nav fly out pattern seen on FaceBook, where the left nav flies out like a tray using an off canvas technique or similar. The thing to watch for is when tucking these things away and triggering with Javascript is you have to account for when Javascript fails and Stephanie Rieger wrote this great article when Obama released his responsive site campaign site they were utilising the FaceBook like slide out but she tested in all these devices and it worked in 2 devices but didn't work in about 100 so the site was left without navigation. That's not good obviously. So when you are showing and hiding something conditionally you need to watch out that it degrades gracefully. The default needs to be so that the user can navigate your website. Those are most of the popular patterns, there have been a few that have come onto the scene and i pay attention to those but fall into one of these categories.
9:50JM: So you talked there a little about the icon, and in most of the sites i’ve seen are using simply 3 horizontal lines, is that now seen as a convention? Do you need more than that or what’s your thoughts?
BF: It’s really interesting, its lovingly called the hamburger icon, those 3 horizontal lines, indicating a menu and its become the defacto standard. Your seeing it all the time, even on Mac OSX, in Chrome and it’s gaining a lot of traction and as far as popularity goes. I’m personally a big fan of spelling things out and i will actually say menu or navigation or something like that. Tim Kadlec on his site has a really nice combo, so there are the 3 lines and then there is “menu”. I really like that as it associates the icon with what it really does. It’s left to the jury but i recently worked on a project but when just saying “menu” got more engagement so that’s interesting.
11:50JM: Yeah makes sense, so if we take an example and trying to retrofit a mega menu, one of those huge menus, on a desktop, into a mobile nav version? What’s the process and some of the potential technology you could use there?
BF: Its interesting, when i wrote my original post about nav patterns, i had people immediately jump down my throat and say “Well i have 17 layers of nav and what do i do about that?” My immediate response is don’t have 17 layers of navigation. One of the great ideas about mobile is that it forces us to focus and to re-evaluate of what it is we do and what people are actually using on our site. So any project like this isn’t just about translation but its about revisiting your content, your hierarchy, your everything. You go through analytics and in the 70 links people were clicking on 5 of them, so then we want to reprioritise that navigation and to bubble up what people really care about. We found some that people just don’t click at all. So mobile is a really good opportunity to reevaluate your navigation.
The other thing to say is that you sometimes have complex navigation say a university, a retailer, or you are just a massive organisation that has a lot of moving parts and it’s not possible to whittle it down to 5 links. While there are patterns available one of the most important things to do is to prioritise search. Instead of forcing users to go through this Russian nesting doll and sifting through your navigation, give users the opportunity to search for what they are looking for and get to it easily.
So as far as some of the patterns go for complex navigation with mega menus and big sub navs my go to pattern is what i call the multi toggle where it’s just nested accordions. So you tap on the menu it drops things down, the user is then able to scan over the parent categories and then when they want to expose deeper categories they click on that. Microsoft does a good of that, it drops down then you have products then it exposes 100 different Microsoft products but it’s nice as the user can scan things as a glance and its nest-able, although if you did have 17 levels of navigation i wouldn’t encourage it.
There are a couple of other patterns, i worked on a project earlier this year and utilised something that i call skip the sub nav. Basically a lot of of the content on mega menus is repeated from the landing page content, for example you click on products and that might take you to a products landing page where it lists out all the products. So it’s a little redundant to include it in a mega menu. They would click products and go directly to that landing page and select a link there. It’s a little less efficient but you don’t need to deal with these mega menus and stuff like that. So that’s an interesting pattern.
The third one i really like is one that Sony uses on their responsive site. I like to call it the old right to left. You tap and it exposes a list of links, then when tapped it does an animation from the right to the left where it slides out, so you drill down into the navigation with this right to left animation pattern. I really like that as a lot of mobile operating systems have that built in, in ioS and Android when you tap in setting it will drill down in the options in this right to left panel based navigation. So that's pretty familiar to a lot of people. The things that i get concerned about with a pattern like that is that there is a lot of moving parts with the animation and being notoriously choppy especially on Android devoices. Anything i see moving on a website i always say “Needs tested, needs tested” because the more moving parts you have the more likely something is to break. It’s not necessarily a negative but it’s a good idea to test that in as many environments as possible. Complex navigation is a little more challenging but i think its doable.
18:10 JM: I think recently there has been a bigger focus on performance, there were a lot of people just chucking things in there, but now we have started to realise and you can’t just stick stuff in there. It might run fantastically well on a new iPhone or a cracking browser and OS but it’s not going to run in something that is degraded in software and similar. It’s good that we are starting to focus on that as there's still a lot of websites that i see out there with performance issues.
BF: Yeah i think in the first few years of responsive design we were getting our bearings straight as far as layout goes and how we use media queries and all that stuff. As time goes on, we are starting to realise that these performance problems which have actually been there forever and they are aren't going away. There average web page is now a meg and a half and it’s increased 28 percent since last year, which is just bonkers, but we are using the web on these slower networks, we are on Edge and 3G and crappy hotel wifi. These issues that have always been there are starting to boil over which fantastic because we are finally able to have these conversations about performance, and its something that i talk a lot about, performance through the lens of design rather than through development. I’d always get frustrated although technically i’m a developer, as any time you are talking about performance you get into futures expires headers, gzipping and minifying and all this technical jargon. It’s like “no no no everybody , your clients, the people running the project, the designers working in PhotoShop. Everybody needs to be on board with performance and talk about it in a general way and talk about the business reasons, the design reasons, about why performance really matters.
JM: Hopefully got Tim Kadlec coming up on another interview which will be focused on performance.
BF: That’s fantastic, he recently just gave a great talk in Germany, it was so good and again it was all about talking about this stuff with your team mates and get them to care. It’s not just a technical consideration but a design consideration. Really looking forward to that one.
21:25 JM: What’s the biggest thing you have learned recently in a mobile project?
BF: Oh Jeez, A lot the things i have been focusing on and trying to get better at are, is not so much to do with technical development but how we talk about and show clients things and convince our team-mates to do the right things and work better together. This year i had the extraordinary experience to work with a bunch of super smart people Jeniffer Brook, Josh Clark, Dan Mall, Jonathan Stark on a few projects where we were really able to work together in a way i have a;ways considered to be ideal in my head. We are making the best use of everyone's time, respecting their time and talking openly with the client and not doing these big reveals and coming back in a month and saying tada here’s what your website is going to look like but including them in the process and it’s easily the best thing i have been learning this year is how to work together, across disciplines, how to include the client in conversations, how to de construct an interface to your team and why that sort of stuff matters. Doing a more systematic redesign on the interface is a much better way for the design process and not just for the current process but for long term, establishing something that can very much serve as a foundation going forward. I had the ridiculous opportunity to work with some people that i have the utmost respect for.
24:00JM: Great, fantastic, some great advice there. Getting off the mobile navigation but a responsive question. I know it’s one that is still open in my mind. I see a lot of developers using ems over pixels in their media queries. What would be the benefit of that?
BF: It’s interesting, we have been moving away from pixels while styling everything else, layout with percentages and ems, padding and margins with ems and rems. Fonts with rems and other relative units which is fantastic but suddenly we get to our media queries and they are still stuck in these pixel values. I think that why it’s happening is that its a transitioning time and we talk of our devices being talk about our devices being 320 pixels wide or 768 wide. We don't talk of them as being in relative units. So i think that's why its still happening. So we should start using ems for our media queries as we are using them for everything else but they also have a really nice accessibility where whenever you zoom. Whenever the user changes their zoom value, me personally, i like sitting back in my chair and reading articles and stuff like that. So i end up going [command ++] all the time on any website really just to read a story a little better. It’s not that my eyes are going bad, although it does help those people with low vision. But whenever you write your media queries with ems the browser listens to the users zoom level, so as you [command ++]. So as you zoom in, if you zoom in far enough it will leave you with a nice single column zoomed in reading experience. I actually just published an article], Lyza Danger Gardener published a really great article called The ems have it - proportional media queries for the win. They are using it on their site and i made a little animated gif of how i zoom in and change my user zoom settings what happens to the layout. It basically just grows and then eventually the side bar collapses underneath the content leaving me with a super zoomed in mobile view which is pretty cool!
JM: Great i’ll try and put all these fantastic links in the show notes. So that’s pretty much it Brad, how do people keep up with you?
BF: I’m pretty much on Twitter all the time. I’ve been trying to blog a bit more lately. Those are the two main areas where i am active and but i’m mostly on Twitter. It’s pretty good!
JM: Big thanks Brad, thank you very much.
BF: Thanks very much John i really appreciate it.
