Building for Mobile

If you’ve paid even a little attention to web development in the past few years, you’re aware everyone’s going cuckoo for mobile-friendly, tablet-friendly web sites. Or more accurately, nobody wants to be caught flat-footed by the question “How does it look on mobile?” And rightfully so as more and more people are using smartphones as their primary way of browsing the web. In fact, there’s a good chance you’re reading this article on a smartphone right now.


Baseline Knowledge

If you’re even a little bit nervous about the term “responsive design” and what it means, this section is for you — otherwise, skip ahead to the next section, where I start giving more hands-on advice. The classic components of a responsive site are fluid grids, responsive images, and media queries. Using a fluid grid means that as the browser scales, so too do the columns of content on the page you’re viewing. Using responsive images means delivering the right image to the device requesting it – if you’ve got a retina display, you’ll get a high-res image; small display, smaller image. And finally, media queries are how you can pick and choose who you deliver styles to. For instance, say you want to make a heading 48px tall:

h1 {
    font-size: 48px;
}

You could wrap this rule in a media query to only apply that style if the visitor’s browser viewport is at least 400 pixels wide:

@media (min-width: 400px) {
    h1 {
        font-size: 48px;
    }
}

Of course, more elaborate styles can be wrapped in media queries, and the media queries themselves can target based on things more interesting than just viewport width — things like device orientation and color support. But the general concept is that you can target your style rules based on browser conditions.

Know Your Audience

Knowing how much traffic you’ve got coming from non-desktop machines should help make it even more obvious about how important mobile is, but it can also let you know what devices you should start your testing with. My company saw a rise in traffic coming from iPhones, so we started there since it represented our biggest mobile device cohort. Another benefit of knowing how your audience breaks down is that it can help you prioritize bugs in terms of audience impact. This doesn’t mean it’s okay to leave your lesser represented devices in the dark, but it can help keep things in perspective when you have limited time to spend on development. Responsive design should be about delivering an experience that’s accessible to all your visitors, not spending all your time making sure all your visitors get the same exact experience. Brad Frost said it best: “For time and budget reasons, we can’t make the best experience ever for every connected device, but we have a responsibility to provide a decent experience for those who wish to interact with our products and services.”

Resist the urge to target specific device resolutions

If someone asked me “What resolution should we target our media queries at for a tablet experience,” my first instinct would be to search Google. I’d come back with some answer like “768px” that I’d have retrieved from a data table someplace. But the problem with that kind of answer is it doesn’t consider what your content looks like. Instead of trying to tailor fit by device, go to your desktop browser, load your page, and resize your browser down to as small as you care to support. Start by making that look as good as you can — or as the responsive development maxim goes, “start with mobile.” Now make that window bigger until the page looks awkward. If you’re using Google Chrome and your dev tools are open while you resize, your viewport dimensions will pop up in the corner of your browser window. There’s your answer, that’s where you need your first media query. You need to deliver styles before you hit that resolution. Your content should flow from one elegant layout to another without any weird gaps in between. Remember: Your goal is a website that looks as good as can be on whatever device is viewing it. Design for your content, not specific devices and their resolutions.

How to Not Be Awful

Sometimes it’s difficult to know how to steer your conversation in a useful direction. To get some ideas about what designers like and don’t like about developer feedback, I sat down with web designer Chris Chiusano to ask about what makes for a productive conversation between developers and designers.

IM: As a designer, what are you looking to hear? What do you hate when developers say, what do you love when developers say?

CC: Just in general when someone’s like, “This is stupid,” “I don’t like this,” or “We can’t do this,” without offering up some sort of helpful feedback. What I always like is where things come up and someone says, “I don’t know if you realize, but we’re using seven different variations of this font. It’d be a lot cleaner if we tried using this. Does that work for you?” or “This isn’t the best way to do it because x, y, and z. And if we do it, this is what could happen down the line.” I like being able to make decisions off of real data. For example, on the signup form a long time ago, it was, “Yeah, we can add that inline functionality when you click in, but it’s going to be a lot of JavaScript and on mobile it’s going to really slow down the speed.” And so hearing something like that was like, “Oh, maybe we don’t want to do that.”

IM: Right, so providing useful non-emotional things.

CC: Yeah, things that are important. And I think the other thing is, I look to a developer to offer a better way to do it. If they know a better way to do it, great — if you can be creative on the technical end, that’s better. I only know what I know.

IM: What if the developer doesn’t have a good alternative? Without having a solution in mind, what do you think a good way is to get into that kind of conversation where you’re working together to think of alternatives?

CC: I think as a group, trying to isolate what the problem is. If you can’t offer up a solution, if you can say specific things of why it doesn’t work and you can be honest, you can say, “I’m not really sure how to fix this” — but I think if you come up with “Here’s why it isn’t working,” it’s easier to brainstorm together.

What Chris is describing is an environment dramatically different than one where you get mockups in and send pages out. Use your technical expertise to complement your design team’s judgment and experience: deliver pages together. You can read more about this in my article Stop Waiting for the Responsive Mockups!

Tailor Your Framework to Your Needs

Twitter Bootstrap’s default media queries are very obviously based on specific device widths and common resolutions. It’s a lot more convenient (and impressive-sounding) than just throwing apparently random numbers around. It’s a great starting point, but Bootstrap was built to be a beginning to a conversation, not the end of it. Your framework won’t have all the answers, and you’ll likely need to modify whatever framework you choose or make significant design concessions. Make whatever changes you need in order to make your framework fit the project your team is working on. It’s especially important to document those changes so that if you want to upgrade or modify the framework later, you’ll be able to remember what you need to put back into the upgraded version. If you can make that documentation visual, it can turn into the start of a style guide for your designers and developers to share.

Look Around You

If you find yourself struggling with some kind of design or development issue, look around to see what other people are doing in similar situations. Keeping up-to-date with what’s going on in the industry is a crucial part of staying relevant, but it’s also a helpful source of inspiration. My personal go-to for new tips and techniques is Web Platform Daily, but I also love Twitter for its brevity. A site that popped up about a year ago, How To Keep Up To Date on Front End Technologies is full of ways to stay current, and includes a few names to get you started if you decide to take the Twitter route. Learning the specifics about what other people are doing with their projects can help give you ideas about how to go about solving similar problems on your own site. Granted, there’ll be plenty of approaches that won’t make sense for what you’re doing, but maybe they’re close enough that your imagination can fill in the blanks.

Another part of being aware of what’s going on means keeping up-to-date with what’s going on with various language specifications. If you aren’t keeping up with that conversation, you might find yourself reinventing the wheel or just missing out on something really cool that could make your site more accessible or easier to maintain. For example, consider the draft Media Queries Level 4 light-level media feature, allowing you to deliver a different color scheme based on your visitor’s lighting environment. There’s a video of a JS-emulated example of that concept using device API’s to fill in the gaps. Can I Use? is a tremendous resource for finding out how widely supported these new features and API’s are.

A very basic example of where we’re taking advantage of HTML5 at Constant Contact is our trial signup form, where we use the input type of “tel.” Devices can take this cue to show a telephone keypad instead of a QWERTY keyboard. But my very favorite part about all this is that we aren’t adding any extra overhead or doing anything particularly clever to get that functionality; we’re just following an old and very well-supported recommendation provided by the W3. Device makers and browser vendors are doing the rest to help their users (and ours.) This is the kind of collaboration where everybody wins.

Responsive is More Than Just Resizing Your Browser Window and Saying “It’s Responsive!”

The first thing that jumps to people’s minds when they hear “responsive” is screen size, but there’s so much more to it than that. Go take a look at some HTML5 device API’s and consider the kinds of experiences we can tailor to a visitor. Battery status API? Vibration API? Ambient temperature events? There’s a lot of room for our imaginations to run wild here. What kind of clues are your visitors giving you to offer a more relevant experience?

But there are more pressing and practical matters at hand; the responsive conversation should include things like bandwidth. Not everyone has a reliable way to get to your content. For simulating a slow network connection, you can use a desktop tool like Charles Proxy to throttle your bandwidth to match what you could expect with poor coverage. Charles Proxy is useful for all kinds of network traffic analysis and it can also help you to track down what kind of bottlenecks your visitors encounter when they try to view your site. In any case, being responsive should mean considering everything your visitor has access to.

Be Smart About Touch Screens

If a visitor is using a touchscreen device that doesn’t support hover, make sure you aren’t trying to send important cues with hover. You can (and should) find out if they’re using a touch screen device by using a feature detection library like Modernizr, so you can provide those same cues some other way. Also, if you’re trying to hook an event listener up in your JS, you may find that the “touchend” event is more helpful than the browser’s “click” event; some browsers wait 300ms after a click in order to wait for a double-click.

Okay, Enough, Go Make Something!

Hopefully this article has inspired you to look at your site in a variety of different browsers and devices, considering all the different things that should go into building a good website. It’s not just a matter of adding Bootstrap to your site, although that’s a fine place to start – the real important thing is that you start. There’s a lot of very smart people making things on the web; people are writing thorough and enjoyable documentation, feature-rich specifications, handy APIs – and useful, accessible, responsive web sites. Go join them and see how easy we can make it for everybody to do everything.

Show your support

Clapping shows how much you appreciated Ian MacIntosh’s story.