Tag Archives: mobile

A quick book review: Responsive Web Design

Just finished reading an excellent book: “Responsive Web Design” by Ethan Marcotte. If you build web pages, I want you to read this book. Here’s a few of my thoughts on what I just learned, and why you should read this one too.

The book begins with an overview of the evolution of page layout in web design, starting with it’s roots in printed page design and moving on to today’s reality that there is a multitude of screens and devices out there, with more on the way. We cannot predict what type of device our readers will show up with, and must adjust our belief system (if we have one) to accommodate the new realities that the various screen widths and mobile device sizes present us with.

The second chapter discusses the idea of designing within the constraints of a flexible typographic grid. Grid systems are somewhat of an artificial constraint that designers place on themselves to provide balance and symmetry to page layout, and on screen a new challenge is presented in that the page size is no longer fixed. The main takeaway here is to design content in flexible porportions to the variable screen widths that might be used to access your web pages. Mr. Marcotte puts forth some simple, accessible ideas for developers to leverage, making text more readable on unknown devices by putting forth a formula that I’ll repeat here mostly for the purposes of getting my own head wrapped around it:

target ÷ context = result

To decode Mr. Marcotte’s example, he begins with an assumption of a base font size of 16px. The headline in the comp is defined to be 24px. So to make it flexible, divide:

24 ÷ 16 = 1.5

And so the headline should be defined as 1.5em. Simple and elegant rule of thumb. Now we just need to remember to do it.

Chapter 3 applies this principle to flexible images, and expands upon it. There is the inevitable Questionable Functionality Challenge™ presented to us by Internet Explorer, which is quickly defused. That’s a lot of ink to dedicate to an obsolete web browser and the example demonstrates where the real problem lies by showing how awful text looks in resized images. But you aren’t locking up text in your images, right? I know, I know, it’s an academic example and clearly illustrates the failings of IE’s image resize capabilities. Let’s move on.

Chapter 4 introduces media queries. We’re finally at what I consider to be the coolest and most important part of the book – how to progressively enhance your web page layouts through the media query construct. Mr. Marcotte makes the argument in favor of using the min-width property instead of things like max-width (which tends to yield excessive code) and min-device-width (which only pertains to devices and doesn’t take into account variable web browser windows.) The max-width property is introduced for those that want to stop the insanity. (I do know people that expand their web browser to the full width of their 27″ high resolution monitors.)

Chapter 5 pulls it all together with strategies to integrate responsive design into your team’s workflow; how to make your design process itself a responsive one. He builds the case for Luke Wroblewski‘s “Mobile First” philosophy (a case that was already built up a bit in chapter 1) and finishes it all of with how to incorporate progressive enhancement using JavaScript to selectively pull in a slideshow component only when JavaScript is available and all the stars are in the proper alignment.

Overall, my belief has always been somewhat of the philosophy that there should be just “one web”; no “mobile web” or any other sort of alternate web reality that we should somehow slip into. Today’s mobile devices that are in fact being used to access the web are billed as fully capable web browsing devices, and indeed they are. Why deliver a shrunken-down version of your website just because they have a 3″ wide screen these days? It no longer makes sense in most cases; just reposition your content to accommodate their view. Every chapter includes simple, usable techniques that work, and I feel that these gems of advice should be a core part your future projects.

Lastly, I am very thankful for the appearance of the A Book Apart series. Each one of these volumes is, I believe, how a tech book should be: concise, full of valuable, practical, actionable information. I have read several of these so far, and each one has been a hit. I look forward to more.

Cheatsheet from today’s Open Web Camp “Refactoring for Mobile” talk

For the Open Web Camp attendees, here’s my cheatsheet from the Refactoring for Mobile talk I gave today at Stanford:

Get it as a CSS file and view it in your favorite code editor:


Or preview here:

The first thing we need is a media query and to add
<meta name="viewport" content="width=device-width,
minimum-scale=1.0, maximum-scale=1.0">
to the head:
@media only screen and (max-device-width:480px) {
For starters, note the two divs #wrapper and #contents.
Let's use those to create our structural layout and
fold back in some of those design elements.
#wrapper {
background:url(img/back2.png) no-repeat center top;
#contents {
margin:0 auto;
Now, let's style the main navigation buttons. First, we
will use inline-block to give block-like behavior to the
buttons but retain width based on the content. Then we set
the color, font size, and floating, and add a bit of box
.menu a {
padding:1em 0.95em;
border-left:1px solid #888;
-webkit-box-shadow:0px 1px 5px #222;
We can now use border-radius to style the left and right
buttons instead of image files:
.first_menu a {
.menu li:last-child a {
What if we flip to Landscape? There's a media query for
@media screen and (orientation:landscape) {
.first_menu a {
Now we can style the body content. #middle-contents is
the main containing block. We can use the background image
from the main stylesheet, but alternately we can use rgba
backgrounds to get finer control. Add border radius and box
shadow for depth.
#middle-contents {
/* background:url(img/side.png) repeat-y;*/
-webkit-box-shadow:0px 1px 6px #000;
box-shadow:0px 1px 6px #000;
Let's style the banner text and have some fun with it using
web fonts. Here's a font we'll pull in, using TTF and SVG formats.
Sadly, the vendors have many opinions on the solution, but
FontSquirrel can help sort it out.
@font-face {
src: url('Lobster_1.3-webfont.ttf') format('truetype'),
url('Lobster_1.3-webfont.svg#webfontcOtP3oQb') format('svg');
#logo a {
font-family:Lobster, sans-serif;
text-shadow:0px 2px 4px #000;
#logo h1 {
font-family:Lobster, sans-serif;
The float is creating a spacing issue. We can fix that
with a clear:
#header { clear:both; }
We are getting close. Now on to the bottom of the page.
The #comments section is too wide. We need to reset it:
#comments {
#comments textarea, #comments input {
border:1px solid #000;
That input button could be nicer:
#comments input.button {
margin:0 auto;
Now we have something that looks like it was meant for a
mobile device. Let's wrap this up by making the final
links look like tap-friendly buttons:
#right-col a {
background-image: -webkit-gradient(linear, left top, left bottom,
from(#666666), to(#666666), color-stop(.5,#333));
border:1px solid #000;
Maybe those final link items were over the top.
Let's restore them to inline links:
#copyrights a {
Now add some HTML5: Add placeholder="I think..." to the textarea in
comments.php, line 191.
Add input types to email and url fields.
Finish with atouch icon: <link rel="apple-touch-icon" href="piano.png"/>
(Note to attendees: I forgot to add the piano.png file to my project files.
But this works otherwise!)

The madness of screens vs. browsers on the mobile web

This evening as I was doing some research on mobile web development, I got myself on a tear about the wild differences we face as web developers regarding screen sizes and default browser installations, and came up with this:

Make Model Resolution Default Browser Engine*
Amazon Kindle 600 x 800 NetFront
Apple iPhone 480 x 320 WebKit
Apple iPod Touch 480 x 320 WebKit
BenQ M315 128 x 128 Opera
HTC G1 320 x 480 WebKit
Kyocera Mako S4000 128 x 160 Openwave
Motorola Hint QA30 320 x 240 Openwave
Motorola Krave ZN4 240 x 400 Openwave
Motorola KRZR K1 176 x 220 Opera
Motorola RAZR V3 176 x 220 Opera
Motorola ROKR E2 240 x 320 Opera
Motorola SLVR L7 176 x 220 Opera
Motorola V980 176 x 220 Opera
Motorola VE240 128 x 128 Openwave
Motorola ZINE ZN5 240 x 320 WebKit
Nokia 6300 240 x 320 Opera
Nokia 2605 Mirage 128 x 160 Openwave
Nokia N81 240 x 320 WebKit
Nokia N810 800 x 480 Gecko
Nokia N82 240 x 320 WebKit
Nokia N95 240 x 320 WebKit
Nokia N96 240 x 320 WebKit
Palm Centro 320 x 320 NetFront
Palm Treo 680 320 x 320 NetFront
Palm Treo 750 240 x 240 Internet Explorer
Palm Treo 755p 320 x 320 NetFront
Palm Treo 800w 320 x 320 Internet Explorer
Palm Treo Pro 320 x 320 Internet Explorer
RIM Blackberry Bold 480 x 360 Blackberry Browser
RIM Blackberry Pearl 240 x 320 Blackberry Browser
RIM Blackberry Storm 480 x 360 Blackberry Browser
Samsung Behold T919 240 x 400 NetFront
Samsung BlackJack SGH-i607 240 x 320 Internet Explorer
Samsung Epix i907 320 x 320 Internet Explorer
Samsung Eternity SGH-A867 240 x 400 Openwave
Samsung Highnote M630 176 x 220 Polaris
Samsung Omina i910 240 x 400 Internet Explorer & Opera
Samsung Rant M540 176 x 220 Polaris
Samsung Rugby A837 176 x 220 NetFront
Samsung Saga i770 320 x 320 Internet Explorer & Opera
Samsung SPH-Z400 176 x 220 Obigo
Siemens SX66 240 x 320 Internet Explorer
Sonim XP3 128 x 160 Opera
Sony Ericsson C702a 240 x 320 NetFront
Sony Ericsson C905a 240 x 320 NetFront
Sony Ericsson TM506 240 x 320 NetFront
Sony Ericsson W595a 240 x 320 NetFront
Sony Ericsson W760 240 x 320 NetFront
Sony Ericsson X1 800 X 480 Internet Explorer & Opera

*Some service providers will opt to use a different browser than the ones listed here.

It is interesting to note the diversity on these fronts. Screen sizes are all over the map, and the browsers here are not the usual suspects we see on the desktop. As for browsers, while it is certainly possible on many of these platforms to install a different browser (Opera being the usual choice), most users don’t bother. Regardless, Opera is the dominant player in this space, with significant marketshare owned by all the other actors on the mobile stage. As I research this topic, the WebKit engine proves to be the vast trendsetter and it is interesting to see how many platforms besides the iPhone are picking this one up. And trends show that this landscape is evolving rapidly as mobile capabilities increase and users begin surfing the web on their mobile devices with greater and greater frequency. ABI Research sees web browser installations on smartphones expanding from 130 million in 2008 to 530 million by 2013. The mobile web is a vastly unexplored frontier in web design and we should start seeing more and more attention getting paid to this aspect of the online world.

Update: Amazon Kindle’s Basic Web is based on NetFront – table updated to reflect this.

iPhone and mouse events

PPK has written his impressions regarding his shiny brand-new Jesusphone. (I wonder did he get black or white?)

In his post, he tells us the initial reports for the behavior of mobile Safari with regards to things like documentation (missing), mouse event implications (game changing), and how the disjunct state of finger tapping and dragging compares with the continuous state of the traditional OS desktop mouse pointer. In particular, he points out the fact that the assumed ever-present mouse pointer (the little cock-eyed arrow which points black and to the upper left on Mac, and is white and points to the upper right on Windows) can no longer be counted on. And in fact, there is no icon any more. Your fingertip is it, my friend!

With the coming of the iPhone the mouse model has lost its inescapable logic. Mousemove, mouseover and mouseout (and even poor old :hover) have been downgraded to device-specific events that may not survive in the long run.

May not survive… hmmm, interesting impact. I think he could be right here.

But — and here lies the problem — these events are used in countless web sites and applications for a variety of purposes, and Apple simply cannot afford these sites not working on the iPhone.

Interestingly, so far Apple has found that it indeed can afford to dispense with Flash and Java on the iPhone platform, and while most complain that the checkbox isn’t complete, some argue that Apple is doing just fine and won’t be in any hurry anytime soon. Certainly demand for these babies has been extremely high so far. I would be interested to see how many of such sites absolutely depend on such functionality to work, and how many of those either change their site behaviors or create iPhone-friendly web presences as the demand for the mobile web increases. Wondering… but at the very least, things like these aforementioned mouse events – Flash, Java, and the like – are not yet queued up on Apple’s priority list, or else they chose to take the less-is-better approach. It is an interesting question: How much of the specifications do browser vendors adhere to on such a limited platform such as mobile devices? What is practical? What is feasible?