Book Review: Responsive Web Design 59
Michael J. Ross writes "With more people accessing the Internet using mobile devices than computers, web designers and developers are challenged to make sites that work well on both categories of hardware — or resign themselves to the greater costs and other disadvantages of maintaining two versions of each web site (a mobile-ready version as well as one for much larger screens). Fortunately, recent advances in web technologies are making it easier to build web pages whose contents and their positioning are automatically modified to match the available screen space of the individual user. These techniques are explored in detail in a recent book, Responsive Web Design, written by Ethan Marcotte, a veteran web designer and developer." Keep reading for the rest of Michael's review.
This title was published on 7 June 2011, under the ISBN 978-0984442577, by A Book Apart, as the fourth in their series of "brief books for people who make web sites." On the publisher's page, visitors will find brief descriptions of the book and its author, links to purchase the print and e-book versions (or the two combined, at a substantial discount), and three promotional blurbs also used on the back cover of the print version. The e-book package consists of six files: the book in EPUB, MOBI, and PDF formats; an EPUB document on responsive design for video; a letter from Jeffrey Zeldman (the book's publisher), Jason Santa Maria (its designer), and Mandy Brown (its editor); and the previous five files zipped into an archive. This book is also available in French, perhaps reflecting the publisher's greater awareness of internationalization relative to mainstream technical publishing houses.
| Responsive Web Design | |
| author | Ethan Marcotte |
| pages | 143 pages |
| publisher | A Book Apart |
| rating | 9/10 |
| reviewer | Michael J. Ross |
| ISBN | 978-0984442577 |
| summary | A pithy tutorial on responsive web design. |
Readers of the print version will likely be first struck by its diminutive size — just 143 pages. In fact, the book is so slender that only half of the spine title actually fits on the spine. (It's either a bold design statement against conventional publishing practices, or an even bolder typographical error committed inexplicably by a well-regarded design firm.) Flipping through the glossy pages, readers will also notice the judicious use of text color to indicate HTML and CSS code, and highlighted fragments therein. Even more visually impressive are the full-color screen shots and other figures. The book begins with the previously mentioned letter, as well as a short yet delightful foreword by Jeremy Keith; it ends with the author's acknowledgments, suggested resources, references by chapter, and a suspiciously brief index, not much longer than the author bio that follows it.
The bulk of the information is organized into five chapters — the first of which, "Our Responsive Web," presents a high-level rationale for architecting web sites that can be maximally useful on a wide range of devices, with screen sizes ranging from the smallest found on smartphones, up to widescreen TVs attached to web-enabled game consoles. Throughout the book, to illustrate the principles of responsive design, the author utilizes a fictional example web site, "Robot or Not", designed to assist users in identifying robots masquerading as humans (which would have been helpful to the crew of the spaceship Nostromo!). This short chapter is essentially just an introduction.
The author gets down to business in the second chapter, titled "The Flexible Grid," which demonstrates how grid-based layouts can be used to more easily position page elements for greater visual consistency. He goes into detail in showing how such layouts can be made flexible, with font sizes specified in character widths and positioning specified in proportions of containing elements. Experienced designers will probably not encounter any new concepts in this material. These techniques are extended in the subsequent chapter, "Flexible Images," which explains how to use percentages when working with images (both markup and CSS) and other media types — including workarounds for the browser most despised by web designers, Internet Explorer.
Media queries, introduced to the world in CSS2, are now a key technology in responsive design, and are discussed in Chapter 4, which forms the core of the book. The author shows how to use them to cause the browser to apply CSS rules selectively based upon such factors as the width of the browser viewport. All of the narrative is clear, except for the statement on page 66 that the example web site's logo is "scaled down to a nearly microscopic size" in Figure 4.2, when in fact it appears unchanged. Readers may wonder why — after noting that mobile devices do not consistently use "handheld" or "screen" as their media types — the author does not explain why the recommended media queries use "@media screen," and not "@media all" to be more encompassing. Nonetheless, the discussion of media query techniques is instructive. It continues with a look at how to use them in older browsers, using JavaScript libraries, css3-mediaqueries-js and Respond.js. Lastly, the author shows how incorporating some fixed widths into a flexible design may be an optimal approach.
The fifth and final chapter, "Becoming Responsive," discusses real world implications of responsive design. The author counters an interesting contention: web sites on mobile devices should not simply be the desktop content scaled down to a smaller screen, but instead should offer different content, more appropriate for the individual on the go. He then touches on the topic of designing sites first for mobile, rather than the traditional approach of trying to shoehorn a full-size site onto a small screen. The bulk of the chapter is devoted to presenting a workflow employed by the author in creating actual client sites. It concludes with a demonstration of how to add a slideshow using a jQuery plug-in and some custom code, so it abides by the principles of progressive enhancement.
In terms of the physical book, the quality is top-notch, and the full-color images are quite compelling. Sadly, each figure tends to bleed through to the other side of its page, but fortunately not enough to inhibit reading the text on the other side, or appreciating any of the images. The e-books are also quite readable — probably more so compared to the electronic versions of other programming books, given the smaller line lengths.
In terms of the narrative, Ethan Marcotte has a somewhat goofy writing style, replete with nerdy side comments and jokes, which some readers may regard as padding, particularly in those sections where they are quite numerous. The same may be said for the hyperbole in some spots, such as "Marvelous. Wonderful. Stupendous, even." (page 33). On the other hand, many readers may enjoy the lighthearted style, especially those jokes that work well. More importantly, the explanations are generally comprehensible and thorough. I was able to find only one erratum ("or a maybe an animation," on page 119), and the only grammatical error was the frequent use of the term "that" to refer to people, instead of "who." Otherwise, there were no glitches in the writing, and most techies will find this book a fairly quick read.
From a higher-level perspective, one sometimes hears an objection raised against web design/development books such as this one — namely: all of the book's information is freely available in articles, blog posts, forums, IRC channels, and other resources for programmers. So why purchase a static book whose author probably started writing it months if not years in the past? Such technical information is scattered among numerous websites, thereby forcing us to spend time searching around, and in many cases skipping over redundant material. Also, the advice tends to vary in quality, and hence we must distinguish what information is out of date or simply invalid. Likely every experienced developer has been tempted by an article titled such that it sounded as though it would contain the exact solution to the problem at hand — only to discover that the title was quite misleading, or the people contributing to the comments were equally befuddled (and frustrated). Technical books geared toward the working professional can obviate these problems, because they bring together most of the information known by the industry, into a cohesive whole, that is then vetted by technical reviewers and editors. In the case of this monograph, Ethan Marcotte's well-regarded seminal article, in conjunction with the other most popular articles on responsive web design, would still not be a sufficient substitute for this resource.
For web designers and developers alike, Ethan Marcotte's book is a neatly-crafted and authoritative single-source tutorial on how to build responsive web sites that will likely prove robust on a wide range of platforms.
Michael J. Ross is a freelance web developer and writer.
You can purchase Responsive Web Design from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
How about (Score:4, Interesting)
Starting with Web Pages That Suck [webpagesthatsuck.com] and learning there before doing anything.
Amazed how many pages get it wrong - from Facebook to Ebay - there are fundamental navigation design flaws which vex users. There's some sort of disease, which has been epidemic for years on the web, steering wide of the Keep It Simple Stupid philosophy of design. Keep in direct, simple and above all light weight.
Mystery meat in Unity (Score:2, Interesting)
Starting with Web Pages That Suck
If only the architects of the Ubuntu operating system would read that web site. Then they'd understand what the global menu in Unity does wrong compared to the global menu in, say, Mac OS X. In Unity, the frontmost window's title covers up the menu bar until the mouse enters the menu bar. WPTS calls this behavior mystery meat navigation [webpagesthatsuck.com]
Re: (Score:1)
Starting with Web Pages That Suck [webpagesthatsuck.com] and learning there before doing anything.
Did they nominate themselves for any award? I went hunting for the list of 2011 contenders and it took about four clicks of links, each of which promised me I was going to get to the 2011 contenders. Every time I clicked a link it opened it in a new window. The ads were so intrusive I didn't know if they were bitching about the companies advertising on their page or something else.
How about not worrying about it (Score:2)
How strange (Score:2, Insightful)
I thought the whole idea of HTML was that content and presentation would be separated so you wouldn't have to care whether the end-user was viewing the page on an SGI workstation in Spielbergian 3D or an Etch-a-sketch?
Of course that was before the 'web designers' came along and suddenly 'this page is best viewed at 1280x1024' was plastered across the web.
Why serve both low- and high-detail HTML (Score:3)
I thought the whole idea of HTML was that content and presentation would be separated
On a device with a high-definition screen, such as a PC, Internet-enabled television, or full-size tablet, a news site might want to show both the headline, a photo thumbnail, and the first sentence of each article. But on a device with a smaller screen, such as a PDA or mobile phone, it might want to show only the headline. CSS can only hide boxes; it can't keep the boxes from being downloaded in the first place. Furthermore, the devices with small screens often have Internet connections that cost more per
...on the same hostname (Score:2)
If what you describe is really a problem, then the only sensible thing to do is to use two completely separate web sites. You have one targeting mobile devices, and one targeting more capable devices.
Which is sort of what I meant by "redirect small-screen users to a low-detail HTML document". Viewing the front page of a site on a PDA or cell phone would redirect to /m/; doing so on a PC or TV would redirect to /home/.
Re: (Score:2)
Viewing the front page of a site on a PDA or cell phone would redirect to /m/; doing so on a PC or TV would redirect to /home/.
So can you show us the code on the server that determines the size of the screen (or window) at the client end?
This turns out to be a non-trivial problem. If the Web's standards stated that the client had to send this information, it would be easy. But this hasn't been done. The only "solution" seems to be to use the HTTP_USER_AGENT string, which isn't actually sent by all clients, and which has millions of possible values, some of which don't tell you much about the window/screen size. People who h
Re:SO USE SEPARATE WEB SITES! (Score:5, Insightful)
For the most part they don't. In fact I don't know of anyone who actually does that successfully.
The author of this book seems to think it's a good idea, but generally speaking I've never known anyone halfway sane who did it more than once by choice. Sometimes you'll get the content vs presentation brigade self flagellating with this kind of design, but these are the same people who think that the web is a place where you can actually follow best practices and end up with a meaningful result.
Sorry to burst everyone's bubble, but the Web is a dirty dirty place. The W3C likes to finally set standards for things that were needed 5 years ago and never for what's needed now, AJAX is a dirty hack which just happens to work well, and everyone on the standards body seems absolutely obsessed with building more and more functionality for static web pages which make up less and less of content and didn't really need any help to begin with. Half of HTML5 is semantic web garbage, which is great in theory, but which is almost entirely focused on last decade's content.
Re: (Score:2)
On a device with a high-definition screen, such as a PC, Internet-enabled television, or full-size tablet, a news site might want to show both the headline, a photo thumbnail, and the first sentence of each article. But on a device with a smaller screen, such as a PDA or mobile phone, it might want to show only the headline.
With the amount of Javascript and appallingly bloated HTML on some news sites, I think a small amount of extra text per story that gets downloaded but not shown will pale into insignificance. And if they want to include a picture, then they can use CSS to apply it rather than use the <img> tag, so it would not get downloaded if it doesn't match the media type. I guess that does blur the line between content and presentation though.
The best practice is to write pages that flow naturally to the screen w
Make it wide enough for netbooks and Snap (Score:2)
And if they want to include a picture, then they can use CSS to apply it rather than use the <img> tag
Since when can a CSS background-image be scaled?
The best practice is to write pages that flow naturally to the screen width.
True, but there's still a reason to put something like max-width: 30em on a body text element, and it's the same reason newspapers are printed in columns instead of with lines of text across the whole width of a half-broadsheet. Without it, the eye has trouble finding the start of the next line of text, and the reader may end up repeating or skipping a line.
The problem with having the mindset of separate versions of the website (to quote the summary: a mobile-ready version as well as one for much larger screens) is that it can miss out on the screen sizes in between (eg. netbooks).
Then make your "full size PC" page scale as small as netbooks, but not necessarily smaller. A lot of web
Re: (Score:2)
And if they want to include a picture, then they can use CSS to apply it rather than use the <img> tag
Since when can a CSS background-image be scaled?
I'm not saying that you should scale the image smaller on smaller window sizes. I am saying to remove the image at small resolutions. That is easily done with CSS.
there's still a reason to put something like max-width: 30em on a body text element
That is one strategy for making the page resize as I stated, and yet it prevents the page from becoming stupidly unreadable on large monitors. It is certainly better than just using width: 30em. That said, you don't want to make the max-width too narrow. It is annoying to maximize a window to see more of a webpage, only to be greeted with exactly
Re: (Score:2)
That would fail for 800x480 netbook screens. Or people on 1280 width screens who do not maximize every window. That is exactly my point: whatever assumptions you make about the client's environment, someone out there will prove you wrong.
Heh. I've found myself often adopting a practice that helps prevent a single web site from occupying most of my screen: If I see a "mobile" link, I automatically click on that one. Such pages are quite readable on this 1920x1200 screen, and leave most of the other stuff still visible. And the "mobile" pages tend to omit a lot of the cruft that clutters up most "main" pages, so I often see more actual information that way. I did this with slashdot, before they provided a layout that used the full windo
IE pre-9 is still nearly half (Score:2)
Re: (Score:2)
Re: (Score:2)
So you cant make the php or asp code also see what the browser is and adjust?
If you have "articles" and run flat html and css you need to stop right now and get out of the web design business.
Use separate URLs to be cache friendly (Score:2)
So you cant make the php or asp code also see what the browser is and adjust?
One can, but to take cache behavior into account, one needs to put the PHP or ASP code that generates the low- and high-detail documents at different URLs and then do "Location: /home/" or "Location: /m/" depending on the detected user agent. Each document in /home/ or /m/ would link to the corresponding document in the other space in case the script misdetects the user agent. Otherwise, if you put the home and mobile documents at the same URL, a caching proxy might deliver the document suitable for the dev
Re: (Score:2)
I thought the whole idea of HTML was that content and presentation would be separated so you wouldn't have to care whether the end-user was viewing the page on an SGI workstation in Spielbergian 3D or an Etch-a-sketch?
Of course that was before the 'web designers' came along and suddenly 'this page is best viewed at 1280x1024' was plastered across the web.
I have a considerable background in developing very lightweight web interfaces. Use no more than necessary to accomplish your goal. But then, I do a lot of the coding by hand, still. Composition tools in the hands of morons are responsible for most of the web's disasters. Why bother to understand the footprint and implications of each object added to a page when it's so easy to do? I finally had to go to DSL at home when my poor 56K modem was choking on bloat - good by $12/mo. internet.
Ergonomics aren'
Re: (Score:2)
I thought the whole idea of HTML was that content and presentation would be separated so you wouldn't have to care whether the end-user was viewing the page on an SGI workstation in Spielbergian 3D or an Etch-a-sketch?
Actually, that was one of the primary design goals in Tim Berners-Lee's original HTML. The "markup" was explicitly designed so that when the text reached the client's machine, it could be quickly and easily formatted to fit whatever screen was available.
Of course that was before the 'web designers' came along and suddenly 'this page is best viewed at 1280x1024' was plastered across the web.
I think you nailed it! But we might add that this contempt for the viewer was encouraged by many managers, who just wanted it to look good on the screen that was on their desk. I've worked on any number of projects where, once it worked on the Boss's s
This is new? (Score:2)
Re: (Score:3)
HTML did okay until you started playing with tables. And many content-only sites would do well to return to simpler layouts.
But applications-in-the-browser that use tons of javascript can't really fall back to plain HTML.
Re:This is new? (Score:4, Funny)
But applications-in-the-browser that use tons of javascript can't really fall back to plain HTML.
If some vocal opponents of web applications are to be believed, JavaScript-heavy web applications can fall back to offering a download of the installer for a native application designed to run in Windows and Wine and a download of an APK designed to run in Android.
Re: (Score:2)
Lol, even adobe couldn't pull that off with their flash plugin. Better to let the individual vendors write their own bugfixes. Maybe google will get some traction with their sandboxes native code in the browser idea.
Re: (Score:2)
requests from the browser to the httpd
Each of which requires a separate round trip over a potentially high-latency Internet connection, making the site load more slowly.
Re: (Score:2)
you have no clue
Then please give us some. Say you want to display only the headlines to users of a PDA or mobile phone but the headline, the first sentence of the article, and a photo thumbnail to users of a full-size tablet, a PC, or an Internet-connected TV. How would you do this using XML and XSLT?
Re: (Score:2)
now you are talking about "how to select(!) and transform information from the XML using XSLT"...
answer: XPath queries
You can only "select" information without a round-trip if you have already downloaded it. This means your low-detail document will have as many bytes as the high-detail document, which defeats the purpose of sending a low-detail document over a more expensive Internet connection.
Re: (Score:2)
Re: (Score:2)
I come to Slashdot for shill reviews for Packt Publishing and their books on 3 year old versions of Drupal. Slashdot I am disappoint.
Would a 1 1/2 year old book by RuPaul [amazon.com] make you feel better?
Re: (Score:1)
Simple Solution to Faster Web Pages (Score:5, Informative)
1- do not serve ads from remote servers
2- do not associate with external sites like facebook, etc
3- do not use web bugs, beacons or other trackers
Those three things probably account for 99.9% of the sloth in today's internet
Re: (Score:2)
I just love it when I find myself at a new (to me) website, and open up the noscript dialogue box to whitelist that domain, and I can't even find the thing because it's grabbing crap from fifteen different places. Usually that's my clue to leave, but it seems to be happening more and more often now.
That, and websites that just love having a completely separate domain for images, video, and regional content, and then they smash it all into one page. That pisses me off too. I weep for the death of subdomains.
Re: (Score:3, Informative)
Re: (Score:2)
Not everyone needs to do this, but many rely on ad revenue in order to keep running their websites. So good luck with that.
>2- do not associate with external sites like facebook, etc
Shouldn't this depend on your marketing plan and target audience, and the sites they like to use? Oh, I guess you just dislike it on principle? Good luck with that.
>3- do not use web bugs, beacons or other trackers
Rule out Analytics software? OK, so far you've whitt
Re: (Score:2)
It should be possible (hmmm... maybe I should patent this?) to locally cache all (or many) of the ads the upstream provider wants you to display. Likewise analytics on those ad views/page impressions can be batched back periodically. Website specific analytics can be hosted locally. As to the social media - is there really a need to provide a facebook login? or a facebook tracker? I suppose some will justify it and perhaps I would have less of any issue (ignoring privacy concerns) if I didn't see so ma
Re: (Score:1)
1- do not serve ads from remote servers 2- do not associate with external sites like facebook, etc 3- do not use web bugs, beacons or other trackers
Those three things probably account for 99.9% of the sloth in today's internet
Responsive, in this context, doesn't refer to loading time, but rather the adaptability of a website to respond to a UA's canvas at almost any size and orientation while remaining usable.
Hello? (Score:2)
It's called CSS and those of us who paid attention have been using it for years.
it is not hard to make a webpage that looks good on a pc AND a mobile device with CSS.
Keeping that while the idiot client wants you to put in more blinking and scrolling crap is another matter..
CSS Isn't The Whole Answer (Score:2)
Yes, the mechanism for designing pages that are usable on devices large and small, bandwidth constrained or not, is CSS. But, to the best of my knowledge, there ain't no way to know which tags or class of tag will best render in browser X without a large dose of either browser or capability detection. So, merely replying "CSS" is only giving half of the answer.
Re: (Score:2)
Just to be clear, I'm aware that there's a certain amount of mobile support that can be handled directly in CSS:
> @media only screen and (max-width: 999px)
> @media only screen and (device-width: 768px) and (orientation: landscape)
> @media only screen and (min-device-width: 320px) and (max-device-width: 480px)
etc, but it isn't the end all-be all.
Re:Hello? (Score:4, Insightful)
And it doesn't work and never has.
CSS won't allow you to magically show the same content on a 24 inch screen and a 3 inch one because it's about more than layout at that point. You have to completely change what content is shown to make that work, and CSS simply doesn't support that, not even in CSS3. That's not even taking into account the fact that the entire layout and complex CSS will have to be downloaded even if most if it isn't used, or websites which aren't pure text or where layout matters.
Indeed, CSS doesn't work (Score:2)
Re: (Score:2)
IF you are trying to show the same content then you are a fool.
Your backend php/asp shuold already be doing browser detection and simply swapping between mobile and big-ass-screen(tm) css leading to ONE site that services all devices.
Honestly this is fricking Webdesign 101, are you people seriously having trouble with serving comtent to both devicetypes?
I can detect android devices and ios devices and serve up css that makes the webpages look and act like native apps. been doing this for over 2 years no
Re: (Score:2)
Your backend php/asp shuold already be doing browser detection and simply swapping between mobile and big-ass-screen(tm) css leading to ONE site that services all devices.
The problem there is that your backend server might not (and for large websites probably won't) have full access to the client. Suppose your home page is served by a CDN or other web proxy, or is even just a static page so that it doesn't get overwhelmed by heavy traffic. In those situations, there's not a great way to say "serve this page to mobile visitors and this one to everyone else".
If you can pull it off, there are nice benefits from being able to hand out the same content to everyone along with inst
Re: (Score:2)
You have to completely change what content is shown to make that work, and CSS simply doesn't support that, not even in CSS3.
Sure it does, to a point. You can write something like:
And then in your style.css:
Re: (Score:2)
For a relatively trivial subset of cases yes, and of course just because display is none doesn't mean it's not downloaded.
The general point being is that for anything non trivial trying to handle your viewers with CSS is needlessly complicated and messy. Generally two pages is a much better way of dealing with things.
Re: (Score:1)
Not available on Amazon (Score:1)