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- and tablet-friendly web sites. Or more accurately, nobody wants to be caught flat-footed by the question “How does it look on mobile?” because 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.
Some baseline knowledge
If you’re even a little bit unsure of what the term “responsive design” means, this section is for you — otherwise, feel free to skip ahead to the next section for 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 your site gets from non-desktop machines should not only 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. For example, we saw a rise in traffic coming from iPhones, so we started there since it represented our biggest mobile device cohort. Knowing how your audience breaks down can help guide in prioritizing bugs and features in terms of audience impact.
This does not mean it’s okay to leave 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 is about delivering an experience that’s accessible to all your visitors, and not about 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 targeting specific devices
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. 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 discuss 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.
Chris is describing an environment that is dramatically different from one where designers send in mockups and developers send out web pages. As developers, we need to use our 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
The media queries used in the Twitter Bootstrap framework are 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 a 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 not only crucial to staying relevant, 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.
Stay up-to-date with what’s going on with various language specifications. – if you don’t, 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. Here’s a video of a JS-emulated example of this 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 W3C. 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 resizing your browser window and saying “It’s responsive!”
The first thing that comes 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?
Being responsive to bandwidth
But there are more pressing and practical matters at hand; the responsive conversation should include things like bandwidth. Not everyone has a reliable high bandwidth connection 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 touchscreens
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) use a feature detection library like Modernizr to find out if they’re using a touchscreen device, so that 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 before sending the event in order to wait for a potential double-click.
Okay, enough, go build something responsive!
Hopefully this article has inspired you to look at your site with an eye toward its responsiveness. 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 are a lot of very smart people building 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.
Leave a Comment