A handful of the many screens your responsive designs must handle. Photo: Ariel Zambelich/Wired.com
Building responsive websites can be daunting. After all, instead of just one desktop layout you’re creating at least two, probably three or even four layouts to handle different breakpoints and screen sizes. That means considerably more work, which can feel overwhelming if you don’t have a good plan of attack.
One of the better plans I’ve seen recently comes from developer David Bushell, who recently outlines 5 Tips for Responsive Builds. Among his suggestions there are two standouts, the first being “utilize breakpoint zero.” For Bushell “breakpoint zero” just means “start by writing HTML in a semantic and hierarchical order. Start simple, with no CSS at all and then “apply the basic styles but don’t go beyond the default vertical flow.”
In other words, keep your layout slate blank as long as you can so that when you do start adding layout rules you can spot problems with different breakpoints early and fix them before changing things becomes a major headache.
The other highlight of Bushell’s post is the suggestion that you maintain a CSS pattern library — reusable snippets of CSS you can drop in for quick styling. There are a ton of ways you can do this, whether it’s something formal like SMACSS (pronounced “smacks”), OOCSS, or just taking the time to write a style guide with some sample code. The point isn’t how you do it or which method you use, but that you do it.
Be sure to check out Bushell’s post for more details on these two suggestions as well as the other three ways you can help make your responsive design process a bit smoother.
So many screens, so many images (testing responsive sites with Adobe Shadow). Photo: Adobe
The average webpage is now 1.2 megabytes and around 60 percent of that rather large payload comes from images. That’s a lot of data, whether you’re handling images responsively or just trying to speed up a desktop site.
You might think, if images are the bulk of what your browser is downloading, that browsers would be working hard to speed up the image downloads, perhaps trying alternate, space-saving image formats, but you’d be wrong.
You might also think that, as Google’s Ilya Grigorik writes, “innovating on better image formats would be a top agenda item” for the web. But again you’d be wrong. The web is still using the same image formats it’s been using virtually since the first images appeared online.
Grigorik thinks it’s high time that changed and we agree.
In a recent post looking at what it would take to deploy new image formats on the web, he writes, “if we really want to make an impact on web performance, then image formats is the place to do it… there is absolutely no reason why we shouldn’t have dozens of specialized formats, each tailored for a specific case and type of image.”
Of course no web developer wants to deal with dozens of specialized image formats. Nor should they need to — that’s a job for servers. “In a world with dozens of image formats,” continues Grigorik, “the human solution does not scale — read, markup does not scale… whereas computers are fantastic at doing exactly the kind of optimization work required to solve the problem.”
Grigorik isn’t alone in calling for new image formats, nor is he the first to suggest handing these tasks off to the server. Developer and responsive images proponent Matt Wilcox has argued for a similar solution, as have others.
The basic premise of these arguments is that deciding which image to serve up to which device and browser should be a server-side problem. And in fact there’s already a way to solve this problem with HTTP headers, namely the Accepts header, which tells the server which image formats the browser supports. Based on that information the server could then “re-encode, recompress, resize, strip unnecessary metadata and deliver the optimal format.”
The problem is that web browsers (with the exception of Opera) don’t actually send useful information in the Accepts header.
Thus, the first step in creating a server-side solution for smaller images is to get other browsers to send useful Accepts headers.
The Accepts header isn’t a magic bullet by any means, but it’s a problem that’s not hard to solve provided browser makers prioritize it. But to really get server side image solutions working the web would also need new server tools (fortunately, several already exist). There are other stumbling blocks as well. Grigorik addresses half a dozen potential problems and objections that you can read through in his post.
Even if browser makers come around to the idea and do start improving Accepts headers, bringing better image formats to the web is going to be an uphill battle. But Grigorik is determined to chase the idea. “Some uphill battles are worth fighting,” he writes in a comment, “I think this a good one. Wish me luck.”
Good web typography needn’t be difficult, but typography can be a complicated and sometimes intimidating subject for newcomers.
To help you understand typography a bit better — and create better-looking websites with your new understanding — developer Tommi Kaikkonen created his Interactive Guide to Blog Typography. The guide offers a nice hand-holding walk through of the elements that make for good typography on the web, helping you not just make more readable sites, but understand why they’re more readable.
For most suggestions in Kaikkonen’s guide there’s an interactive button to toggle different line-heights, fonts and measures so you can see for yourself why those elements matter and how they contribute to making your site easier to read.
Among the suggestions in Kaikkonen’s guide are to set a readable measure (the number of characters on a line), frame content with white space (to put emphasis on the main part of the page), avoid pure black for text and, unless you really know what you’re doing, stick with just two different fonts.
There is one part of the guide we can’t totally endorse — the last suggestion, which is to use font-variant: small-caps; even if the font you’re using doesn’t actually have a small-caps variant. With some fonts — the traditional six fonts of web design, for example — you can get away with this, but if you’re using fancier fonts like those from Google Web Fonts or TypeKit this can make for some really awful results; proceed with caution on that one.
Your website’s view of the tubes. Photo: Stig Nygaard /Flickr
High-resolution screens on mobile devices present web developers with an interesting conundrum — the screens are capable of displaying very high-res images, but on a mobile device bandwidth may be limited. What’s a web developer to do?
The answer, for now, is that there is no good answer; be it bandwidth or image quality you’re going to have to compromise somewhere.
That’s why mobile expert Peter-Paul Koch thinks browsers need to start broadcasting the connection speed of the device. “Browsers, especially mobile ones, should give information about the speed of the connection they’re on,” writes Koch in a recent blog post exploring just what that might look like and how web developers might use that information.
Here’s what Koch thinks developers need:
We need an HTTP header, so that a server-side script can use the information to decide whether to send the lowsource or high-res images. Let’s call it X-Connection-Speed for now.
A JavaScript property, say navigator.connectionSpeed, also makes sense.
Chris Coyier proposed a bandwidth media query with matching min-bandwidth and max-bandwidth. Sure, why not?
Check out Koch’s post for full details on other aspects like units, how connections speed might be calculated and what to do with edge cases — like when the connection speed changes between read and page load (Koch’s scenario imagines a user on a phone in a train with a good connection that deteriorates when the train enters a tunnel).
Koch’s post isn’t a proposal; rather its an exploration of the idea and he’s looking for feedback. There are already some great comments from other developers, including several that question whether web developers should be allowed to decide how much bandwidth a site uses.
While developers might like to be able to control bandwidth and deliver the images they’d like to be seen, that just might be a decision best left to users. For example, I may have a great 4G connection, but my data plan might be a mere gigabyte a month and I may not want to waste it on your high-res images. As David Ellenwood points out in the comments, a YouTube-style approach, choosing a sensible default and then offering up links to higher-res content (e.g., the 480, 720, 1080 options on most YouTube videos) might be the more user-friendly approach.
For now not only do browsers not broadcast connection speed, most don’t even have access to that information at the device level. But there are already proposals to add some sort of bandwidth info to HTTP (like the HTTP Client Hints proposal from Google’s Ilya Grigorik or Mozilla’s proposed Network Information API) and it seems likely that something along these lines will be added before too long. Be sure to read through Koch’s post for some more background and details. If you’ve got ideas, leave a comment on his site.
If your site has ever been, as Google’s Jonathan Simon charitably puts it on the Google Webmaster Tools blog, “caught up” in linkspam, Google has a new tool you can use to disavow those inbound links and clear your site’s name.
Google cautions that its new Disavow Links tool should be thought of as a last resort. It’s far better to get any spammy links actually removed from the web. In fact “the vast, vast majority of sites do not need to use this tool in any way,” writes Simon. But for situations where you can’t make the offending links go away — for example, with a client who might have made some bad SEO decisions in the past — Disavow Links offers a solution.
It’s worth noting though that Simon says that any links you disavow will be seen as “a strong suggestion rather than a directive — Google reserves the right to trust our own judgment for corner cases.”
Inbound links are perhaps the best known thing that Google uses to calculate PageRank and order search results. While PageRank is just one of more than 200 “signals” Google looks at to determine where your site will be in search results there’s no question that better inbound links mean your pages end up higher in search results.
There’s a flip side to inbound links though. If the wrong sort of sites point at your site it hurts your PageRank. If you’ve got inbound links from known paid link or other shady link-swapping schemes that violate Google’s guidelines, you can quickly find your site has disappeared from Google’s search index.
For more info on how the Disavow Links tool works, check out the video below from Google’s Matt Cutts. Also be sure to read through the FAQ over on the Google Webmaster Tools blog.
Browse Our Tutorials
Cheat Sheets
Color Charts
Cut & Paste Code