Week 6 - Mobile site creation

This week’s section of the CE will focus on the problem of delivering content on mobile devices. For a number of reasons we will touch on shortly, this section will deal primarily with creating web pages optimized for mobile, but we will also touch briefly on the possibility of creating our own apps.

In theory, creating content for mobile devices is quite easy. In fact, you are probably doing it right now, assuming you have any web presence at all, as any web page can be viewed on a mobile device. Anyone who has browsed the web on a mobile device, however, knows that this isn’t the whole story.

Viewport & Target size

Teeny-tiny buttons and microscopic text are the bane of the fat-fingered and the myopic, yet they are sadly the order of the day on the mobile web. Mobile browsers, when rendering a standard, desktop-optimized website will zoom out to the point of unreadability rather than squeeze the design into the much narrower window of the mobile device. This provides the user with a sense of the layout of the larger page, but tends to require a lot of very annoying zooming and scrolling.

      desktop-optimized                   mobile-optimized

When a mobile browser renders a desktop-optimized website, it does so in a somewhat different manner than a desktop browser. When a desktop browser encounters a style in the CSS that specifies, say, that the font in particular element should be rendered 11 pixels high, it simply sizes it to 11 pixels. When a style specifies a side bar with a width of 25%, the width of that element is relative to the size of the browser window. Carrying this practice over to the mobile web, however, would break the specified designs very badly. Instead, mobile browser render the content into two viewports: the layout viewport and the visual viewport.

The visual viewport is easily explained: its dimensions are the actual size of the screen and it contains whatever portion of the page is currently being viewed at whatever level of magnification. Pixel sizes, percentage widths, and the layout of the overall document, however, is calculated against the layout viewport, the width of which varies slightly from device to device. The iPhone version of Safari, for instance, uses a width of 980px, while Android uses 800px. When the visual viewport is zoomed out, it is identical to the layout viewport. As the user zooms in order to actually read the microscopic text, the visual viewport renders only a portion of the total layout viewport.

For a deeper explanation of this, check out A Tale of Two Viewports (part 1 and part 2) from Peter-Paul Koch’s excellent QuirksMode blog.

Mobile-optimized sites take control of this layout viewport and scaling by adding a <meta viewport> element in the HTML header. With this tag, designers can take control of the size of the layout viewport and thereby increase the default display size of the visual viewport. Setting the initial width of the layout viewport to the device-width, for instance, means that a 10 pixel element will be rendered 10 pixels high (more-or-less - in mobile, a pixel is not a pixel). The long and the short is that when a site has been optimized for mobile, the text is fully readable when first loaded.

One of the most important elements of any touch interface is the size of the targets you present the user. Fingertips are larger than a mouse pointer and require a larger target area in order for users not to be frustrated by false clicks. Apple, Microsoft, Nokia and other manufacturers have slightly different guidelines with regard to the minimum size for these elements, but a good rule of thumb is that interaction elements should be rendered no smaller than 9mm on the physical screen in order to be finger-usable: larger if they are frequently used or if a mis-click will prove particularly inconvenient.

There are other elements to consider, of course: resizing your images, simplifying your navigation, but at root, designing a website for a mobile interfaces is no more complicated than designing for any other website, in terms of the technology: it is still just plain old HTML and CSS.

Appropriately setting the <meta viewport> element can help the designer control the rendered size of the page’s elements. If someone (say, a vendor) shows you a “mobile version” of their product and the text is microscopic, you can be sure they’ve misunderstood even the most basic elements of the problem.

Device Detection

Some websites will automatically re-route mobile users to a mobile version of the site. While convenient, this can actually be one of the more complicated aspects of mobile design, and there are a wide variety of ways to do it. Keeping track of new devices as they come out, thankfully, is largely a solved problem as there are a number of community maintained efforts to help with that: WURFL, for instance, is a device description repository which makes it possible for a developer to write scripts to tell when a user is on a mobile device and reroute them appropriately. There are modules for WordPress and Drupal and many other content management systems which can handle that part of the problem for you.

Or you could avoid it entirely and rely on marketing. This is definitely the simplest solution. Forgoing redirection entirely, creating a prominent link to the mobile version of your site and then featuring it in your normal marketing materials (whether posters, newsletters, blog posts, etc.) will get you a long way and won’t require you to hire a developer. If you’ve read Week 5, you already have a pretty good idea of how to get started.

Responsive Web Design

It is also possible, using both the <meta viewport> tag and CSS media queries to create a single page which renders well in both mobile and desktop browsers.

To see an example, check out Cognition, the design blog for a large development shop call Happy Cog. On a desktop, the screen renders normally and looks pretty attractive. Now resize the screen, slowly narrowing the width and see what happens.

Did you see it?

The display slowly adjust through steps to render well through a gradually smaller viewport. On a mobile device, the exact same page and the exact same code renders just as attractively as it does on a larger screen.

This method was first described by Ethan Marcotte, a designer at Happy Cog, in an article in the web design magazine A List Apart: Responsive Web Design (check out his book).

When well done, this method can save an organization that means to have its entire site optimized for mobile from having to build an entirely new, parallel site. A few max-width queries in the CSS, a healthy bit of additional styling, and voila: welcome to the mobile web.

Mobile First

Designing for the mobile web can be frustrating for developers used to the vast amount of space in a typical desktop window. The constraints imposed by the smaller viewport require a great degree of discipline.

Let’s look at a quick illustration. First, check Southwest Airline’s main site. Lots of ad copy, lots of images, news items, special deals, travel guides: a lot of noise, making it much more difficult than it needs to be to find the few things on that site you are most likely to want to do: namely, book a flight, check an arrival status, or check in. Now check out their mobile site.

The mobile site is much more tightly focused and, frankly, much more usable. It’s all down to the constraints.

Recently, designer Luke Wroblewski has proposed a design methodology which uses those very constraints to help us focus our desktop-optimized sites as tightly as our mobile sites: Mobile First (check out his book on the subject).

Wroblewski’s idea is that the ideal design process will begin the mobile version of the site first, and then proceed to elaborate on that design in the desktop version with a high level of discipline already in place. By building first for the heavily space-constrained mobile form factor, designers are forced to consider the handful of options on their site which are most important. That exercise then informs the rest of the process.

As a quick exercise of your own, take a look at your institution’s website. If you were to redesign tomorrow with a mobile first methodology, which bits would make the cut? Now ask yourself: how much of what’s left actually needs to be there?

Apps vs. Websites

So far, we have focused exclusively on the creation of websites for mobile users, to the exclusion of native apps. The reason for that is relatively simple: apps are hard. Generally speaking, app development requires you to hire a programmer and to develop and maintain applications for multiple operating systems (iOS and Android at minimum, but perhaps also BlackBerry, Windows Mobile/Phone, etc. depending on your users).  The web however, uses technologies with which all libraries are already well familiar (HTML and CSS rather than Objective-C and Java) and works on any device with a browser: namely, all of them.

There are some downsides to a web-only approach, however. Mobile users are app-focused, and asking them to open a browser and either search or open a bookmark to get to your site may seem onerous in comparison to tapping their finger on an attractive little icon.

Lately there have been a number of frameworks which make it possible to build native apps using only HTML and Javascript, NimbleKit chief among them (there is also a NimbleKit for Android). These sorts of frameworks provide an opportunity to develop a native app for relatively low cost which will appear in iTunes or the Android Marketplace. To my knowledge no library has yet gone down this path, but it has significantly lowered the bar of entry into native app development and deserves serious consideration.

text here

Add a Comment - week 6

Comment3 - week 6