The other side of the moon

So after WebPerfDays today, a bunch of us ended up at a Pizza place in Mountain View. Naturally the first thing we all did was search for wifi in the area and try to get on to a network from our mobile devices.

Now Mountain View has Google Wifi, and it appears as if they now require you to sign in with your Gmail account, and that's where the problem comes in... for me at least. I have two factor auth turned on for my google accounts, which means that after I type in my username and password, I get to a second screen to enter my second authentication token. This token comes from an app on my iOS device... the same device I was trying to log in with.

I switched to the app to get the token number, but as soon as I did that, iOS decided that I didn't actually want to sign in to the wireless network, and disassociated itself from the Access Point (AP).

Once I'd got the number, I switched back to the settings app and it initiated login again, which means I had to enter my username and password again, and by the time I'd reached the token screen, the token had expired.

This is what the token screen looks like:

It was rather annoying.

It then hit me that I could copy the token to the clipboard, and then paste it into the token text field, which should shave a few seconds off and maybe let me through.

That worked, but it was still annoying.

We started talking about how this interface could be improved. There are a few reasons why this is a problem, and I think they're mostly Apple's fault.

When you connect to a wireless network, iOS attempts to connect to www.apple.com. If it gets redirected somewhere else, it assumes that it's being asked to authenticate, and displays whatever page it gets redirected to in a browser like window.

The problem is that if you do anything other than interact with the content in this window, iOS treats it exactly the same as hitting the "Cancel" button (top right of the screenshot), terminates the login and dissociates from the AP.

This means that you cannot switch to the Authenticator App (second app at the bottom of the screenshot) to get your token.

Can Apple fix this?

Yes, just don't cancel sign in unless I explicitly click cancel

Can Google fix this?

Maybe, if they could provide a link or something that would open the Authenticator app right from that page and let me pull the number out of it (I don't know enough about iOS to know if this is possible).

Do any Apple/Google engineers want to take this up?

I've been catching up on my technical reading, and this weekend was spent on Responsive Enhancement¹. I'd read about it before on Jeremy Keith's blog and his comments on proportion perfection over pixel perfection² made me think. Finally, Kayla's report³ on Smashing Magazine about responsive web design coming up as I was thinking about making bluesmoon.info more mobile friendly is what prompted me to study it in detail.

I'm not going to go into the details of responsive enhancement, the references at the end of this article serve that purpose. This article lists what I think are best practices and my reasons for them.

@media queries

As a web designer or developer, you want your page to be easily viewable across different devices and screen sizes. It shouldn't matter whether your user uses a 21" desktop monitor, a 13" laptop, a 10" iPad or a much smaller smartphone. Responsive web design uses @media queries to change the layout of the page using CSS based on browser width. You might have CSS that looks like this:

/* Default wide-screen styles */

@media all and (max-width: 1024px) {
    /* styles for narrow desktop browsers and iPad landscape */
}

@media all and (max-width: 768px) {
    /* styles for narrower desktop browsers and iPad portrait */
}

@media all and (max-width: 480px) {
    /* styles for iPhone/Android landscape (and really narrow browser windows) */
}

@media all and (max-width: 320px) {
    /* styles for iPhone/Android portrait */
}

@media all and (max-width: 240px) {
    /* styles for smaller devices */
}

And yes, you could go smaller than that, or have intermediate sizes, but I'll cover that later.

viewports

Now this works reasonably well when you resize desktop browsers⁴, but not so much for mobile browsers. The problem is that mobile browsers (iPhone/Safari, Android/Chrome and Fennec) assume that the page were designed for a wide screen, and shrink it to fit into the smaller screen. This means that even though users could have had a good customised experience for their smaller devices, they won't because the device doesn't know about this⁵. The trick is to use Apple's viewport^{6, 7, 8} meta tag in your document's head in conjunction with @media queries⁹:

<meta name="viewport" content="...">

I've left the content attribute empty for now because this is where I see confusion... which is what we'll talk about now.

width=device-width

Most sites that I've seen advise you to set the content attribute to width=device-width. This tells the browser to assume that the page is as wide as the device. Unfortunately, this is only true when your device is in the portrait orientation. When you rotate to landscape, the device-width remains the same (eg: 320px), which means that even if your page were designed to work well in a 480px landscape design, it would still be rendered as if it were 320px.

It's tempting to use the orientation media query to solve this problem, but orientation doesn't really tell you the actual width of the device. All it tells you is whether the width is larger than or smaller than the device's height. As ppk points out⁵, since most pages tend to scroll vertically, this is irrelevant.

Use this if you use the same page styles in portrait and landscape orientation. Also note that using width=device-width is the only way to tell android devices to use the device's width¹².

initial-scale=1.0,maximum-scale=1.0

Setting initial-scale=1 tells the browser not to zoom in or out regardless of what it thinks the page width is. This is good when you've designed your page to fit different widths since the browser will use the appropriate CSS rules for its own width, and initial-scale stops the zooming problem that we faced without the viewport meta tag.

Unfortunately a bug, or more likely a mis-feature, in mobile safari messes this up when a device is rotated from portrait to landscape mode. initial-scale is honoured only on full page load. On rotate from portrait to landscape mode, the browser assumes that the page width stays the same and scales accordingly (1.5) to make 320 pixels fit into 480pixels. However, as far as @media queries go, it reports a 480px width, and uses the appropriate CSS rules to render the page. This results in a page designed for 480px rendered scaled up 1.5 times. It's not horrible, but it's not desirable. Fennec claims⁸ that it does the right thing in this case. The Android emulator is impossible to work with and I haven't tested on mobile Opera yet.

To get around this bug, the pixel perfection camp suggests also setting maximum-scale=1. This stops the page zoom in on rotate, but it has the undesired side effect of preventing the user from zooming the page. This is a problem from the accessibility point of view. Zooming in is a very valid use case for users with bad eyesight, and in some cases, even users with good eyesight who just want a closer look at some part of your page. Do this only if you hate your users. It goes without saying that setting user-scalable=no should also not be used on most general purpose pages.

A better solution may be design your page to use the same styles in portrait and landscape orientation and set width=device-width. This way even if it does zoom, it will still be proportionate. See Lanyrd¹⁰ for an example of this design.

width=<actual width>

Some sites advise using a specific viewport width and designing your pages for that width. This is fine if you're building a separate page for each device class, but that doesn't flow with the concept of responsive design. Fixed width layouts are for print. The web is fluid and adapts to its users. Your site should too. Don't use this.

@media all and (device-width:480)

While this is a media query rather than an option to the viewport meta tag, I've seen it at various locations, and don't think it's the best option around. Here's why. According to the CSS3 media queries spec¹¹, the device-width media feature describes the width of the rendering surface of the output device. For continuous media, this is the width of the screen. For paged media, this is the width of the page sheet size.

We're dealing with continuous media here (on-screen as opposed to printed), in which case the spec states that this is the width of the screen. Unless the browser window is maximised, this might be larger than the viewport with. My tests show that most desktop browsers treat device-width and width as synonyms. Mobile browsers seem a little confused on the matter. As far as the viewport meta tag goes, device-width is the width of the device in portrait orientation only. For a 320x480 device, device-width is always 320px regardless of orientation. For CSS media queries, however, device-width is the width of the screen based on its current orientation.

If you are going to use this, use it in conjunction with the orientation media feature. Never use max-device-width and min-device-width. It's better to use max-width and min-width instead. Also remember that device widths may change with newer models. You want your design to be future proof.

Intermediate widths

I'd mentioned above that you could design for any number of widths. The important thing is to test your page for different browser widths. This is fairly easy to do just by resizing your browser window. Test, and whenever you find your page layout break, either fix the layout for all widths, or build a new layout for smaller widths.

On bluesmoon.info, I change many parts of the page depending on page width. The default design (at the time of this article) has 5% empty space around the content. This is fine really wide screens (1152px or more), but as you get smaller, the empty space becomes a waste. Below 1152px, I shrink this to 2% and below 1024px, I get rid of it completely. You could say that my page content was really built for 1024px. This design also works for the iPad in landscape mode.

Below 1000px, all 3 column pages switch to a 2 column layout. Below 580px, I move the right column on all pages below the main content. All pages that initially had 3 columns now have 2 columns below the main content.

As we get smaller, I reduce the space used by non-essential content like the footer, the sidebars and the menu at the top, leaving as much space as possible for main content. Finally, when we get below 380px, the whole page turns into a single column layout.

This is of course, just an example. Your own site may have a layout that works perfectly at all screen widths, or you may need to design only two or three layouts. It's easy to test and design, so there's no reason not to. Designing for multiple widths took me just a couple of hours, and a lot of it was spent reading the articles below.

Recommendations

So finally, this is what I recommend.

1. DO use the viewport meta tag
2. DO use media queries to render your page appropriately for various widths ranging from under 200px to 1024px or more
3. DO use width=device-width,initial-scale=1 in your viewport meta tag OR use width=device-width alone¹².
4. DO NOT use maximum-scale=1 or user-scalable=no
5. DO NOT use width=<specific width>
6. DO NOT use @media all and (*-device-width: xxx)

Remember that using initial-scale=1.0 throws you open to a zooming bug in mobile Safari. Push Safari to fix this bug. Finally, David Calhoun has a great summary¹³ of all options to the viewport meta tag, and alternate meta tags for older phones. Well worth a read. Also note that Mozilla's documentation⁸ of the viewport meta tag is far better than Safari's⁷.

Footnotes & References

1. Ethan Marcotte. 2010. Responsive Web Design. In A List Apart #306. ISSN: 1534-0295.
2. Jeremy Keith. 2010. Responsive Enhancement. In adactio.
3. Kayla Knight. 2011. Responsive Web Design: What It Is and How To Use It. In Smashing Magazine.
4. Webkit based desktop browsers re-render the page correctly as you resize the browser, however they have a minimum width of 385px (on MacOSX) and I was unable to shrink the browser below this. Firefox 4 re-renders the page correctly until the width gets too narrow to fit the navigation toolbar. At that point the viewport width stays fixed even if you shrink the browser. The page is re-rendered if you type something (anything) into the URL bar. Opera 10/11 re-render correctly at all sizes.
5. Peter Paul Koch. 2010. A tale of two viewports — part two. In Quirksmode.
6. Using the Viewport on Safari. In Safari Web Content Guide.
7. The viewport meta tag. In Safari HTML Reference.
8. MDC. 2010. Using the viewport meta tag to control layout on mobile browsers. In Mozilla Developer Network.
9. Peter Paul Koch. 2010. Combining meta viewport and media queries. In Quirksmode.
10. Willison & Downe. Lanyrd.
11. Lie et al. 2010. Media Queries. W3C Candidate Recommendation 27 July 2010.
12. If you design your page for the narrow view and expect it to scale when rotated, then use width=device-width and nothing else. If, instead, you design your page for either width, then use width=device-width,initial-scale=1. This is the only way to get the android browser to render a page with the intended width. Mobile Safari will render the page exactly as if initial-scale=1 were specified alone. You will still end up with the zoom on rotate bug.
13. David Calhoun. 2010. The viewport metatag (Mobile web part I).