Designing for Mobile

Designing for Mobile

When designing a website always design for mobile first. The most crucial part for mobile applications is the context. Visitors browsing the site are not using a mouse, they are using their finger or stylist. The buttons for a mobile device should be no smaller than 44x44px.

There is no hover on a mobile device. That means buttons and hyperlinks need to be obvious, content cannot rely on :hover, avoiding drop-down menus without clear visual clues.

Mobile Design Patterns

The Carousel

Users can flick between each "card" by sliding over the screen to the left or to the right. Apps that use this pattern are normally information-rich but interaction-poor. Usually a single type of content organized in a linear set. In this structure there is no way to move between views more than one card away.

The Good

  • Simple to use.
  • Utilizes a whole screen to show content.
  • Requires a natural gesture for navigation.

The Bad

  • Relies on gestures–the user has to swipe from card to card.
  • All the information for a given page has to fit on the screen at the same time.
  • Each page needs to be conceptually the same.
  • Users have to progress through the sequence; they can't skip ahead.
Tab Bar

It is useful for quickly establishing the structure of an application. They allow users to move easily between broad sections and also acts as an anchor point, showing where the user currently is.

The Good

  • Provides a familiar navigation for users.
  • Allows easy switching between modes, views, or tasks.
  • Indicates the current state/location of the app.

The Bad

  • Its hierarchy is flat–there's no easy way to have nested subpages.
  • It always appears on the screen, taking up valuable real estate.
  • Only handles up to five navigation items effectively, and it is clunky beyond that.
List

Content is displayed in a vertical list, allowing users to scroll through the options. They can be used for presenting actionable options, such as an index for a long list of content. As a navigation hierarchy it lets users work their way through the structure. Can allow users to go from a broad selection to a single item. The main limitation of this is that once they go down the list they lose the ability to go back up. It is usually combined with the tab bar pattern to overcome that issue.

The Good

  • Flexible enough to handle lots of data.
  • Familiar and easy to understand.

The Bad

  • Inherently hierarchical.
  • Users need to return to the beginning to change paths.

Wireframing

Wireframing and sketching is a great way to gain a sense of how the flow and overall structure of the app will work.A wireframe is a low-fidelity visual representation of the layout of the application. It’s used to represent the basic page layout and navigational model. Sketches can provide a sense of the user experience as a whole, allowing us to spot potential usability problems before we commit too much time to building the interface.

Wireframe Tool Options
  • Pencil and Paper
    • Sometimes the simple tools are the best. It removes distraction and lets us focus on the task at hand. The downside is that when we want to iterate our design we have to redraw each layout.
  • Balsamiq, http://www.balsamiq.com/products/mockups
    • A simple wireframing applicationwith a range of common interface elements. It has a hand-drawn look that's designed to keep you focused on the structure rather than the appearance of your mockups.
  • Mockingbird, https://gomockingbird.com
    • Lets you build and share your wireframes in-browser. Has a similar sketchy style to Balsamiq.
  • Omnigraffle, http://www.omnigroup.com/products/omnigraffle
    • Mac-only application. Has a fully featured wireframing tool. Range of interface stencils that are available for free.

Interface Icons

It is important to find icons with the right metaphor to represent your content. When using them you have to make sure that users know their meaning or that they don’t already have a meaning and you want to use them for something else.

Interface Icon Sets
  • Glyphish, http://glyphish.com
    • A set of 200 or so icons that are available as a free set with attribution requirements, or US$25 for the Pro version.
  • Helveticons, http://helveticons.ch
    • Up to 477 icons based on the letterforms of the typeface Helvetica Bold. Costs between US$279 and US$439 depending on the set
  • Pictos, http://pictos.drewwilson.com
    • Three separate sets consitiing of 648 icons. Vector packs for each set are between US$19 and US$29.

A Pixel is no Longer a Pixel

When designing in mobile do not assume that it is being designed for a single resolution.

iPhone 3GS is 163ppi, iPhone4 is 326ppi, iPad is 132ppi, the Palm Pre is 186ppi. Android’s developer guidelines split its devices into three categories: low, medium, and high density screens.

Application Icons

This icon will be used in a number of places, but it will most likely end up on the users home screen. It is part of the application that people will see most often so it needs to be memorable and reinforce the function we offer.

Good application icons do one or more of the following:
  • Build from an existing brand iconography
  • Encapsulate the functionality of the application in a single image
  • Play off the name to reinforce the identity

Icons should be iconic.

General Rules when Designing Application Icons
  • Should be forward-facing. Want volume and presence, some perspective is nice, but don't go overboard.
  • Light source should be top-down.
  • Fill the entire background. While some platforms support transparent images, your app will look out of place on iOS without a complete background color.
  • Consider the icon's appearance at small sizes, and create one that is recognizable at every resolution.
  • Create artwork in a vector format.
  • Subtle texture will make surfaces feel more real and less clinical.
  • Keep It Simple.

Creating and Sizing the Application Icons

Application Icon Code

iOS supports a couple options for specifying home screen icons.
< link rel="apple-touch-icon" href="apple-touch-icon.png" />
< link rel="apple-touch-icon-precomposed" href="apple-touch-icon-precomposed.png" />

Application Icon Sizing
  • 114x114px for high-resolution display like the iPhone 4
  • 72x72px for iPad
  • 52x52px for everything else

Doctype Declaration

Doctypes are important: they tell the browser what sort of markup to expect and therefore how to parse the HTML we are giving it. Use conditional comments to create classes, in order to give us the option of targeting Internet Explorer7 mobile if we need to.

Internet Explorer 7 mobile

< !--[if IEMobile 7 ]>< html class="no-js iem7">< ![endif]-->
< !--[if (gt IEMobile 7)|!(IEMobile) ]>< !-->< html class="no-js">< ![endif]-->

Images and Pseudo-element

Using an image sprite is a technique often used in desktop web development. It is faster for a browser to download a single large image, rather than several small images.

Implementing Sprites

Create a single image that can be used as a background image for multiple elements. This background image is then repositioned to show the correct sprite in the correct place. The problem is it requires either:

  • Large, complex images that have enough padding around each sprite for the space they appear in.
  • Unnecessary markup that gives us a hook to crop the sprite tightly in place.

To avoid those pitfalls, create the additional elements using content generated in CSS pseudo-elements. This approach lets us alter the source of the sprite using only CSS.

Pseudo-elements can be used to insert "fake" elements into the page via CSS, allowing us to apply additional background images without affecting the markup of the page. Two pseudo-elements that can be used for the purpose of adding extra images are, :before and :after.

Clipping Sprites

By adding a clip property, we can clip the contents of a sprite without altering the overall size of the element.

  • .example {
    • background: #000;
    • clip: rect(0 50px 50px 0);
    • height: 100px;
    • width: 100px;
  • }

The element still thinks it is 100 pixels wide but only 50 pixels of its content is visible.
The four values in the parenthese after clip: rect, in order, are the distance to crop from:

  • 1. the top edge, measured from the top edge
  • 2. the right edge, measured from the left edge
  • 3. the bottom edge, measured from the top edge
  • 4. the left edge, measured from the left edge

The origin for all crop values is the top-left corner of the element. That is the only anchor point that won't change relative to the content in the clipped element.

Viewport

On the desktop, the viewport is a clear concept: it is the visible space in the browser window. On mobile devices, it’s a little more complicated, because the screen is usually smaller than the browser window.

Two Viewport Concepts

Visual Viewport: is the section of our page that's currently visible; Its size can be altered when a user scrolls or zooms to a different part of the page.

Layout Viewport: Refers to the size of the actual page.

On the desktop the visual and layout viewport are one and the same, but on mobile devices the browser needs to set a default for the layout viewport that's larger than the visual viewport.

Defaults differ between devices: Mobile Safari uses 980px, Opera Mini uses 850px, Android WebKit uses 800px, and IE uses 974px.

Viewport Meta

Using a meta tag we can override the default width. < meta name="viewport" content="width=device-width>

Other aspects of the viewport are:

  • height
    • Sets the height of the viewport in pixels. Can also be set to use device-height.
  • initial-scale
    • The zoom level of the screen. This usually defaults to whatever value will fit the entire width of the page on the screen.
  • minimum-scale
    • Sets the smallest scale the user can resize the viewport to. iOS default is 0.25, but the value can be set anywhere between 0 and 10.
  • maximum-scale
    • Set the maximum zoom level the user can resize the viewport to. iOS default is 1.6, but the value can be set anywhere between 0 and 10.
  • user-scalable
    • Specifies whether we want to let our users resize the viewport. The default is yes, and to disable scaling we can change the value to no.
  • target-densitydpi
    • Android-only property, for now, which gives us control over the rendered resolution of the target device. Can be set to device-dpi to match the screen densite of the device, but can have the effect of scaling your CSS pixel values up or down.

To change some or all the properties, use a single meta tag with comma-seperated values.
< meta name="viewport" content="width=device-width, minimum-scale=0.5, maximum-scale=2">