Mobile Design For Iphone and Ipad (Smashing Ebook Series)

Imprint
Published in November 2010
Smashing Media GmbH, Freiburg, Germany
Cover Design: Andrea Austoni
Editing: Thomas Burkert
Proofreading: Brian Goessling
Concept: Sven Lennartz, Vitaly Friedman
Founded in September 2006, Smashing Magazine delivers useful and

innovative information to Web designers and developers. Smashing
Magazine is a well-respected international online publication for
professional Web designers and developers. Our main goal is to support the
Web design community with useful and valuable articles and resources,
written and created by experienced designers and developers.
ISBN: 978-3-943075-01-4
Version: December 2011
Smashing eBook #4│Mobile Design for iPhone and iPad │ 2

Table of Contents
Preface
Mobile Web Design Trends

Mobile Web Design: Tips and Best Practices
How to Build a Mobile Website
Web Development for the iPhone and iPad: Ge!ing Started

How to Create Your First iPhone Application
iPhone Apps Design Trends
iPhone Apps Designs Reviewed
iPhone Apps Design Mistakes: Over-Blown Visuals

iPhone Apps Design Mistakes: Disregard of Context
Useful Design Tips for Your iPad App
Make it a Mobile Web App

How to Use CSS3 Media Queries to Create a Mobile Website
Forms on Mobile Devices
Se!ing up Photoshop for Web and iPhone Development

How to Market Your Mobile Application
A Study of Trends in Mobile Design
"e Authors

Preface
Web designers know that their industry changes quickly. Continuous
adaption and development of skills is necessary in order to always stay up
to date. Over the past few years, mobile web usage has increased to a point
that web designers can no longer afford to ignore it. As a result, web
designers have a growing need to be educated in this area and to be ready
to design websites that accommodate this audience.
This eBook presents articles on professional mobile design for the iPhone
and iPad, including studies of trends in mobile design and guidelines for the
development of mobile web pages. These articles are a selection of the
best from Smashing Magazine in 2009 and 2010 dealing with mobile design
for the iPhone and iPad plus an exclusive 90-page study about mobile web
design trends. The articles have been carefully edited and prepared as a
PDF version and versions for ePub and Mobipocket compatible eBook
readers, such as the Apple iPad and Amazon Kindle. Some screenshots and
links were removed in order to make the book easier to read and to print.
— Thomas Burkert, Smashing eBook Editor

Mobile Web Design Trends
Steven Snell
Web designers know that the industry involves plenty of change, and
continuous adaption and development of skills is required in order to stay
up to date. In the past few years, one of the biggest areas of change has
been the amount of Internet users who are accessing websites via phones
and mobile devices. As a result, Web designers have a growing need to be
educated in this area and to be ready to design websites that accommodate
this audience.
Because designing websites for mobile devices brings some unique

situations and challenges into play, the subject requires a strategic
approach from the designer and developer. In this article, we’ll look at the
subject as a whole, including current trends, challenges, tips and a
showcase of mobile websites. Plenty of helpful resources and articles are
also linked to throughout this article, so, if you’re interested in learning more
about designing for mobiles, you should have plenty of information at your
fingertips.
1. Simple options
One of the most intriguing things about mobile websites is the scaled-down
options that are available to visitors. The mobile home page of Digg, for
example, contains only 17 simple headlines and links, a log-in link and a few
very basic navigation options. When it comes to mobile websites, simplicity
is key. Because of the lack of space on the screen and Internet connections
that are often slower, it’s important for visitors to have access to what is
most crucial, and as little else as possible.

In an age of crowded pages, the simplicity of mobile websites can be
refreshing. What’s important is there, and what is most likely excess gets cut
out. The simple options that a user has can make a mobile website much
more usable than it would be otherwise, as long as the options allow for
actions the visitor wants to take.
2. White space
White space is an important part of any design, and it’s something that’s
usually a challenge in web design because there is a desire to get as much
as possible in front of the visitor. White space becomes even more of a
necessity in mobile design because the typical screen size is so much
smaller. A jumbled website would be very user-unfriendly and very difficult
to pull off in the mobile environment.

As you browse through the websites shown in the gallery further down in
this article or in real-world scenarios on your own mobile device, you’ll find
that many websites include ample white space, especially the ones that are
helpful and easy to use.
3. Lack of images
As high-speed Internet connections have become more common in recent

years, designers have been able to take more liberties with things like
bandwidth-hogging video and images. The average visitor on a desktop or
laptop wants to see a visually engaging website, and, as a result, images are
heavily used. However, when it comes to mobile design, excessive use of
images often does more harm than good.
There is a great variety of speeds of mobile Internet connections and of

pricing plans for access. Visitors are more likely to be slowed down or
concerned with use of their resources when they’re on a mobile.
Additionally, the size of the screens can make many images difficult to see
and content harder to read. For these reasons, it’s very common to see
minimal use of images in mobile Web design.
As a growing number of mobile users move to smart phones with larger

screens and better connection speeds, more opportunity exists to use
images. However, because there is still a large percentage of users who are
not using these devices, many mobile websites still avoid images when
possible.
4. Sub-domains instead of .mobi or separate domains
When the .mobi top-level domain (TLD) first became available, a lot of buzz
surrounded the news. While some websites use .mobi for mobile versions of
their websites, it is currently more common to see companies use a sub-
domain or a separate folder on their primary domain. There are multiple
issues a company must consider when making this decision, but one of the

major benefits of using a sub-domain is that it keeps everything on one
domain, rather than spreading things out and potentially confusing visitors.
You’ll commonly see mobile versions of websites at such addresses as

mobile.example.com, m.example.com, example.com/mobile, example.com/
m and other ones along these lines. Of course, there are exceptions to this
trend, but, as you look at the mobile versions of major websites, you will see
more sub-domains than .mobi TLDs.
5. Prioritized content
Because of the simplicity of these pages and the general lack of many
options, the content displayed is highly prioritized. One thing you may find
surprising when viewing mobile websites is how much of the content is
prioritized for the visitor. Of course, all websites should be user-focused,
but, because most websites are run commercially for business purposes,
there are often elements that aren’t necessarily important to visitors, such as
banner ads. While advertisements have largely become an accepted part of
the Internet, most mobile websites are ad-free. The content available on a
mobile website is typically of the highest priority to the average mobile
visitor, not the company, although in the end the company benefits by
having a more usable website.
Common Challenges in Designing for Mobiles

Of course, Web design for mobile devices brings its own unique set of
challenges that designers must overcome to create a successful mobile
website. If you’ve attempted to design for mobiles, these were probably
some of your most significant challenges.

1. Variety of screen sizes
Although Web designers are used to dealing with varying screen sizes and
the resulting issues, mobile design presents this challenge in a bit of a
different way than dealing with different-sized desktop monitors. Most
designers are comfortable with the challenges that arise from various
screen resolutions on desktop monitors, but, if you haven’t worked with
mobile design before, it can be something yet more complicated that you
need to overcome.
Because mobile technology is always changing, screen sizes are changing

too. Fortunately for designers, modern mobile devices typically have bigger
screens and higher resolutions than those of a few years ago, but of course
those older phones are still in use.
While we’re on the topic of mobile screen sizes, there are two excellent
articles from April of 2008 at Sender 11: Mobile Screen Size Trends and
More on Mobile Screen Size Trends. The results of the study behind these
articles show that 240 x 320 (a.k.a. QVGA) should be the standard for
mobile development. Many newer mobiles and smart phones have larger
screens, but smaller ones are largely a thing of the past.
The graph below shows the findings of the report, which is close to a year
old at this point. With the rise in popularity of the iPhone and its competitors,
the most recent numbers most likely favor larger screens even more.

For more interesting details on the study and other helpful charts and graphs,
please see both articles at Sender 11.
2. Lack of understanding
One of the biggest challenges that many designers face is just the
intimidation of dealing with a new aspect of design. If you haven’t
considered mobile browsers and visitors in your previous design work, it’s
most likely not something you feel comfortable doing without some
research. Because mobile browsers behave somewhat differently than
desktop browsers and, because the environment of its users is not the
same, the designer needs to gain some understanding and familiarity.
Through the information and resources presented in this article, you can
easily get started with a general understanding of the mobile Web, if you
don’t already have experience.

3. Rapid change
Like any other technology, rapid change is a constant. Of course, Web

designers need to stay on top of the industry in general, and the mobile
Web is no different. As technology and trends continue to change, the
mobile Web will evolve accordingly. The challenge of change isn’t really
anything new to designers; the mobile Web just presents another area in
which designers need to stay up to date.
4. Testing challenges
One of the most significant challenges in designing for mobiles is the wide
variety of phones in use. While designing for desktops brings its own testing
challenges with its various browsers and screen resolutions, there are more
dependable ways of testing these items at the moment. On the mobile Web,
however, many of your visitors will likely be accessing your website in an
environment that you were not specifically able to test.
There are, of course, some things you can do so that a mobile website is
tested as well as possible. To start with, the simplicity of mobile websites in
a way makes the testing process easier because there is less that can go
wrong. With a careful design and some well-planned testing, it’s possible to
be fairly certain that a website will be displayed properly and, more
importantly, usable on the vast majority of mobile devices.
There are a number of helpful resources for testing, we’d like to point out
here. First, the Web Developer Toolbar has some very useful features for
testing a website for mobile users. Because CSS and images may not be
enabled when a mobile visitor is on your website, you can use the toolbar to
disable both and see how the website will appear. While this does not
exactly replicate the experience of visiting the website in a mobile browser,
it can help identify potential problems in the way content and navigation is
displayed.

Another helpful testing resource is the Opera browser. In the Opera toolbar,
go to “View” and select “Small Screen.” This will display the website in a
very narrow window, similar to what would be used on a mobile device.
Additionally, you can use the Opera WebDev Toolbar to view an unstyled
page by clicking on “Display.” By viewing the page in the small screen with
CSS turned off, you can get an idea of how mobile visitors may experience
the website. The screenshot below shows the Smashing Magazine front
page unstyled in the small window.

5. Deciding on what is essential
If websites are to contain only what is most essential, the website owner or
designer will have to determine accurately what content is most important.
This may seem pretty simple, but taking a website that’s loaded with
content, images and maybe even video, and weeding it down to just the
essentials can be quite a challenge. Another aspect to this issue that must
be considered is the status of the average mobile visitor. What are they
doing? Why are they accessing the website at that time? What are they
likely and unlikely to have any interest in? Keep in mind that the goals of
mobile visitors are often vastly different than those of visitors sitting at a
desk.
Considerations for Mobile Design

Now that we’ve looked at some of the current trends and challenges in
designing for mobiles, let’s examine some specific issues that should be
considered by designers during the process.
1. Clean, semantic markup

The best thing you can do to lay a solid foundation for a usable mobile
website is to incorporate clean and semantic markup. What you may be able
to get away with on a traditional website may cause significant problems on
a mobile website. Clean markup will help ensure that the browser is capable
of properly displaying the website, and it will help give visitors a pleasant
experience, with no unnecessary difficulties.

2. Separation of content and presentation with CSS
Alongside clean, semantic markup is the need for the separation of content
and presentation. Mobile visitors are much more likely than desktop visitors
to see a website with images and CSS disabled. The most important thing
for these visitors is to be able to access the content and links – presentation
is secondary. A website that uses clean, valid markup, with CSS to separate
the presentation from the content, is off to a great start as a mobile website.
3. Alt tags
Because it’s likely that some visitors will not be able to see images on the
website (or will choose to disable them), alt tags are extremely important for
usability purposes. Of course, alt tags should be used anyway, but it’s even
more critical for mobile visitors.
4. Labeling form fields

Like alt tags, form field labels help make a website much more usable for
mobile visitors. Imagine trying to use a form without knowing what is
supposed to go where. Simple details like alt tags and form field labels can
make a big difference this way.
5. Use of headings
With inconsistent and often limited styling of text on mobile browsers,
headings become more significant. Mobile browsers are less likely to style
text exactly how you would like it to be, but h1, h2, h3 and other such tags
generally help make certain text stand out and build the structure of the
page from a visitor’s perspective.
6. Avoid floats if possible

Even if a mobile browser correctly displays a website that uses floats for
layout, it’s unlikely the website will look good on a small screen. Usually the
website will be more usable and look less awkward without floats altogether
and with content simply stacked up.

7. Reduce margins and padding
Most likely, your mobile website should have smaller margins and padding
than your main website has for traditional visitors. Of course, this depends
partly on how much of a margin and padding your website currently has, but
very large amounts can make the layout awkward.
8. Pay attention to navigation

Most websites have a primary navigation menu very high on the page. This
is helpful on mobile websites as well, but generally, mobile navigation
options are scaled down. Provide only the most relevant links, and, if
possible, give visitors an easy way to access the other navigation items.
9. Consider Color Contrast

Because mobile screens may not have the same appearance as desktop or
laptop monitors, make sure the background and text colors provide
adequate contrast so that the content can be read easily.
Sitepoint’s Designing for the Mobile Web

Sitepoint published an article, Designing for the Mobile Web by Brian Suda,
that provides an excellent point of reference on the subject. In the article,
Brian breaks down the process of designing for mobiles in seven
understandable and digestible steps. The article is useful enough to restate
the main points here.
1. Don’t mix up your markup
For most websites, we can ignore WML and make use of the markup
language with which we’re probably much more familiar: XHTML.

2. Know your phones
We must cater not only to different screen sizes and resolutions, but to
different shapes. From short and long rectangles to tall and skinny ones to
perfect squares, the mobile world contains a rich tapestry of variation that
almost makes you want to pull your hair out!
3. Target the right customers
Traditional website customers are most likely sitting at a desk facing a large
monitor that has a decent resolution. Visitors who are browsing your mobile
website are unlikely to be in the same circumstances. They may be waiting
in line, riding on the train or bus, running to the departure gate or lost in an
unfamiliar town late at night and trying to get somewhere.
4. Publish the bare minimum
While the concept of having only one website, and simply styling it
differently depending on the medium the visitor is using, is popular with
many standardistas, a separate mobile website is required to deliver an
optimized experience for mobile users.
5. Choose a great domain name
When deciding on a domain name for a mobile website, the colleagues and
companies I’ve worked with have always used a sub-domain. Creating a
sub-domain is the easiest of the options to set up (you already own the
domain), it’s the cheapest option (there’s no need to register the .mobi), and
it means you avoid having to spend hours tweaking the server (and
potentially messing up normal traffic).

6. Validate your markup
Mobile browsers are much less forgiving than desktop browsers. A browser
running on a mobile device generally doesn’t have the luxury of a 2 GHz
processor and 200 GB of disk space. Therefore, you must check, validate
and recheck your markup, time and time again.
7. Test, Test, TEST!
Testing your website with a Web browser on a desktop computer can get
you only so far in terms of simulating the mobile experience. There are
many elements of mobile device usage that can’t be replicated accurately in
this way.
Brian’s article is an excellent starting point for those who are new to
designing for mobile devices, and it’s also a great resource to have handy
down the road when you want to check your work to make sure you’re
doing things the right way.

Mobile Web Design: Tips and Best
Practices
Cameron Chapman
In Year 2009, more than 63 million people in the United States accessed
the Internet from a mobile device. It’s forecasted that by 2013 there will be
more than 1.7 billion mobile Internet users worldwide. With those kinds of
numbers, it’s imperative that web designers and developers learn optimal
development and design practices for mobile devices.
For the most part, you won’t need to learn any new technologies for mobile
site design, but you will need to look at site design in a new way, one that is
decidedly more restrictive than design for standard browsers. To work
around the issues that mobile site design presents, and to get a result that is
as user-friendly and useful as your standard site, some creative problem-
solving skills are required.
Familiarize Yourself with the Hardware and

So!ware Available
Cell phone and mobile device platforms vary greatly when it comes to
operating system, screen size, resolution, and user interface. To be able to
decide which platform(s) you want to optimize your site for, it would be
helpful to familiarize yourself with the different available options.
The most common operating systems in use are Windows Mobile, the
iPhone platform, Palm OS, Mobile Linux, Symbian OS, the BlackBerry
platform, and Android (which is poised to get a lot bigger thanks to a recent

deal between Verizon and Google). There are other proprietary systems
specific to particular phones, such as those found on some Verizon
handsets and specific brands of phones. You can estimate, based on the
type of audience your site targets, which OSs your users are most likely to
be using. If your visitors are mostly business users, you’ll need to optimize
your site for Windows Mobile and BlackBerry devices. If your users are
younger, trendier, or more tech-savvy, you’ll want your site optimized for
iPhones and Android devices. In any case, ensure your site is at least usable
on the majority of mobile platforms.
StatCounter Global Stats – Top 8 Mobile OSs
http://gs.statcounter.com/#mobile_os-ww-monthly-200812-201010

Mobile browsers are another factor to consider. Some of the more common
browsers include Safari for the iPhone, Android browser, Opera Mobile,
WebOS browser (on Palm devices), BlackBerry browser and Internet
Explorer Mobile (on Windows Mobile devices). There are additional
browsers in use on Nokia and on other phone brands. Some of these
browsers are based on proprietary code, while others are built on WebKit
(Android, Safari), Gecko (Fennec, a Mozilla browser) or other common
platforms.
StatCounter Global Stats – Top 9 Mobile Browsers
http://gs.statcounter.com/#mobile_browser-ww-monthly-200901-200910
Finally, you need to consider your site visitors’ most common screen size
and resolution. Your site should work on the widest range of mobile devices
that your visitors might be using.

Simplify!
Your mobile site, in most cases, should be simpler than your standard site.
The only exception to this is if your standard site is already very minimalist.
Eliminating graphic elements from your site is usually an effective way to
optimize its display on a mobile device. Look for ways to simplify both the
design and functionality of your site. This might mean redoing your menus,
eliminating images, breaking up text over multiple pages, or otherwise re-
working your site’s layout and functionality.
Examples

Use Valid Markup
Considering the variety of potential operating systems and browsers from
which people might be accessing your site, web standards become even
more vital. Standard browsers are, for the most part, very forgiving of bad
code, but with a mobile browser you often won’t get that kind of leeway.
Make sure your code validates and is as clean and minimalist as possible.
Give Users the Option of Visiting the Standard Site

Depending on what kind of device your visitors are using, they may want to
just use your standard website. This is particularly true with a lot of the
better smartphones and the iPhone, the latter of which does an excellent
job of rendering standard websites without issue. Give your mobile visitors
the option of visiting the standard site, even if it’s just through a link in the
footer (where most of us are already predisposed to looking). You could
additionally give them the option to come back to the mobile site without
having to use their back button.

Examples
Use a Separate Mobile "eme

While optimizing your main site for mobile use sometimes makes sense, it’s
often easier to use a separate mobile theme, which can be done on most
CMSs by changing the CSS for mobile devices. A dedicated mobile theme
means you can really take into account how your visitors will see your site
and optimize it specifically for them. Some sites have one design optimized
for regular mobile devices and another for iPhone users.

Examples
Limit Scrolling to One Direction

It’s really annoying to have to scroll in multiple directions on a web page
when using a standard browser. That doesn’t change when you’re visiting
from a mobile device; in fact, it’s worse. It’s very easy to accidentally scroll
the wrong way (horizontally instead of vertically or vice versa) when using a
touchscreen phone. If your site only scrolls one way, you eliminate the
potential for such a hassle.

Examples
Don’t Use Pop-Ups or Open New Windows

Depending on the particular platform, popups and new windows can
interfere with the browsing experience, so don’t use them. If you absolutely
need something to open in a new window, make sure you alert your mobile
visitors that it will do so.

Minimize the Use of Images
Use only the images you need to get your message across. A logo is fine, as
are most icons. Images that are integral to the content on your site are also
fine. But eliminate images that serve no purpose other than to look pretty.
They generally won’t look pretty on a mobile device anyway, so why bother?
And sometimes they just make your site look worse, or cause strange
scrolling or layout issues if the resolution is other than what you were
expecting.
Examples

Optimize Your Navigation
Many mobile devices have touchscreen interfaces, so try to design with that
in mind. That means making the clickable area around your links a little
greater, making buttons larger, and putting more space between links.
Trying to click on tiny, barely-visible links is a real pain, and having to zoom
in every time you want to click on something doesn’t make it much better.
To improve these navigation issues, many sites use a completely separate
mobile navigation design, optimized for touchscreens or non-mouse input
devices.
Examples

Don’t Rely on Flash or JavaScript
Not all phones and mobile devices support Flash or JavaScript. Even if they
do, there’s no guarantee it will be the most recent version. And forget about
Flash if your visitors are using an iPhone. Make sure all the important
information and functionality on your mobile site is in plain (X)HTML/CSS.
Otherwise, you risk a large portion of your visitors being unable to access
important content.

Include as Much Content from Your Standard Site as
is Practical
How many times have you gone to a favorite website from your phone and
then realized you can’t get to the part you wanted to visit? It happens all the
time. Include as much of the original site content as possible on your mobile
site. In addition to making it available, make sure the navigation route to get
to it also remains relatively unchanged.
Examples

Make Sure Redirects Work Properly
Don’t just send mobile users to your home page. There’s nothing more
annoying than clicking a link, either in search engine results or from another
website, and having it redirect to the homepage if you’re on a mobile
device. If your site automatically detects whether a visitor is coming from a
mobile browser, make sure it’s set up to send that visitor to the link they
were trying to visit, otherwise they’re likely to leave and never come back.

How to Build a Mobile Website
Jon Raasch
Over the past few years, mobile web usage has increased to a point that
web developers and designers can no longer afford to ignore.
In wealthy countries, the shift is being fueled by faster mobile broadband

connections and cheaper data service. However a large increase has also
been seen in developing nations where people have skipped over the PC
and gone straight to mobile.
Unfortunately, the mobile arena introduces a layer of complexity that can be

difficult for developers to accommodate. Mobile development is more than
cross-browser, it should be cross-platform. The vast number of mobile
devices makes thorough testing a practical impossibility, leaving developers
nostalgic for the days when they only had to support IE6.
In addition to supporting different platforms, each device may use any

number of mobile web browsers. For instance, an Android user could
access your site using the native Android browser, or could have also
installed Opera Mini or Firefox Mobile. It’s fine as long as the smartphone
uses a progressive web browser (and it’s safe to say that most browsers are
progressive nowadays), but it doesn’t have to.
Furthermore, the mobile web reintroduces several issues that have been
largely ignored in recent years. First, even with 4G networks, bandwidth
becomes a serious issue for mobile consumers. Additionally, mobile devices
have a significantly reduced screen size, which presents screen real estate
issues that have not existed since the days of projection monitors.

Combine these issues with cross-platform compatibility problems, and it isn’t
hard to see how mobile development is a lot like “stepping backwards in
time”. So let’s tackle these issues one at a time and create a road map for
mobile web development.
• How To Implement Mobile Stylesheets

• What To Change With Mobile Stylesheets
• Beyond Stylesheets
• Special Concerns For iPhone / iPad
How To Implement Mobile Stylesheets

The first step to adding mobile support to a website is including a special
stylesheet to adjust the CSS for mobile devices.
Server-side Methods & The UA String
One approach to including mobile stylesheets involves detecting the user

agent string with a server-side language such as PHP. With this technique,
the site detects mobile devices and either serves an appropriate stylesheet
or redirects the user to a mobile subdomain, for instance m.facebook.com.
This server-side approach has several advantages: it guarantees the highest

level of compatibility and also allows the website to serve special mark-up /
content to mobile users.
While this technique is perfect for enterprise level websites, there are
practical concerns that make it difficult to implement on most sites.
New user agent strings come out almost daily, so keeping the UA list
current is next to impossible. Additionally, this approach depends on the
device to relay its true user agent, however historically browsers have
spoofed their UA string to get around this type of detection. For instance,

most UA strings still start with “Mozilla” to get through the Netscape checks
used in the 90′s, and, for several years, Opera pretended to be IE. As Peter-
Paul Koch writes:
It’s an arms race. If device detection really catches on, browsers will
start to spoof their user agent strings to end up on the right side of the
detects.
Clientside Methods & Media Queries
Alternately, the easiest approach involves detecting the mobile device on

the clientside.
One of the earliest techniques for including mobile stylesheets involves

taking advantage of the stylesheet’s media type, for instance:
<link rel="stylesheet" href="site.css" media="screen" />

<link rel="stylesheet" href="mobile.css" media="handheld" />
Here we’ve included two stylesheets, the first site.css targets desktops and
laptops using the screen media type, while the second mobile.css targets
mobile devices using handheld.
While this would otherwise be an excellent approach, device support is

another issue. Older mobile devices tend to support the handheld media
type, however they vary in their implementation: some disable the screen
stylesheets and only load handheld, whereas others load both.
Additionally, most newer devices have done away with the handheld
distinction altogether, in order to serve their users fully-featured web pages
as opposed to duller mobile layouts.
To support newer devices, we’ll need to use media queries, which allow us
to target styles to the device width. Since mobile devices typically have
smaller screens, we can target handheld devices by detecting screens that
are 480px and smaller:

<link rel="stylesheet" href="mobile.css" media="only screen
and (max-device width:480px)"/>
While this targets most newer devices, many older devices don’t support
media queries, so we’ll need a hybrid approach to get the largest market
penetration.
First, define two stylesheets: screen.css with everything for normal browsers
and antiscreen.css to overwrite any styles that you don’t want on mobile
devices. Tie these two stylesheets together in another stylesheet, core.css:
@import url("screen.css");
@import url("antiscreen.css") handheld;
@import url("antiscreen.css") only screen and
(max-device-width:480px);
Finally, define another stylesheet handheld.css with additional styling for

mobile browsers, and link them on the page:
<link rel="stylesheet" href="core.css" media="screen"/>

<link rel="stylesheet" href="handheld.css" media="handheld,
only screen and (max-device-width:480px)"/>
While this technique reaches a large market share of mobile devices, it is by

no means perfect. Some mobile devices such as iPad are more than 480
pixels wide and will not work with this method. However these larger
devices arguably don’t need a condensed mobile layout.
Moving forward there will likely be more devices that don’t fit into this mold.
Unfortunately, it is very difficult to future-proof mobile detection, since
standards are still emerging.
Besides device detection, the media query approach also presents other
issues. Mainly, media queries can only style content differently and provide
no control over content delivery.

For instance, a media query can be used to hide a side column’s content,
but it cannot prevent that mark-up from being downloaded by your users.
Given mobile bandwidth issues, this additional HTML should not simply be
ignored.
User Initiated Method
Considering the difficulties with mobile UA detection and the pitfalls of

media queries, some companies such as Ikea have opted to simply allow
the user to decide whether to view the mobile version of their website.
While this has the clear disadvantage of requiring more user interaction, it is
arguably the most fool-proof method and also the easiest to accomplish.
The site contains a link that reads “Visit our mobile site” which transports
the user to a mobile subdomain. This approach has some drawbacks. Of
course, some mobile users may miss the link, and other non-mobile visitors
may click it, since it is visible regardless of what device is being used. Even
though, this technique has the advantage of allowing the user to make the
mobile decision. Some users prefer a condensed layout that is optimized for
their device, whereas other users may prefer to access the entire website,
without the restrictions of a limited mobile layout.

What To Change With Mobile Stylesheets
Now that we’ve implemented mobile stylesheets, it’s time to get down to the
nuts and bolts of which styles we actually want to change.
Increase & Alter Screen Real Estate
The primary goal of mobile stylesheets is to alter the layout for a smaller
display. First and foremost, this means reducing multi-column layouts to
single columns. Most mobile screens are vertical, so horizontal space
becomes even more “expensive” and mobile layouts can rarely afford more
than one column of content.
Next, reduce clutter throughout the page by setting display: none; on any
less important elements.
Finally, save additional pixels by reducing margins and padding to create a

tighter layout.

Reduce Bandwidth
Another goal of mobile stylesheets is to reduce bandwidth for slower mobile

networks. First make sure to remove or replace any large background
images, especially if you use a background image for the whole site.
Additionally set display: none on any unnecessary content images.
If your site uses images for buttons or navigation, consider replacing these
with plain-text / CSS counterparts. Finally if you’d like to force the browser to
use the alternate text for any of your images, use this snippet (and use
JavaScript to add the as-text class for img and make sure that alt-attributes
are properly defined in your markup):
img.as-text { content: attr(alt); }
Other Changes
Besides addressing screen size and bandwidth concerns, there are a few
additional changes that should be made in any mobile stylesheet.
First improve readability by increasing the font size of any small or medium-
sized text. Conversely, heading text often appears too heavy on mobile
devices, so consider removing the extra font weight:
h1, h2 {
font-weight: normal;
}
Next, clicking is generally less precise on mobile devices, so make sure to

increase the clickable areas of any important buttons or links.
Additionally, floated elements can cause problems for mobile layouts, so

consider removing any floats that aren’t absolutely necessary. Remember
that horizontal real estate is especially expensive on mobiles, so you should
always opt for adding vertical scrolling as opposed to horizontal.

Finally, mouseover states do not work with most mobile devices, so make
sure to have proper definitions of :active-states. Also, sometimes it may be
useful to apply definitions from the already defined :hover states to
the :active states. This pseudo-class is displayed when the user clicks an
item, and therefore will work on mobile devices. However this only
enhances the user experience and should not be relied on for more
important elements, such as drop-down navigation. In these cases it is best
to show the links at all times in mobile devices.
Beyond Stylesheets
In addition to mobile stylesheets, we can add a number of special mobile
features through mark-up.
Clickable Phone Numbers
First, most handheld devices include a phone, so let’s make our phone
numbers clickable:
<a href="tel:15032084566" class="phone-link">(503) 208-4566

</a>
Now mobile users can click this number to call it, however there are a few
things to note. First, the number in the actual link starts with a 1 which is
important since the web is international (1 is the US country code).
Second, this link is clickable whether or not the user has a mobile device.
Since we’re not using the server-side method described above, our best
option is to simply hide the fact that the number is clickable via CSS. So use
the phone-link class to disable the link styling in your screen stylesheet, and
then include it again for mobile.

Special Input Types
When it comes to mobile browsing, another concern is the difficulty of

typing compared to a standard full-sized keyboard. But we can make it
easier on our users by taking advantage of some special HTML5 input
types:
<input type="tel" />

<input type="email" />
These input types allow devices such as iPhone to display a contextual

keyboard that relates to the input type. In the example above type="tel"
triggers a numeric keypad ideal for entering phone numbers, and
type="email" triggers a keypad with @ and . buttons.

HTML5 input types also provide in-browser validation and special input
menus that are useful in both mobile and non-mobile browsing.
Furthermore, since non-supportive browsers naturally degrade to view
these special input types as <input type="text" />, there’s no loss in using
HTML5 input types throughout your websites today.
See a complete list of HTML5 input types. You can find some information
about browser support of HTML5 input attributes in the post HTML5 Input
Attributes & Browser Support by Estelle Weyl.
Viewport Dimensions & Orientation
When modern mobile devices render a webpage, they scale the page
content to fit inside their viewport, or visible area. Although the default
viewport dimensions work well for most layouts, it is sometimes useful to
alter the viewport. This can be accomplished using a <meta> tag that was
introduced by Apple and has since been picked up by other device
manufacturers. In the document’s <head> include this snippet:
<meta name="viewport" content="width=320" />
In this example we’ve set the viewport to 320, which means that 320 pixels
of the page will be visible across the width of the device.
The viewport meta tag can also be used to disable the ability to resize the
page:
<meta name="viewport" content="width=320, user-

scalable=false" />
However, similar to disabling the scrollbars, this technique takes control

away from the user and should only be used for a good reason.
Additionally, it is possible to add certain styles based on the device

orientation. This means that different styles can be applied depending on
whether the user is holding their phone vertically or horizontally.

To detect the device orientation, we can use a media query similar to the
clientside device detection we discussed earlier. Within your stylesheet,
include:
@import url("portrait.css") all and

(orientation:portrait);
@import url("landscape.css") all and
(orientation:landscape);
Here portrait.css styles will be added for vertical devices and the
landscape.css will be added for horizontal.
However orientation media queries have not been adopted by all devices,
so this is best accomplished with the max-width media query. Simply apply
different max-width queries for the different orientation widths you want to
target. This is a much more robust approach, since presumably the reason
to target different orientations is to style for different widths.
Special Concerns For iPhone/iPad

With a market share of 28% and estimates of as much as 50% of mobile
browsing going through iPhone, it makes sense that developers make
special accommodations for the mobile giant.
No Flash
Regardless of Apple’s reasons, the reality is that iPhones do not play Flash
unless they are jailbroken. Fortunately, there are now usable alternatives to
Flash, so iPhone’s issues with this technology are easy to get around for
most websites.
Beyond video, it is usually best to use Javascript to accommodate any

simple functionality. Javascript libraries such as jQuery make it easy to build
rich interactive applications without Flash. Regardless of your desire to

support iPhone, these Javascript apps typically have a number of additional
advantages over Flash alternatives.
Finally certain applications are simply too hard to recreate with HTML5 and
Javascript. For these, iPhone users will have to be left out; however, make
sure to include appropriate alternate content.
Other Shortcomings
Besides Flash, there are a few additional caveats to supporting iPhones and
iPads.
First, iPhone does not support <input type="file" />, since it does not have an
accessible internal file structure. While most mobile devices connect to a
computer as an external hard-drive, Apple has taken steps to ensure that
the iPhone file structure remains obfuscated.
Next, iPhone only caches assets that are 25 kb or less, so try to keep any
reused files under this restriction. This can be a bit counter-intuitive, as it
often means breaking out large image sprites and concatenated Javascripts
into smaller chunks. However be careful to only serve these assets to
iPhone, or it will cause extra HTTP requests in all other browsers.
Finally, when it comes to @font-face font embedding, iPhone’s Mobile Safari

doesn’t fully support it and supports the SVG file format instead. However
SVG fonts are only supported by Chrome, Opera and iPhone, so we’ll need
a hybrid approach to target all browsers. In addition to the SVG, we’ll need
an .otf or .ttf for Firefox and Safari, as well as an Embedded Open Type
(EOT) for IE (believe it or not, IE has actually supported @font-face since IE4).
After obtaining the necessary files, tie them all together with the appropriate
CSS:
@font-face {
font-family: 'Comfortaa Regular';

src: url('Comfortaa.eot');
src: local('Comfortaa Regular'),
local('Comfortaa'),
url('Comfortaa.ttf') format('truetype'),
url('Comfortaa.svg#font') format('svg');
}
Special iPhone / iPad Enhancements
Despite iPhone’s various shortcomings, the device offers a wonderfully rich

user experience that developers can leverage in ways not possible with
older mobile devices.
First, there are a variety of Javascript libraries that can be used to access
some of the more advanced functionality available in iPhone. Take a look at
Sencha Touch, jQTouch and iui. These three libraries allow you to better
interface with the iPhone, and also work on similar devices such as Android.
Additionally, keep an eye on the much anticipated jQuery Mobile, which has
just been released in alpha.
Next, the App Store isn’t the only way to get an icon on your users’ iPhones
– you can simply have them bookmark your page. Unfortunately, the default
bookmark icon is a condensed screen shot of the page, which doesn’t
usually look very good, so let’s create a special iPhone icon.
Start by saving a 57 x 57 pixel PNG somewhere on your website, then add

this snippet within your <head> tag:
<link rel="apple-touch-icon" href="/customIcon.png"/>
Don’t worry about rounded corners or a glossy effect, iPhone will add those
by default.

Conclusion
As the worldwide shift to mobile continues, handheld device support will
become increasingly important. Hopefully this article has left you with both
the desire and toolset necessary to make mobile support a reality in your
websites.
Although mobile occupies a significant chunk of global web browsing, the

technology is still very much in its infancy. Just as standards emerged for
desktop browsing, new standards are emerging to unify mobile browsers.
This means that the techniques described in this article are only temporary,
and it is your responsibility to stay on top of this ever-changing technology.
In fact, the only thing in web development that remains constant is the
perpetual need to continue learning.

Web Development for the iPhone and
iPad: Ge#ing Started
Nick Francis
According to AdMob, the iPhone operating system makes up 40% of the

worldwide smartphone market, with the next-highest OS being Android at
26%. Sales projections for the Apple iPad run anywhere from one to four
million units in the first year. Like it or not, the iPhone OS, and Safari in
particular, have become a force to be reckoned with for Web developers. If
you haven’t already, it’s time to dive in and familiarize yourself with the tools
required to optimize websites and Web applications for this OS.
Thankfully, Safari on iPhone OS is a really great browser. Just like Safari for
the desktop, it has great CSS3 and HTML5 support. It also has some slick
interface elements right out of the box, which sometimes vary between the
iPhone and iPad. Lastly, because the iPhone OS has been around for quite
some time now, a lot of resources are available.
I know that most discussion about the iPhone OS platform centers on native
applications. But you can still create powerful, native-looking applications
using HTML, JavaScript and CSS. This article focuses on three phases of
building and optimizing your website: design, coding and testing.
Before we get into the three phases, let’s look at some of the advantages
and disadvantages of building a Web app rather than a native app.
Advantages of building a Web app instead of a native app:

1. No Apple approval process or red tape, which is especially important
given the terms of service dispute going on right now.
2. Optimizing your Web app for other popular platforms, like Android and
Blackberry, with the same code is much easier.
3. You don’t have to learn Objective-C.
4. If you’re charging users, you don’t have to share revenue with Apple.
5. You get 100% control over the means of payment, promotion and
distribution to users… which could also be a negative, depending on
how you look at it.
Disadvantages of building a Web app instead of a native app:
1. No presence in the App Store.
2. Installing the app on a device is a little trickier.
3. No access to some of the features that are native to the iPhone OS,
such as push notification and GUI controls.
Design
Designing a Web app for this platform is much like designing a native app,
so you’ll have access to some really great tools. Whether your wireframing
tool of choice is pencil and paper or desktop software, you’re covered.
Inspiration
Not many people know that Apple has a “Web apps” section on its website,
which is dedicated to showcasing optimized websites.

Featured Web app on the Apple website
Paper
Paper prototyping has long been my tool of choice for wireframing new
ideas or websites. What I really like about the tools below is that they
provide perspective on the size and dimensional constraints that you’re
dealing with. To successfully optimize a Web app for the iPhone OS, you
have to cut things out. I suggest keeping the design minimal by wireframing
with a sharpie and one of the tools listed below.

Digital
Once you know exactly how things will lay out in your design, we can move
to the desktop and get specific. I really like wireframing with OmniGraffle,
but sometimes diving straight into Photoshop makes sense. Either way,
these tools are a huge help in making it happen.
iPad GUI preview from Teehan + Lax.

Coding
When you start coding for Safari on the iPhone OS, understanding how the
browser works is important. Also, there are subtle differences between the
iPhone and iPad’s browsers, such as how form-select boxes work. Most
importantly, Safari has great CSS3 and HTML5 support, so you can use
modern code without having to worry about cross-browser compatibility.
Education
Apple actually does a really good job of documenting Safari for the iPhone
OS. The only shortcomings in my opinion are a lack of help with browser
detection and window orientation. Read each of the articles below for
everything you need to know about coding for this browser.
iPhone Human Interface Guidelines for Web Applications

This is a good overall summary of how Safari for the iPhone OS works. It’s
certainly worth scanning through, because it has some good advice,
although no specific coding examples.
iPad Human Interface Guidelines

This document does a good job of distinguishing iPhone elements and iPad
elements. This is also worth scanning through, because it has some great
advice on designing for the iPad.
Safari Web Content Guide

This document gets specific about the viewport, webclip icons, unique meta
tags and event handling, among many other topics. Code examples are
provided. I recommend reading it cover to cover before getting started.
Browser Detection
David Walsh provides good examples of proper browser detection for the
iPad and for the iPhone on his blog. Options for PHP and Javascript are
included.

Detecting iPhone Window Orientation
This iPhone development tutorial from Nettuts provides a good example of
how to vary style sheets according to the iPhone’s orientation.
Detecting iPad Window Orientation

Detecting iPad’s window orientation is much easier. Here’s what the code
looks like (no JavaScript required):
<link rel="stylesheet" media="all and (orientation:portrait)"

href="portrait.css">
<link rel="stylesheet" media="all and (orientation:landscape)"
href="landscape.css">
jQTouch Mobile Framework

While the iPhone has a few mobile development frameworks, jQTouch is far
and away the best. jQTouch gives you all of the tools to make your mobile
Web app look and feel like a native one.
My only complaint when building my first website with jQTouch was a lack of
documentation and tutorials. I had to figure it out by playing with the demo
website’s code.
Testing
A crucial and somewhat tricky part of building a website or Web app for the
iPhone OS is testing. It’s a little more complicated than testing in a web
browser, but familiarizing yourself with a couple of tools should make the
process simple.
Liveview
Liveview is a really clever testing tool for when your app is in the design or
initial coding phase. It allows you to broadcast an image from your desktop
onto your phone so that you can see what it looks like. This is useful for
getting text size and the visual specifics just right, because sometimes
visualizing from Photoshop is hard.
Using the iPhone Simulator
In my opinion, no good iPhone or iPad emulators are available. The ones

that are available are a waste of time. Much better is to download the latest
version of the SDK and use Apple’s official iPhone OS simulator, which of
course supports the iPad as well.

Setting up the SDK and a local testing environment takes a few minutes but
is well worth the effort, rather than depending on unofficial and often
inaccurate emulators. I’ve written a step-by-step tutorial about setting up a
local testing environment that’s worth a read. One great thing about local
testing is that it’s faster and does not require an Internet connection. I highly
recommend going this route until you are ready to launch.
PhoneGap: Best of Both Worlds?

PhoneGap is a game-changer for Web developers. If you would rather
create your app in HTML, CSS and JavaScript but want it to run natively and
have it be available in the App Store, then PhoneGap is the solution. It’s an
open-source development tool that not only compiles your code for native
use on the iPhone OS but also works for Android, Palm, Symbian, Windows
Mobile and Blackberry devices.
Feeling Overwhelmed?
If you are, then some good hosted services will make it easier to optimize
your website for multiple platforms without having to start from scratch.
There are various levels of flexibility available, but all the services use a
WYSIWYG-like editor to help you create mobile websites on the fly.
Depending on your Web app and client, one of the following may be a good
fit:

Mobify is a great alternative if you don’t care to build from scratch.
Conclusion
It’s a great day to be a Web developer, because non-desktop platforms like
the iPhone OS open up greater possibilities for us to express our creativity
and entrepreneurial savvy, while allowing us to adhere to modern Web
standards. All of the tools you need to create a great Web experience on
the platform that’s currently dominating the mobile space are out there. It’s
up to you to make the most of them!

How to Create Your First iPhone
Application
Jen Gordon
What if you had a nickel for every time you heard: "I have the perfect idea
for a great application!"? It’s the buzz on the street. The iPhone has created
unprecedented excitement and innovation from people both inside and
outside the software development community. Still for those outside the
development world, the process is a bit of a mystery.
This how-to guide is supposed to walk you through the steps to make your
idea for an iPhone app a reality. This article presents various ideas,
techniques, tips, and resources that may come in handy if you are planning
on creating your first iPhone application.
Have an Idea – a Good Idea

How do you know if your idea is a good one? The first step is to even care if
your idea is solid; and the second step is to answer the question: Does it
have at least one of the indicators of success?
Does your app solve a unique problem? Before the light bulb was invented,
somebody had to shout out, “Man, reading by candlelight sucks!” Figure out
what sucks and how your app can make the life of its user more
comfortable.
Does the app serve a specific niche? Though there aren’t any stats on the
App Store search, the usage of applications is certainly growing with the

explosion of App Store inventory. Find a niche with ardent fans (pet lovers,
for example) and create an app that caters to a specific audience.
Does it make people laugh? This is a no-brainer. If you can come up with
something funny, you are definitely on the right track and your idea may be
the golden one. Heck, I hit a red “do not press” button for 5 minutes
yesterday.
Are you building a better wheel? Are there existing successful apps that lack
significant feature enhancements? Don’t be satisfied with just a wine list,
give sommeliers a way to talk to their fans!
Will the app be highly interactive? Let’s face it, most of us have the attention
span of a flea. Successful games and utilities engage the user by requiring
action!
Action: Does your app fall in to one of these categories? If yes, it’s just about
time to prepare the necessary tools.
Tools Checklist
Below is a list of items you’ll need (* Starred items are required; the rest are
nice-to-have’s):
• join the Apple iPhone Developer Program ($99) *

• get iPhone or iPod Touch *
• get an Intel-based Mac computer with Mac OS X 10.5.5,
• prepare a Non-Disclosure Agreement*
• download and install the latest version of the iPhone SDK
• a spiral bound notebook*

What Are You Really Good At?
What skills do you bring to the table? Are you a designer whose brain
objects to Objective C? A developer who can’t design their way out of a
paper sack? Or maybe you are neither, but an individual with an idea you’d
like to take to the market? Designing a successful iPhone application is a lot
like starting a small business. You play the role of Researcher, Project
Manager, Accountant, Information Architect, Designer, Developer, Marketer
and Advertiser – all rolled into one.
Remember what all good entrepreneurs know – it takes a team to make a

product successful. Don’t get me wrong, you certainly can do it all. But you
can also waste a lot of time, energy and sanity in the process. Don’t go
crazy, reference the checklist below and ask yourself: What roles are the
best fit for you to lead? Then find other talented people to fill in the gaps.
The infusion of additional ideas can only enrich the product!
Skills checklist
• Ability to discern what works/doesn’t work in existing iPhone Apps

• Market research
• Outlining App Functionality (Sitemap Creation)
• Sketching
• GUI Design
• Programming (Objective C, Cocoa) (we assume here that we are
creating a native application)
• App Promotion and Marketing

Remember to have contractors sign your non-disclosure agreement. Having
a contract in place tells your contractor "I’m a professional that takes my
business and this project seriously. Now don’t go runnin’ off with this idea."
Action: Select skills that are a good fit for you to lead. For those roles where
you cannot lead, hire professionals.
4. Do Your Homework: Market Research

Market research is a fancy way of saying "Look at what other people are
doing and don’t make the same mistakes." Learn from the good, bad and
ugly in the App Store. Coming up with creative solutions in the app concept
development and design starts with analyzing other (maybe similar)
applications. Even if you encounter a lot of poorly designed apps, your mind
will reference these examples of what not to do.
Action: Answer these questions:
• What problem does your app solve?

• What products have you seen that perform a similar task?
• How do successful apps present information to users?
• How can you build on what works and make it unique?
• What value does your app bring to your audience?
5. Know the iPhone/iPod Touch UI

If you want to create an iPhone app, you need to understand the capabilities
of the iPhone and its interface. Can you shoot a .45 caliber bullet out of your
iPhone? No. Can you shoot videos? Yes!

The good news is that you don’t have to memorize the encyclopedic Apple
User Interface Guidelines to get a feel for what works and what doesn’t in
iPhone Apps. Download and play with as many apps as you can, and think
about what functionality you want to include in your product.
Take note of:
• How do well-designed apps navigate from screen to screen?

• How do they organize information?
• How MUCH information do they present to the user?
• How do they take advantage of the iPhone’s unique characteristics: the
accelerometer, swiping features, pinch, expand and rotate functions?
Action: Download the Top 10 apps in every category and play with all of
them. Review the Apple Guidelines for UI design and list at least 5 features
you’d like to incorporate into your app.
6. Determine "Who will use your app?"

We assume here that you’ve already determined that your app will bring
value and that you will have a raging audience for your app. Well, fine, they
are raging fans, but who are they really? What actions will they take to
achieve their goals within the app?
If it’s a game, maybe they want to beat their high score. Or perhaps they are
a first time player – how will their experience differ from someone who is
getting a nice case of brain-rot playing your game all day?

If it’s a utility app, and your audience wants to find a coffee shop quickly,
what actions will they take within the app to find that coffee shop? Where
are they when they’re looking for coffee? Usually in the car! Do present an
interface that requires multiple taps, reading and referencing a lot? Probably
not! This is how thinking about how real-life intersects design.
Action: Line item out the different types of people who will use your app.
You can even name them if you want to make the scenarios you draw out as
real as possible.
7. Sketch Out Your Idea

And by "sketch" I mean literally sketch. Line out a 9-rectangle grid on an 8.5
x 11 sheet of paper and get to sketching!
Ask yourself:
• What information does each screen need to present?

• How can we take the user from point A to point B to point C?
• How should elements on the screen be proportioned or sized in relation
to each other (i.e. is this thing even tap-able?)
Thumbnailing your ideas on paper can push your creativity far beyond
where your imagination might stagnate working in an sketching application!
You can also buy the iPhone Stencil Kit to quickly sketch out iPhone UI
prototypes on paper.
Action: Create at least one thumbnail page of your application per screen.
Experiment with various navigational schemes, the text you put on buttons,
and how screens connect. If you want to transfer your sketches into digital
format, iPlotz is a good tool to check out.

8. Time for Design
If you are a designer, download the iPhone GUI Photoshop template or our
iPhone PSD Vector Kit. Both are collections of iPhone GUI elements that will
save you a lot of time in getting started. If you’ve solidified your layout
during sketching, drawing up the screens will be less of a layout exercise
and more about the actual design of the app.
If you are not a designer, hire one! It’s like hiring an electrician to do
electrical work. You can go to Home Depot and buy tools to try it yourself,
but who wants to risk getting zapped? If you’ve followed steps 1–3, you’ll
have everything you need for a designer to get started.
When looking for a designer, try to find someone who has experience
designing for mobile devices. They may have some good feedback and
suggested improvements for your sketches. A few places to look for
designers: Coroflot, Crowdspring, eLance. When posting your job offer, be
very specific about your requirements, and also be ready to review a lot of
portfolios.
Action: If you are a designer, get started in Photoshop. If you are not a
designer, start interviewing designers for your job.
9. Programming
Even though this how-to is sequential, it’s a good idea to get a developer on
board at the same time when you line up design resources. Talking with a
developer sooner than later will help you scope out a project that is
technically feasible and within your budget.

If you are a Objective C/Cocoa developer crack, open Xcode and get
started! If you are not a developer, you know what to do – find one! Specify
the type of app you want to produce – whether it is a game, utility or
anything else. Each type usually requires a different coding skill set. A few
places to look for developers: Odesk, iPhoneFreelancer, eLance and any of
the forums listed above.
10. Submit your application to Apple Store

OK, so how do you submit your application to Apple Store now? The
process of compiling your application and publishing the binary for iTunes
Connect can be difficult for anyone unfamiliar with XCode. If you are
working with a developer, ask them to help you:
• Create your Certificates

• Define your App ID’s
• Create your Distribution Provisioning Profile
• Compile the application
• Upload to iTunes Connect
Action: If you are a developer, map out a development timeline and get
started. If you are not a developer, start interviewing devs for your job.
11. Promote Your App

If a tree falls in the middle of the woods and nobody was around to hear it,
does it make a sound? Apps can sit in the store unnoticed very easily. Don’t
let this happen to you. Be ready with a plan to market your app. In fact, be
ready with many plans to market your app. Be ready to experiment, some
ideas will work, others won’t.

Strategies for maintaining/boosting app sales:
• Incorporating social media. If your users make the high score on his or
her favorite game, it is a good idea to make it easy for the user to post it
to Facebook or Twitter. Think about how your app can incorporate
social media and build that functionality into your app. At a minimum,
set up a fan page for your app on Facebook and Twitter and use them
as platforms to communicate with your users and get feedback on your
app.
• Pre-launch promotion. Start building buzz about your app before it has
launched. E-mail people who write about things that relate to your app
and see if they will talk up the upcoming release of your app.
• Plan for multiple releases. Don’t pack your app with every single
feature you want to offer in the very first release. Make your dream list
for the app and make sure that the app is designed to incorporate all of
the features at some time in the future. Then periodically drop new
versions of the app to boost app store sales.
Action: Make a list of 20 promotional strategies that target the audience for
your app. Take action on them yourself or hire someone who can!
11. Stay Focused and Don’t Give Up!

It’s easy when you are working on your first app to get all AppHappy,
dreaming up a zillion new app-ideas. Dream, but don’t get sidetracked by
new ideas. Your first app needs to make a big splash and getting involved in
too many projects at once can dilute your passion for making your first
application a success.
Action: Get out there and go kick some app!

iPhone Apps Design Trends
Jen Gordon
For the past two years, the elegant iPhone has housed some of the most
poorly designed applications you could imagine. The hype surrounding
iPhone has prompted many designers across the globe to try their skills with
the new mobile medium. The result are literally thousands of various iPhone-
applications that are often hardly usable and counter-intuitive. However,
some designers invest a lot of time and efforts into creating usable and
original user interfaces (yes, there are usable and creative UIs).
This article explores the ways in which designers use graphical elements
and screen interactions to create iPhone-applications that are easy on the
eyes and mind. The aim of this article is to display common trends and
design approaches in iPhone app design – please notice that they are not
necessarily optimal ones from the design or usability point of view.
Mirroring Native iPhone UI Elements

“Tell them what you’re gonna tell them, tell them, and then tell them what
you told them.” Creating a whole new OS within your app can be fun, but
when you’re dealing with the mobile medium, people just want to get stuff
done. Getting stuff done means that the designer has to get into the flow of
the OS and create an app that requires zero explanation for the end user to
operate. Mirroring the layout and UI elements that the user is already
familiar with saves time and energy. So it seems quite convenient to use this
approach when designing iPhone-applications.

Facebook
In the new Facebook 3.0, you’ll find a grid layout that users can swipe left
and right to access more categories. Because it mirrors Apple’s native UI,
users do not have to “learn” how to use it all over again. A similar approach
exists in Web design: users expect to see a logo in the top left, navigation
along the top, etc. Facebook has taken this concept mobile, using large
buttons that are easily distinguishable and tap-able

Where
Where has a similar concept, allowing users to swipe left and right to access
more data.

Tweetdeck
Tweetdeck is a good example of user interface design on many levels.

Notice how the design highlights recent updates. The application could
display the updates in a new window, with a categorized or tabbed list. But it
doesn’t. Instead, a more familiar dialogue menu is displayed — it serves as a
springboard to jump to a specific category or to clear the messages
altogether.

Simplifying "e Interface
Simplifying user interfaces may sound like a mechanical task, but what lies
beneath the surface of user interface design? The answer is simple: users.
And what do users want? What makes them all warm and fuzzy? How do
you deliver what they want so that they don’t even notice how they are
consuming information?

Flickr
Flickr is another example of how to achieve a good balance between

functionality, visual design and the small display area on mobile devices.
Think about it: what is at the core of Flickr? Photos. Its users probably do not
want to look at big clunky navigational elements; instead, they are looking
for pictures. Flickr has managed to fit all of its core functionality without
heading down the highway to navigational hell. In fact, most elements in the
navigation are handled by interacting with the photos themselves. Simple
and smart.

Hardware-ish Look
Many utilities are breaking out of the conventional iPhone UI to take
advantage of the device’s unique ability to respond to finger gestures. Many
of these have hardware-ish interfaces that users are familiar with but come
with perpetually shiny exteriors and clicks and pops that maintain their
newness from the first to one-thousandth click.

Little Snapper
Little Snapper mimics the wheel that you turn on a typical digital SLR.

Where To?
This application looks like it belongs in a Mercedes. Plush leather, matte-

finish tactile buttons: quality craftsmanship. We can just imagine how each
button press feels solid, requiring the perfect amount of pressure.

Rich, Padded And Pre#y List Views
You know that you are a geek designer when you get excited about the
latest trends in list view design. And what do people do when they
encounter a list view? Of course, they skim. And how do we make it easier
for people to decide what interests them? That’s right: more visual cues!
Essentially, users are asking for a snapshot of what’s next, and then decide
if they want more information. One way to do this is with big pretty buttons.
Large and in charge, elegantly-designed, big buttons give the user a lot of
information through their color, icons and typography.

Delivery Status Touch
Check out how Delivery Status uses appropriate colors on its big buttons to
identify each brand. And it uses typography well to establish a hierarchy of
information.

Be Happy Now
Be Happy Now’s big buttons convey the “be happy” mantra through a
mellow color scheme and light, calm and clear typeface.

Next Read
The Next Read application allows friends to share books. Here all books
about a particular topic are presented, including the title, cover image,
review rating and number of people who have recommended it. Notice the
padding and a lot of white space for each navigation option; this makes the
areas easily clickable and easier to navigate.

Layered Interface
Several applications take advantage of the iPhone’s capabilities by layering
the interface and making some elements stationary and others vertically or
horizontally scrollable. This approach has several benefits:
1. It reduces the number of traditional navigation elements that are

necessary (i.e. fewer buttons help to avoid a cluttered interface).
2. It gives users a faster route to the information they want.
3. More screen space is available for information.

Barnes & Noble
Barnes & Noble has a layered interface that allows you to quickly slide
through new releases at the top or dive into more categories below.

USA Today
USA Today takes a slightly different approach to layering the interface in its
“Pictures” section: it uses sliding panels to display blocks of information.
While the interface may look cluttered at the first glance, one can easily get
around it. The interesting part is that within each panel you can slide
thumbnails left and right to view more images.

myPantone
Would we expect any less from Pantone? The color picker shown above is a
layered interface that lets you pick from a range of colors, sort and scroll as
well as open and close detail screens, all without driving you crazy.

Icons For "e List View
Icons aren’t just for springboard-loving folks. On small screens, icons can
give a huge boost to an application’s usability and navigation. Let’s now
take a look at some examples of applications that use icons to their
advantage.

iStudiez
This application uses various educational metaphors as icons to clearly

communicate the purpose of the application. Excellent visual cues tell the
student what’s happening today at a glance.

Top Floor
Top Floor uses simple and easily recognizable icons to quickly guide users
to their category of choice.

New York Times
Isn’t it great when applications just let you do whatever you want to do? For
an app with as much information as the New York Times’, users are bound
to have their favorite sections. Well, guess what? The New York Times
cares: it lets you customize the tab bar’s navigation to include only your
favorite sections of the paper. Drag an icon down the tab bar and you are
set. The downside of the design is, of course, its lack of visual appeal.

Illustrations in use
Applications that rely on graphics not found in the standard user interfaces
are increasing in popularity, as developers try to set their apps apart from
the crowd. Sometimes it works, but often it doesn’t. The more
unconventional a design is, the more likely it is to have usability problems.
Please always conduct usability testing before releasing a product with a
“creative” user interface.

Magnetic Personalities
An excellent example of how buttons don’t have to look like standard

buttons.

SugarSync
This interface could have easily followed the traditional list-view route.
Instead, the designers played with the concept of “connectivity” to create a
visual treatment that communicates the purpose of the app. It is unusual and
requires some time to get used to.

Mom Maps
Another example of how illustrations do a great job of pulling together the

whole concept of an application.

Using Gestures
Classic linear navigation may look boring: a button that links to other
buttons, which leads you to a list of something, which leads you to such-
and-such an interaction. Not really spectacular. The possibilities for creative
interaction in utility apps are huge and largely untapped (no pun intended).

Mover
Mover exemplifies how to use gestures for sharing contacts, photos and
bookmarks. Open two devices, and flick the shared files from one handset
to the other.

ABC Animals
This application teaches while it entertains. Being able to trace a letter with
your finger is another example of how the iPhone responds to touch and
movement.

All Recipes
This applications allows you to mix in various elements to create your next
meal using gestures.

iPhone Apps Designs Reviewed
Alex Komarov
Some time ago I started a mobile app design review section on our
company’s website. The idea behind this “Crit Board” was simple: if mobile
developers want to create apps that people want to buy, they’ll need help
with design and usability. But most of the time they can’t afford it. On our
Crit Board, developers can send us their mobile apps (iPhone apps, Android
apps, Blackberry apps) along with questions and problems, and we (free of
charge) will pick apart key usability issues, illustrate our design
recommendations and post our findings.
The only condition to get free criticism from us is that you agree for it to be
made public, which is why I am able to share several case studies with
Smashing’s readers right now. It’s hard to imagine something more relevant:
these are real problems facing real developers. I hope these problems and
the proposed solutions will benefit others who have similar issues and will
be generally relevant to those working in the field.
1. Foobi
“Alex, I am the lead designer and developer of Foobi. Foobi was
designed to track your diet in a different way; instead of tracking
calories and tapping on many drilled-down lists, it works by simply
tracking servings per food group and providing an overview of your
food intake balance.

Although I have tried really hard not to over-design it by tracing Apple’s
footsteps while building custom UI control elements, I would love to
hear from you about this subject. — Remy”

Your app is beautiful indeed. And it is also usable and easy, exactly as you
describe it. If the user knows how to flick, he is already an expert. An expert
in what, though?
As stated in the iTunes description, the purpose of this app is to “track and
balance your diet.” I understand the two main user goals as follows:
1. To record what food they consume,
2. To make sure they stay on the right path with their nutrition, and to
have a clear guide to balancing their diet if they veer off that path.
Your app does a good job of fulfilling the first goal: users can easily record
what they eat just by selecting the right food group and adding the amount
of “servings” consumed.

But what about the second more important goal of tracking progress and
adjusting one’s diet? Does the app help customers achieve this goal? Not
very well. There is room for big improvement.
There are two main problems with this part of the app.

Summary information is hidden
To access the summary chart, you have to flip the iPhone to the side and
view it in landscape mode. But this feature is not communicated through the
app’s design, so a user will discover it only by accident. When we talk about
fulfilling a major user goal, it is important never to rely on accidents to
communicate functionality.

Summary information is not well designed
Additionally, the summary is not informative enough.
The summary chart doesn’t offer too much to the viewer. Here are the main
problems:
• It’s not clear what the different colors mean, and there is no legend to
help.
• The scale is not flexible. You can view the information only by week,
which does not allow users to easily see their big-picture eating habits.
(Tip: consider incorporating the pinch gesture to allow users to scale in
and out.)
• Tracking consumption of a particular food group is not possible with this

chart but would be valuable to users.

Information design is a vast topic. There are a million ways to address the
problems that I’ve highlighted and to increase the visibility of useful
information for your audience. I recommend reading Edward Tufte’s books,
particularly The Visual Display of Qualitative Information.

And here’s an inspiring display of a lot of information. Of course, it’s not
tailored to mobile use, but it has a few great ideas:
From Google Finance.

One more thing
When I purchased and downloaded your app, I didn’t quite understand why
it was taking so long to download… until I realized that it had already
downloaded. I was fooled by the app icon, which makes it look like it is still
downloading:
2. Budget Planner
“Alex, please take a look at my app Budget Planner. I have tried
everything, and it keeps going up and down. The major issues that
people complain about are intuitiveness and slowness. People don’t
understand what the software does. But people who do learn it love it.
— Alex Sabonge”
The basic idea of this app is very good, and the App Store description
shows off its functionality well:”Budget Planner tracks your bills, budget,
calendar and transactions by displaying your balance in a calendar view,
letting you know how much money you will actually have on any particular
day. Like a balance forecaster.”
Here’s an overview of how Budget Planner works:
1. Users input their monthly salary info and plug in their fixed monthly
expenses (utilities, phone, car payment, etc).

2. Using this data, the app allows users to track their cash flow and
predict the amount they’ll have in the bank on any given day.

Most folks would find this extremely useful. So, why are people complaining
about the app? Why does it have an average rating of 2.5 out of 5 stars, and
why are sales lower than you had hoped?
Let’s look at the main sources of the problem. For now, we’ll set aside lesser
(though important) usability factors, such as not following the iPhone UI
guidelines and using the standard controls improperly. Let’s start at the
beginning. Humans invented money to buy things, right? Your core
audience’s main goal is to know what they can afford and when they can
afford it, whether it’s a new pair of shoes, a new car or a solid retirement
plan.
People don’t prepare a budget just for fun. They make the effort because
they hope it will help them make better purchasing decisions (read: buy
more stuff that they like), without their rent check bouncing. Your app is
getting there. But several key factors are getting in the way of a great user
experience. Let’s take a closer look at the app’s “landing screen,” the
calendar, the main element that differentiates this app from other budget
apps.
First of all, I think the calendar is a great idea. It’s much better than the
categorized lists that many other apps have. The calendar is all about how
much money you have or will have in future. A list only shows how much
you’ve spent. Knowing that your money is gone doesn’t really help achieve
a financial goal (purchasing a shiny new laptop, for example).
Here are some downsides to the calendar view:

I believe there’s a way to visualize information in the current design so that
users are able to uncover “invisible” patterns. Uncovering the details and
patterns behind their spending habits enables users to get new ideas, make
informed decisions and achieve their financial goals (and praise your app in
the process). Users will better understand their bad habits and be able to
take steps to correct them.
A graph could provide richer possibilities for visualizing financial information.

It’s much more flexible and scalable than a calendar. Using a graph for the
landing screen could dramatically increase the density of meaningful data
while reducing visual noise. Here are some ideas we came up with; this is
merely a draft we put together to illustrate our points and to get your ideas
flowing—it is not a proposal for a final design:

Next steps
People love apps that help them achieve their goals. What if your app
allowed users to input and compare different financial scenarios, shown
through several overlaid graphs?
This capability could help users think through their options:
• If I put my child through this private school, would I still be able to afford
the Beemer I’ve always dreamed of?
• How many hours of overtime would I need to work to be able to afford
both?
These are few examples of questions that people ask themselves. If your
app can help them get the answers, I think it’ll really catch on, and you’ll
soon be driving a shiny new Beemer yourself.
3. Units United
“Unit conversion app, Units United. Yep, yet another one… ;) Can you
please review it?
— Meils Dühnforth”

The biggest problem with almost every unit converter I have seen is that
they require users to submit their query in a format that the computer (or
iPhone in this case) can understand. Most unit converters force people to
make double the effort to get what they want.
Consider the following scenario: you’re from the US, and you are recounting
yesterday’s baseball game to your Icelandic friend. During their last at bat,
the Phillies hit a 456-foot home run. Amazing! You punch the value into your
unit converter app, but to get an answer you must translate the query into a
format that the application understands:
1. Go to “Categories,”
2. Select meters for the “To” unit,
3. Select feet for the “From” unit,
4. Type in 456 on the number pad,
5. Double-check that you are converting 456 feet into meters and not
vice versa.
Are all these steps necessary? You just wanted to know “What is 456 feet in
meters?” But you had to ask the question in robo-speak. You had to select
options from a list to be understood. Good software speaks your language.
Among the innumerable unit converters, only Google does it right, allowing
you to ask your question in plain English:

Using speech recognition technology is another good idea. Sometimes your
hands aren’t free when you need to convert a unit. Say your Icelandic friend
is driving on a US highway and needs to convert the 55 miles-per-hour
speed limit into kilometers.
Implementing everything described above, your app might look something

like this (this quick draft is meant to illustrate the point and is not a design
proposal):

This application is much easier to use because there’s no more robo-talk: it
doesn’t force users to browse categories and sub-categories, and it accepts
questions in everyday language.

iPhone Apps Design Mistakes: Over-
Blown Visuals
Alexander Komarov
The development of iPhone applications has recently become a hot topic in

the design community; everybody tries to come up with some creative idea,
port it into a stylish iPhone-alike application and sell it to thousands of users
through the iPhone app store. However, many of these applications are
poorly designed and therefore miss the chance of providing users with a
truly useful product that users would find worth recommending to friends
and colleagues.
We want to take a closer look at the design of iPhone applications and

showcase some good and bad examples, best practices as well as useful
ideas and recommendations for your next iPhone app design.
Are iPhone apps really not good enough?

“It’s only 99 cents. Who cares if it sucks? I’m still trying it.” How many times
have you said something like that to yourself before downloading the next
promising iPhone app? How many screenfuls of those apps do you have on
your iPhone? 4? 6? 10? And how many of them do you actually use?
On average, only 3% of people who have downloaded an app use it after 30

days. Why? Because the majority of iPhone apps don’t make any sense to
users. The situation is similar to that of PC software a couple of decades
ago. Have we not learned from our mistakes?

iPhone applications nowadays are designed by developers who seem to
care only about their app’s implementation. When an app goes live, its
beautiful code or visual design often fail to address real customers’ needs.
The result is thousands of useless applications in the App Store that people
download and use once and then never again. These applications often
don’t make sense to customers because of a poor interaction design.
Free applications usage over time: Percentage of users returning versus number
of days since first used. On second day, 20% returning users; on the 30th day,
only 3%. By Pinch Media.

Paid applications usage over time: Percentage of users returning versus number
of days since first used. It’s not really different from the graph above. Paid
applications generally retain their users longer than free applications, although
the drop-off is still pretty steep. By Pinch Media.

Users stop using the average applications pretty quickly. Long-term audiences
are generally 1% of total downloads. By Pinch Media.

Hilarious 500 million downloads breakdown, by Gizmodo. (Copyright: Gizmodo)
It shouldn’t be this way. Developers should be writing applications that

people love so much that they would pay $9.99 or even $99.99 for each of
them. There’s no programming technique that teaches you how to do this.
But there is something else, and it’s called interactive design.
Five Most Frequent iPhone Design Mistakes

Many applications share the same design problems that prevent customers
from fully enjoying them. Recently, I conducted a review of 100 apps from
the App Store and identified the five most frequent iPhone design and
usability mistakes, which are:

1. Over-blown visuals.
2. Neglecting technological limitations, such as slow Internet connection,

slow processors and single-threaded OS architectures.
3. Confusing navigation (flow, layout and taxonomy).
4. Confusing the iPhone with a computer. Neglecting to use new iPhone

interactions (fingers instead of the mouse; multi-touch gestures; turn, tilt
and rotate) and technological features such as phone functions, built-in
GPS and accelerometer.
5. Disregard of context. A lack of understanding of how, when, where and

why the mobile device is being used.
Let’s start with the first one in this article and proceed with the next ones in
the follow-ups to this article.
Mistake #1. Over-Blown Visuals

Probably the oldest, yet extremely popular design problem is overdesign.
Designers of iPhone applications often tend to disregard common design
and usability conventions by offering users slick and shiny user interface
designs that go way beyond their standard look and also way beyond their
claimed functionality.
Why make things look, feel and work complicated, and why do designers
like to re-invent the wheel? The answer is simple: they want the application
to be different, look different and stand out from the crowd. Unfortunately, a
different look isn’t necessarily helpful for application’s usability and
functionality.
So how does an overdesign in iPhone applications look like? To better

understand it, let’s look at an example:

Motion X GPS settings.
What do you think is wrong with the design in this first screenshot? Some of
you may say, “Well, nothing is really wrong with it. It’s beautiful.” I agree, it’s
pretty slick. But, there’s a catch: while beautiful, it is also inconsistent with
other apps. It’s different. Let’s compare this screen to the settings screens of
other iPhone applications:

Motion X GPS settings screen, compared to the settings screens of other apps.

Noticed the difference? Being inconsistent with other products makes yours
worse for two reasons:
1. Going against convention makes your application less intuitive. Over-

styled controls look different and require users to re-learn how they
work.
2. It’s a waste of time and money. The resources you have spent to make
your app look different, but not necessarily better, could have been
used much more effectively.
Breaking convention makes your app less intuitive
The more familiar the parts of your app are, the more intuitive the app will
be for whoever uses it. If we recognize the parts, we will be able to learn
how to use the whole faster. It’s like reading: knowing the alphabet and
meanings of words allows us to “decode” books we haven’t seen before.
Here’s an example from the real world. Try to make the stop sign more
“beautiful” and people will inevitably start dying:

“Sign B, 2, ‘STOP,’ shall be used to notify drivers that, at the intersection where
the sign is placed, they shall stop before entering the intersection and give way
to vehicles on the road they are approaching.” Article 10 of 2006 road signs
convention.

In his paper Intuitive Equals Familiar (Communications of the ACM. 37:9,
September 1994, page 17), Jeff Raskin, an American human-computer
interface expert best known for starting the Macintosh project for Apple
Computer in the late 1970s, writes:
“The impression that the phrase ‘this interface feature is intuitive’ leaves
is that the interface works the way the user does, that normal human
‘intuition’ suffices to use it, that neither training nor rational thought is
necessary, and that it will feel ‘natural.’”
However,
“… it is clear that a user interface feature is ‘intuitive’ insofar as it

resembles or is identical to something the user has already learned. In
short, “intuitive” in this context is an almost exact synonym of ‘familiar.’”
Drastically redesigning every user interface element will make your

application less intuitive, which will lead to more user mistakes and a longer
learning curve. Eventually, you will lose customers because of it.
What about branding?
Is there place for branding in applications that are strictly following general
design guidelines and usability conventions? Definitely! It is possible to
strike a balance between having a unique look but not over-designing.
Here’s one example:

Let’s take a look at an example of overdesigning by Bloomberg. Here, we
have an overdesigned text input field at the top. You can barely recognize
this as a field when you first look at it. The version on the right hand side is
much better. A standard input field makes the screen’s purpose much
clearer, while remaining consistent with the application’s style and branding.

Here is another example by iFitness. Users are supposed to enter their
weight day-by-day on this screen. But you have to flip through the months
and days with a horizontal swipe to find the right one, and then you have to
enter your weight digit by digit using five separate scroll fields. And then
you have to press the very modest “Record” button, which you miss at first
anyway and only find the hard way – after you have lost data. Much better:

99.9% of users will want to enter today’s weight. This redesigned interface
has one-quarter of the controls. The screen space that has been saved can
now be used to present useful information, such as weight statistics. Date
and time can be recorded automatically, and the selection of the metric or
imperial system of measurement, which is not terribly important, has been
demoted to a settings screen.
The Yellow Pages app uses tabs, which work well on the Web, but standard
toggle controls are more familiar to iPhone users.

Waste of time and money
Apple has already done an excellent job of creating standardized controls.

Losing some of that functionality is almost guaranteed if you try to reinvent
the wheel.
Back to our earlier example:

If we take a closer look, we’ll see that one-third of the screen space we
would have had is now lost because of over-designing.

iPhone OS 3.0 introduced accessibility features. One of the modes is White
on Black. Here’s what happens to our controls after inverting colors:
In the original control, color, shape and text survived color inversion.
However in re-designed one, 2/3 of original meaning is lost. Now there is
only text.
In sum, this redesign has given us twice as many UI elements, taking up

twice as much real estate. The catch is, even if you haven’t made the
controls worse, you still haven’t added much value and you have lost time
and money in the process.
That time and money could have been spent on…
Design is all about solving problems. Sometimes, when people don’t know
exactly what problem they are solving, they wander in the design process,
and the result is over-designed. To avoid that, you must have a clear picture
of the problem you need to solve.
One of the best ways to get that picture is to talk to your users (both current
and potential). Only when you know your customers’ needs will you be able
to build an application they’ll love.
Don’t overdesign. Be sure your house has a solid foundation before you
decorate it. You will be rewarded with more loyal customers and higher
download rates surprisingly quickly.

iPhone Apps Design Mistakes: Disregard
of Context
Alexander Komarov
The iPhone will always be part of a much bigger picture. How well you
address human and environmental factors will greatly determine the
success of your product. All too often, iPhone developers create products in
isolation from their customers. In order to create really appealing
applications, developers must stop focusing only on the mechanisms of the
apps. Zoom out. Understand the person using the application, as well as the
complex environmental factors surrounding that person.
To better understand the context of these design challenges, we’ll highlight

several levels of human and environmental factors.
Level 1: You Are Here. To Create An App "at

Customers Love, Zoom Out
Level 1: The app itself.
This is how many developers view their apps. As a developer, you have a
vision of what your product should look like and why customers will turn
their attention to it. However, if you observe your product so closely, you
may put it in the wrong context and design it for the wrong purposes and for
the wrong users. This is why you need to zoom out.

Level 2: A person is using this app.
That person has specific goals and challenges. In the section below we’ll
start by exploring some of the most prominent – and most ignored – human
factors pertaining to the iPhone. We’ll discuss basic physical ergonomics,
visual limitations and common design mistakes.
Level 3: That person is using this app in a specific environment.
Step back and you’ll see that the app is a part of a complex social
environment. It plays but a relatively small role in communication between
people and helping people accomplish bigger goals. This is where the
social components comes into play: networking, community, social-driven
websites and applications and many other things create the environment –
or the context – in which the application will be used.
Level 4: The environment is part of a greater culture.
Your ability to address the unique needs of different cultures will affect the
success of your product. Ignoring them is too expensive, especially if your
app sells worldwide. Here it is important to understand that the environment
is a part of global networking. You need to be aware of cultural differences,
traditions and metaphors in order to create an application that will not only
gain popularity in certain local circles, but will also have a global success.

Level 2: Understand "e Person’s Needs And
Limitations
“Measure twice and cut once”: an effective strategy indeed. For you, the
iPhone app developer, this means that you have to step back and answer
these questions before you start coding:
• Who will be using your application?

• What are the capabilities of that person?
• What are the limitations of that person?
Answering these questions will broaden your perspective and prepare you
to address your customer’s needs. A whole Human Factors profession is
dedicated to just that.
Basic physical ergonomics
Here are a couple of the most important physical-, cognitive- and

ergonomic-related truths about the iPhone.
1. Our fingers are not mouse pointers.

Remember this property of our fingertips: their surface area is not equal to
one pixel. In many applications, tappable objects are way too small, making
the interface frustrating to use. Here’s one example: in iFitness, different
muscle groups are indicated with red pins. Tapping a pin brings up the
name of that muscle. And if you tap the name, you get a list of exercises that
develop that muscle.

The pins are twice as small as those used in the Google Maps app. Tapping
the pin you want is very hard, because the surface of your fingertip covers
an area of three or more pins. You end up tapping repeatedly on the area,
enabling random pins, wishing you could sharpen your finger. After more
than a few tries, you get lucky and hit the right one.
Which of these pins will be activated when you tap on it?
Here are some ways to solve these ergonomic challenges:
1. Make buttons and other tappable objects bigger.
2. If making a button bigger is impossible, then enlarge the clickable area

to be bigger then the button itself.
3. Reduce the number of options on each screen, and make the selection
process sequential (e.g. Arm Muscles → Biceps).

4. Implement multi-touch gestures within the interface. For example,
selecting a muscle group in iFitness would be made easier by
introducing a two-finger zoom feature.
2. We’re not superheroes, unfortunately.

App designers need to take vision limitations into account. Mobile phones
tend to be used in places with worse lighting conditions than computers.
Think about those people who will be using your app on a bumpy bus or
train or walking down a sunny street. Even if the technology is useful and
perfectly executed, people will be reluctant to use the app if they find it hard
to see what’s going on. Here are a few examples of potentially useful apps
that do not account for vision limitations.

TweetDeck

Fish-tycoon
Here are some ways to avoid these mistakes:
1. Choose only the elements that are absolutely necessary. Make them
bigger, and get rid of everything else. If needed, create additional
screens with fewer options.
2. Remember that pixel dimensions on the iPhone are smaller than those
on your computer screen. So, screenshots viewed on your computer’s
iPhone emulator look larger than they would on the iPhone itself, even
though the resolution is the same.
The author holds an iPhone (163 ppi) in front of Apple Cinema’s 30-inch
display (~100 ppi). Your iPhone screen layout may look fine on a computer
emulator, but don’t be fooled: it will appear much smaller on the iPhone
because of its smaller pixel dimensions.

Level 3: Understand "e Challenges Specific To "e
User’s Environment
Goals and environment
Your app will usually play a relatively small role in helping the user achieve a
bigger goal. The better you understand what goals people have and what
they need to achieve them, the better you can design your app to satisfy
those needs. Mobile phones are often used in loud, distracting
environments. A simple stroll through town brings plenty of noisy
distractions (cars, dogs, mail carriers, etc.). Consider the following examples.
Which voice memo app would do a better job?

Apple Voice Memos

iTalk

Although Apple Voice Memos looks nice, iTalk addresses the average
user’s goals and environment much better. Think about it: why would
someone prefer to record a voice memo over writing a note? The audio
format has fewer advantages than simple text. You can’t scan, edit or
enhance audio files as easily as you can text. In most scenarios, text is a
much more convenient format in which to exchange information.
So, why and, more importantly, when would people use voice memos?
When they are not able to type. The most common time is probably while
driving.
According to the New York Times‘ summary of the Virginia Tech

Transportation Institute‘s findings, drivers who text have a 23-times greater
risk of a collision than drivers who don’t text. Which application would be
easier to use in this case? The one with the big shiny mic and the record
button that is small and hard to reach (especially for right-handed people)?
Or the one with the red record button half the size of the screen? Certainly
the latter.
Confirming for the user that the recorder is activated is important, too. Which
interface communicates the device’s status more clearly? Where do you tap
when you’re done?

Apple Voice Memos

iTalk
Based on which design works better overall, iTalk wins. Apple Voice Memo
looks great when you’re checking it out on a friend’s phone but performs
poorly in a real-world context.

Mobile phones, networking and community
The mobile phone is, without a doubt, a social tool. The greater the number
of people involved, the more engaging the experience is. Think about it: if
you were the only one with a phone, it wouldn’t be very useful. YouTube,
Facebook and Twitter are driven by the understanding that we are social
beings – we want to share! Imagine how dramatically designs that foster
greater social interaction could change the mobile world.
With the seemingly endless ways to capture and share information, many
people feel overwhelmed with information. To help them cope, designers
must exploit the iPhone’s platform to make their applications as efficient as
possible. Here are some inspiring examples:

Bump
“Bump makes swapping contact information and photos as simple as

bumping two phones together. No typing, no searching a list for the right
person, no mistakes.” (iTunes Store description)

Mover
“Ever wished you could send something to the iPhone right next to you? Do
it with style with Mover.”

Level 4: "e Environment Is Part Of A Greater
Culture.
Your ability to address the unique needs of different cultures will affect the
success of your product. Ignoring them is too expensive, especially if your
app sells worldwide. Design should adapt to regional challenges. Jacob
Nielsen, a leading usability expert, gives us an illustration of this:
“In Sweden, the Automatic Teller Machines have very large buttons. I
hadn’t noticed this particular design element on previous visits, which
have usually been in warmer months. In 1996 I was in Stockholm in
February and immediately realized why the ATM buttons are so big: you
can press them wearing thick gloves.”
Such insights are gained only by understanding the product in its real-world
context. Here is the graphic designer’s point of view:
“… Understanding the object in context moves graphic design from a

purely formal arena to a social and political one.”
—Steven Heller and Karen Pomeroy in “Design Literacy,” Allworth Press,
New York, 1997.
More wisdom from Jacob Nielsen:
“A system must match the user’s cultural characteristics. This goes

beyond simply avoiding offensive icons; it must accommodate the way
business is conducted and the way people communicate in various
countries.”
Apple studied American users and addressed their goals. That’s why the
iPhone is so popular in US. But it hasn’t succeeded in Japan. The handset is
selling so poorly there that they are giving them away for free.

Conclusion: Excellence Comes From Hard Work
Designing a great app isn’t a simple task. Jacob Nielsen recently asserted
that “the mobile user experience is still miserable.” Extracting user insights
from testing is a challenge. People have difficulty telling you what they want;
they usually only know it when they see it. But developers don’t have to
tackle user research alone. Interaction designers are trained to find relevant
user groups, talk to customers and read between the lines. They understand
how real-world context affects an application’s design.
It takes a lot of leg work, but your efforts to understand user needs will be
rewarded. The forefront of mobile technology is an exciting place to be.

Useful Design Tips for Your iPad App
Jen Gordon
With tools like Appcelerator’s Titanium and some JavaScript programming

skill, creating native iPhone and iPad apps is simple. The danger is in not
being always on the look-out for the kind of design pitfalls that plague many
products in the App Store. In this article, we’ll consider some design tips that
will get you on the road to iPad success.
Design For People

Apps will define the iPad – it’s true. But, in developing your app idea, which
comes first, the idea or the device? Good news: neither. It’s people! When
brainstorming and researching ideas for your app, step back and consider
the context in which the device will be used by real live people. How does
the iPad fit into our lives? In what situations would we prefer this device to a
laptop or iPod Touch?
Who are your people?
Ideally, your target audience includes you, but using this as a reason to
decide that “I know what people like me want” could lead you to miss out
on opportunities to enrich the product beyond your imagination. Surprises
await when you consider the variety of people who might use your product.
Your target audience may be different than what you think; or, in defining
your target audience, you may find that your product is missing important
features.

For example, with our application (a drawing tool), our initial target audience
included early-adopter techies. But after some analysis, we saw that the
interface needed to be greatly simplified so that the children of the techies
would also enjoy the app.
Tip: Define your target audience. Who are they? Where do they live, work
and play? What challenges do they face? Give one of them a name, a job, a
family, a car; then see how your perspective changes.
What is your people’s story?
Defining a target audience is only half of the equation. Now you have to put
your audience into action! What do they do in their daily life? How will their
daily life intersect with your product? Get into their minds. Try this, and I
guarantee it will lead you down some expected and unexpected paths.
You don’t need fancy software to do this. Below is an example of our use
case sketches for our application. After writing out a few use cases, we
learned that people lose interest in drawing games when they’re forced to
create original artwork. Many people will say, “I can’t draw,” but they still
have a desire to create beautiful things. Originally, we planned for our app
to ship with patterns, similar to the classic Lite-Brite toy, but it didn’t occur to
us that people would play with the app more if we provided pre-fab patterns
and templates for them to color. Pretty important feedback!

In developing the idea for an app, our use cases revealed that the replay value
of such an app is low unless you provide patterns for the user to get started.
Tip: Think about the device in terms of lifestyle rather than features and
technology. Will the iPad’s unique characteristics and environmental and
sociological factors make your idea resonate with people?

• It’s lightweight = “I’ll carry it more places than I would a laptop.”
• It’s smaller than a laptop = “It’s discreet. Would I crack open my laptop
to do some work in a waiting room? No. Would I switch on my iPad?
Yes.”
• It has robust utilities and multimedia capabilities = “I can work and enjoy
books, movies and games.”
• Its screen is larger than the iPhone’s = “I can consume more media with
less eye strain. My kids will be entertained on a road trip.”
• It has Wi-Fi and 3G Internet connectivity = “I can be online on a plane,

train or car.”
Designing for people is critical to weeding out weak (i.e. unprofitable,

untargetable or unmarketable) ideas quickly and to developing a product
that not only meets but anticipates the target audience’s needs.
Minimalism Works Best on iPad

With robust, portable, location-aware devices like the iPad, the temptation is
to throw in everything and the kitchen sink. If you’re an iPhone developer,
you’re probably excited about the additional screen real estate. Resist the
temptation to fill the space! Keep it simple. Display only the content and
controls that are relevant to the user at that moment. This requires you to
use the following two things in your interface design.
Contextual menus
Contextual menus are a great way to keep your UI out of the way. We
wanted to keep sharing and community features out of the primary
navigation. We used a contextual menu (“Share this thang!”) to present
actionable items at the appropriate time.

Example of a contextual sharing dialog, activated when you tap and hold on an
image.

Modal views (but wisely)
With the increased real estate on the iPad, one can build in robust
functionality that is impossible on an iPhone or iPod Touch screen. Modal
views give you another way to organize your application; they give the user
clear “modes” of operation; and they can be an elegant solution to UI clutter
if executed wisely.
For example, “photos” on the iPad could operate similar to iPhoto on the
desktop Mac. You have two “modes” of operation:
1. View or edit an individual photo,
2. Manage groups of photos.
In each scenario, packing the viewing, editing and managing functions into
one view wouldn’t make sense. Think of how you could segment features in
your app, while maintaining a smooth connection between the two modes.
iPhoto has two modes of operation: viewing and editing a photo or managing
photos.

Tip: What is the bare minimum your app could provide and still be useful to
users?
iPad’s Two Orientation Are a Big Deal

Being able to switch views—landscape to portrait and back again—is not
unique to the iPad, but it’s a bigger deal on it. This is where paper
prototyping will save you from wasting loads of time in Photoshop.
Having to consider every element of your app in these two sometimes

radically different layouts is like designing for two devices… except that
you’re not designing for two devices. The trick is to keep the experience
consistent in each view, allowing for a seamless user experience when
switching views.
Below is a color palette we tested for our app. The palette looks great in
landscape mode but absolutely hogs the screen in portrait mode. Oops.

This palette looks okay in landscape mode but gobbles up the interface in
portrait.

We reconfigured the color palette to have a smaller footprint in both
landscape and portrait modes:

A streamlined color palette allows accessibility while staying out of the way in
both landscape and portrait views.

Tip: Paper prototype all of your screens in portrait and landscape modes… a
lot.
Use Touch and Real-World Metaphors

Touch changes how we interact with, edit and perceive on-screen elements.
With the iPad’s larger screen, touch and gestures are turbo-charged. A quick
run-down of unique UI elements on the iPad:
• Select and take action on multiple items at once by dragging them to

another area of the screen.
• See both a list view and details of items in that list view (e.g. Mail).
• Edit elements in place rather than from a global menu bar.
Spread your fingers over a stack of photos to spread them out for viewing, as
you might in the real world.
Tip: Think of how you interact with things in the real world. Think of the on-
screen elements as tangible things.

Design for Dynamic Content
The iPad’s portability and bigger screen size gives users unlimited
possibilities for quickly creating and sharing robust dynamic content on the
go. Hybrid apps (i.e. native apps that draw from Web pages or that load real-
time Web content) are becoming more common as users demand
connectivity to Web-based tools. Designing for dynamic content means
working through the challenges and opportunities of dealing with an
Internet connection (e.g. slow downloads or lost connection). Think of what
visuals you would present to users when they’re stuck in East Bum with no
connection to be found!
Tip: Plan for problematic situations in your design.
Get started!
The first step to getting started is downloading the iPad SDK. For Web
developers looking to get into iPad development with their current skills,
products such as Appcelerator’s Titanium offer a good way to build native
iPad, iPhone and Android apps in JavaScript.

Make it a Mobile Web App
Kim Pimmel
Ask any interactive agency what their clients are asking for when they need
a mobile experience – the answer will inevitably be ‘an iPhone and/or iPad
app.’ Native Apple apps are a hot commodity, and, in today’s mobile
application ecosystem, mobile web apps are not sexy – in fact many people
don’t even realize they are even an option. In certain cases, an iPhone/iPad
app will be the right solution for their needs. However, there are many other
situations where it may a short-term win but a long-term loss. Mobile web
apps offer a number of advantages over native apps, and, though they face
some design, development and deployment challenges, they are a powerful
cross-platform, scalable and affordable solution.
Increasing Fragmentation
Mobile apps are all the rage. There are a slew of startups targeting the iPad,
countless entrepreneurs hacking together the next killer iPhone app, and it
seems as though every big company has released an app of some sort. With
the increasing penetration of Android phones, developers are scrambling to
port their software. But what about deploying to Windows Phone 7,
Blackberry and Symbian? Who wants to study yet another SDK, learn
another language, and go through yet another app submission process?
Who will continue to keep the code up to date for all these platforms as
each one splinters into new incarnations, releases new hardware and OS
updates. Fragmentation is a costly long-term investment, and people are
beginning to realize that native apps are not a sustainable long-term
solution for all their needs.

The Mobile Web is Everywhere
As the native mobile app market becomes increasingly fragmented, it is

becoming clear that there needs to be a solution which can reuse code and
designs across platforms and which eases deployment headaches. But why
invent a new solution when it already exists on every device out there – the
web. Webkit is gaining ground as the de facto standard for rendering web
content, but even Webkit isn’t appropriate for every application. It wouldn’t
be recommended for experiences that need complex graphics rendering,
require hooks into specific hardware, such as a camera or an accelerometer,
or have hefty media requirements. Although these constraints will change
over time. But for all other apps that don’t need these features, using the

mobile web frees developers to use their web technology of choice, so long
as it will render on mobile browsers. Design and develop once, deploy
everywhere. With smart design and code, a single web app could render
appropriately on differing resolutions and screen sizes, and respond
accordingly to touch, 5 way or a cursor. Indeed, frameworks for mobile web
app development already exist, such as the Sencha Touch.
This Is Nothing New …
Desktop web apps are far from a new idea – rich internet apps have been
around for a while. Google has been pushing in this direction for years,
creating a broad suite of online tools, primarily for the desktop, with an
increasing focus on mobile. However, web apps have been slow to gain
traction in the mobile space. Even with Apple promoting mobile web apps
as the next best thing on their 1st generation iPhone in 2007, the focus is
still squarely on native apps. And the primary reason for this is due to the
overwhelming success of Apple’s (native) App Store.
The App Store Model
Apple’s App Store was not the first to distribute native applications to mobile
phones, but they proved it was a viable model and launched the concept
into popular culture. It’s this same model that would be necessary to make a
mobile web app ecosystem successful. Indeed, at the Google IO
conference, Google announced their development of a Chrome Web Store.
And, while their focus was primarily on desktop web apps, their
announcement touched on many of the key points of why app stores are
important and how to build for success.

As a consumer, it’s more appealing to go to one trusted online outlet, rather
than to waste time searching the web for the same thing and putting
yourself at risk of being hacked. Mobile web apps need a consolidated
storefront for much the same reasons. First, it’s easy to find apps when they
are indexed, categorized and searchable in one place. Second, a robust
community of users exposing app popularity, contributing ratings and
writing reviews makes it easier to evaluate your choices. Third, when I’ve
decided to buy a game such as Plants and Zombies, I want to be sure my
purchase will be a safe one – something a robust app store from a
recognized company should offer. And, since a web app is cross-platform,
you could play it on your Android phone, your iPad, and your desktop, all
with a single purchase. Buy once, use anywhere. It’s magic!

As a business or developer creating web apps, a centralized web app store
provides benefits over doing it solo. Most importantly, it provides a source of
monetization. This is key to driving adoption of a web app ecosystem, as
without revenue, businesses and developers will stick with money-making
native apps. It’s also a marketing channel, allowing for easy discovery and
promotion. Another potential benefit of using a web app storefront would be
the APIs to help developers deal with authentication, licensing and other
technical hurdles of digital distribution.
It’s Possible Now
A great majority of native apps could be deployed today as full featured

mobile web apps. The HTML5 family of technologies allow for refined
typography, animation, streaming video, offline storage… the list goes on.
Probably the most high profile web app to date is the Youtube mobile site,
which delivers a comparable experience to the native apps they have built.

Real World Challenges
As with any innovation, there are big questions that need to be answered.
The most obvious is the issue of cross-platform compatibility. Building a

robust and rich cross-platform mobile web app experience would benefit
from HTML5 technology support, but currently RIM and Microsoft’s mobile
offerings use their own standards. This weakens the des/dev once, deploy
anywhere story – but is by no means a deal breaker. Web developers have
long dealt with coding to accommodate troublesome browsers, and this
would be a similar case.

Another challenge in the deploy anywhere scenario arises when you look at
how a given design translates across devices with varying resolutions, form
factors and input methods. Application designers will need to approach this
problem by targeting several key resolution/form factor combinations,
similar to what is recommended by the Android SDK. Depending on what
device an app is being run on, the design, layout and functionality may differ
significantly. This can be solved using a combination of intelligent design
and careful development.
Lastly is the problem of providing consistent, quality user experiences in this

new application space. We’ve seen how the Android’s app offerings often
leave much to be desired in terms of visual design and usability while Apple
has been more successful in defining quality experiences. Providing a set of
best practices, design patterns, and components for designers would go a
long way towards the creation of quality mobile web app experiences that
would win over consumers. As mobile web apps gain credibility, we will see
more offerings, such as Sencha Touch and Sproutcore, that provide solid
web development and experience frameworks.
The Inevitable Victory of the Web Browser
Web applications as ‘the next big idea’ might never happen, but, in the
coming years, more and more websites will have mobile incarnations that
look a lot like applications. You’ll be swiping through articles, pinching
photos, and flicking pests off your Farmville plot – all in your mobile
browser. And people won’t even realize that in the end – the next
generation mobile web won.

How to Use CSS3 Media Queries to Create
a Mobile Website
Rachel Andrew
CSS3 continues to both excite and frustrate web designers and developers.
We are excited about the possibilities that CSS3 brings, and the problems it
will solve, but also frustrated by the lack of support in Internet Explorer 8.
This article will demonstrate a technique that uses part of CSS3 that is also
unsupported by Internet Explorer 8. However, it doesn’t matter as one of the
most useful places for this module is somewhere that does have a lot of
support — small devices such as the iPhone and Android devices.
In this article I’ll explain how, with a few CSS rules, you can create an iPhone
version of your site using CSS3, that will work now. We’ll have a look at a
very simple example and I’ll also discuss the process of adding a small
screen device stylesheet to my own site to show how easily we can add
stylesheets for mobile devices to existing websites.
Media Queries
If you have ever created a print stylesheet for a website then you will be
familiar with the idea of creating a specific stylesheet to come into play
under certain conditions – in the case of a print stylesheet when the page is
printed. This functionality was enabled in CSS2 by media types. Media
Types let you specify a type of media to target, so you could target print,
handheld and so on. Unfortunately, these media types never gained a lot of
support by devices and, other than the print media type, you will rarely see
them in use.

The Media Queries in CSS3 take this idea and extend it. Rather than looking
for a type of device they look at the capability of the device, and you can
use them to check for all kinds of things. For example:
• width and height (of the browser window)

• device width and height
• orientation – for example is a phone in landscape or portrait mode?
• resolution
If the user has a browser that supports media queries then we can write CSS
specifically for certain situations. For example, detecting that the user has a
small device like a smart phone of some description and giving them a
specific layout. To see an example of this in practice, the UK web
conference dConstruct has just launched their website for the 2010
conference and this uses media queries to great effect.

The dConstruct 2010 website in Safari on a desktop computer

The dConstruct 2010 website on an iPhone
You can see from the above example that the site hasn’t just been made
smaller to fit, but that the content has actually been re-architected to be
made more easy to access on the small screen of the device. In addition
many people might think of this as being an iPhone layout – but it isn’t. It
displays in the same way on Opera Mini on my Android based phone – so

by using media queries and targeting the device capabilities the dConstruct
site caters for all sorts of devices – even ones they might not have thought
of!
Using Media Queries to create a stylesheet for phones

To get started we can take a look at a very simple example. The below
layout is a very simple two column layout.
A very simple two column layout

To make it easier to read on a phone, I have decided to linearize the entire
design making it all one column, and also to make the header area much
smaller so readers don’t need to scroll past the header before getting to any
content.
The first way to use media queries is to have the alternate section of CSS
right inside your single stylesheet. So to target small devices we can use the
following syntax:
@media only screen and (max-device-width: 480px) {

}
We can then add our alternate CSS for small screen and width devices
inside the curly braces. By using the cascade we can simply overwrite any
styles rules we set for desktop browsers earlier in our CSS. As long as this
section comes last in your CSS it will overwrite the previous rules. So, to
linearize our layout and use a smaller header graphic, I can add the
following:
@media only screen and (max-device-width: 480px) {

! div#wrapper { width: 400px; }
! div#header {
! ! background-image: url(media-queries-phone.jpg);
! ! height: 93px; position: relative;
! }
! div#header h1 { font-size: 140%; }
! #content { float: none; width: 100%; }
! #navigation { float:none; width: auto; }
}
In the code above, I am using an alternate background image and reducing

the height of the header, then setting the content and navigation to float
none and overwriting the width set earlier in the stylesheet. These rules only
come into play on a small screen device.

My simple example as displayed on an iPhone

Linking a separate stylesheet using media queries
Adding the specific code for devices inline might be a good way to use
media queries if you only need to make a few changes. However, if your
stylesheet contains a lot of overwriting or you want to completely separate
the styles shown to desktop browsers and those used for small screen
devices, then linking in a different stylesheet will enable you to keep the
CSS separate.
To add a separate stylesheet after your main stylesheet and use the
cascade to overwrite the rules, use the following.
<link rel="stylesheet" type="text/css" media="only screen and

(max-device-width: 480px)" href="small-device.css" />
Testing media queries

If you are the owner of an iPhone, Android device or other device that has a
browser which supports media queries you can test your CSS yourself.
However you will need to upload the code somewhere in order to view it.
What about testing devices you don’t own and testing locally?
An excellent site that can help you during the development process is
ProtoFluid This application gives you a form to enter your URL – which can
be a local URL – and view the design as if in the browser on an iPhone, iPad
or a range of other devices. The screenshot below is the dConstruct site we
looked at earlier as seen through the iPhone view on ProtoFluid.

The dConstruct 2010 website in ProtoFluid
You can also enter in your own window size if you have a specific device
you want to test for and know the dimensions of it’s screen.
To use ProtoFluid, you need to slightly modify the media query shown
earlier to include max-width as well as max-device-width. This means that
the media query also comes into play if the user has a normal desktop
browser but is using a very tiny window.
@media only screen and (max-width: 480px), only screen and

(max-device-width: 480px) {
}
After updating your code to the above, just refresh your page in the browser
and then drag the window in and you should see the layout change as it hits

480 pixels. The media queries are now reacting when the viewport width
hits the value you entered.
You are now all ready to test using ProtoFluid. The real beauty of ProtoFluid
is that you can still use tools such as FireBug to tweak your design,
something you won’t have once on the iPhone. Obviously, you should still
try and get a look at your layout in as many devices as possible, but
ProtoFluid makes development and testing much simpler.
Note that if you don’t want your site to switch layout when someone drags
their window narrow you can always remove the max-width part of the query
before going live, so the effect only happens for people with a small device
and not just a small browser window.
Retrofi#ing an existing site

I have kept the example above very simple in order to demonstrate the
technique. However, this technique could very easily be used to retrofit an
existing site with a version for small screen devices. One of the big selling
points of using CSS for layout was this ability to provide alternate versions of
our design. As an experiment, I decided to take my own business website
and apply these techniques to the layout.

The desktop layout
The website for my business currently has a multi-column layout. The

homepage is a little different but in general we have a fixed width 3 column
layout. This design is a couple of years old so we didn’t consider media
queries when building it.
My site in a desktop browser

Adding the new stylesheet
There will be a number of changes that I need to make to linearize this

layout, so I’m going to add a separate stylesheet using media queries to
load this stylesheet after the current stylesheet and only if the max-width is
less than 480 pixels.
<link rel="stylesheet" type="text/css" media="only screen and

(max-width: 480px), only screen and (max-device-width: 480px)"
href="/assets/css/small-device.css" />
To create my new stylesheet, I take the default stylesheet for the site and
save it as small-device.css. So this starts life as a copy of my main
stylesheet. What I am going to do is go through and overwrite certain rules
and then delete anything I don’t need.
Shrinking the header
The first thing I want to do is make the logo fit nicely on screen for small
devices. As the logo is a background image this is easy to do as I can load a
different logo in this stylesheet. I also have a different background image
with a shorter top area over which the logo sits.
body {
! background-image: url(/img/small-bg.png);
}
#wrapper {
! width: auto;
! margin: auto;
! text-align: left;
! background-image: url(/img/small-logo.png);
! background-position: left 5px;
! background-repeat: no-repeat;
! min-height: 400px;
}

Linearizing the layout
The next main job is to linearize the layout and make it all one column. The
desktop layout is created using floats so all I need to do is find the rules that
float the columns, set them to float: none and width:auto. This drops all the
columns one under another.
.article #aside {
! float: none;
! width: auto;
}
Tidying up
Everything after this point is really just a case of looking at the layout in
ProtoFluid and tweaking it to give sensible amounts of margin and padding
to areas that now are stacked rather than in columns. Being able to use
Firebug in ProtoFluid makes this job much easier as my workflow mainly
involves playing around using Firebug until I am happy with the effect and
then copying that CSS into the stylesheet.

Testing in an iPhone
Having created my stylesheet and uploading it I wanted to check how it

worked in a real target device. In the iPhone, I discovered that the site still
loaded zoomed out rather than zooming in on my nice readable single
column. A quick search on the Safari developer website gave me my answer
– to add a meta tag to the head of the website setting the width of the
viewport to the device width.
<meta name="viewport" content="width=device-width" />
After adding the meta tag the site now displays zoomed in one the single
column.

The site as it now displays on an iPhone
This was a very simple retrofit to show that it is possible to add a mobile
version of your site simply. If I was building a site from scratch that I would
be using media queries on, there are definitely certain choices I would make
to make the process simpler. For example, considering the linearized
column orders, using background images where possible, as these can be

switched using CSS, or perhaps using fluid images. Our desktop layout
features a case studies carousel on the homepage, this wasn’t easy to
interact with on a touch screen device and so I checked using JavaScript if
the browser window was very narrow and didn’t launch the carousel. The
way this was already written meant that the effect of stopping the carousel
loading was that one case study would appear on the screen, which seems
a reasonable solution for people on a small device. With a bit more time I
could rewrite that carousel with an alternate version for users of mobile
devices, perhaps with interactions more suitable to a touch screen.
Providing support for Media Queries in older

browsers
This article covers the use of media queries in devices that have native
support. If you are only interested in supporting iPhone and commonly used
mobile browsers such as Opera Mini you have the luxury of not needing to
worry about non-supporting browsers. If you want to start using media
queries in desktop browsers then you might be interested to discover that
there are a couple of techniques available which use JavaScript to add
support to browsers such as Internet Explorer 8 (and lower versions) and
Firefox prior to 3.5. Internet Explorer 9 will have support for CSS3 Media
Queries.
Try it for yourself

Using Media Queries is one place you can really start to use CSS3 in your
daily work. It is worth remembering that the browsers that support media
queries also support lots of other CSS3 properties so your stylesheets that
target these devices can also use other CSS3 to create a slick effect when
viewed on an iPhone or other mobile device.

Forms on Mobile Devices
Luke Wroblewski
Mobile forms tend to have significantly more constraints than their desktop
cousins: screens are smaller; connections are slower; text entry is trickier;
the list goes on. So, limiting the number of forms in your mobile applications
and websites is generally a good idea. When you do want input from users
on mobile devices, radio buttons, checkboxes, select menus and lists tend
to work much better than open text fields.
But constraints breed innovation, and mobile forms are no different. The
limitations of mobile devices have forced developers and designers to find
new ways to allow users to input data faster and more easily. Thanks to the
modern solutions covered in this article, the mobile space may not be a
place to avoid forms much longer. Instead, it may become the place to
encourage them.
Field Zoom
In many mobile Web browsers, when a user selects a form’s input field, the
“field zoom” feature expands it to fill the screen’s viewable area. This makes
an otherwise tiny field large enough for people to actually see the data they
are entering. Given that many form errors are caused by people not seeing
their inputs well enough to correct misspellings, the usability of this feature
is clear.
The Safari browser on Apple’s iPhone makes use of field zoom together
with a “form assistant.” The form assistant displays “Previous,” “Next,”
“AutoFill” and “Done” buttons below the magnified input field, giving people

an easy way to move through and complete a form. No need to worry if an
input field is off screen: the user just hits “Next” and won’t miss it!
However, not everyone will know about the form assistant or know how to
hide the keyboard. So, make sure the controls on the Web page still allow
them to complete the form. Excessive spacing around the “Submit” button
can tuck it behind the keyboard.
Field zoom is another great reason to top-align input field labels in forms. As
you can see on Google’s registration form (screenshot below), left-aligned
labels disappear when input fields are expanded to fill the screen. With no
visible label, the user can easily forget what question they have to answer.
Long input fields also suffer a bit with field zoom.

Mobile browsers that don’t have field zoom also run into issues with left-
and right-aligned input field labels. Anyone using such a form on Google’s
Android OS (below) faces the problem of disappearing labels. The screen
simply does not have enough room for both the input field and its
corresponding label. Top-aligned labels avoid this issue.

Input Formats
Some mobile Web browsers recognize specific input types (part of the
developing HTML5 standard) and adjust their input modes accordingly. For
example, specifying an input of the type url brings up a virtual alphanumeric
keyboard with “.”, “/”, and “.com” keys. Specifying an input of the type email
brings up a virtual alphanumeric keyboard with “.” and “@” keys. Specifying
an input of the type number brings up a virtual numeric keyboard.
These input-specific keyboards make entering the particular type of data

required by each input field much easier. Even browsers without virtual
keyboards benefit from the use of number, because users would not have
to switch to number mode to enter numeric data.

Password-Masking
Most password input fields in forms instantly obscure all characters that a
user enters to keep sensitive information hidden from prying eyes.
Automatic masking of passwords may provide the appearance of security,
but it can also create usability issues when people are left staring at a row of
bullets that they hope (but can’t verify) is their password.
Many mobile devices address this issue by displaying the most recent
character the user has entered, and then obscuring that character as a
bullet only after a brief delay.
Pop-Up Menu Controls

Drop-down select menus are one of the hardest input types to use. First,
you have to click on the menu to open it. Then, you have to maneuver
through a potentially long list of small targets. Once you find the value you
want, you need position your cursor on the right target and select it. To top
it off, many implementations of drop-down menus on the Web require you to
keep your cursor on the menu while navigating the list, or else the menu
closes!
Even dexterous users often miss them and need to start over. Couple this
interactive challenge with the small screens of mobile devices and the need
for a different solution for select menus becomes quite obvious.
For drop-down select menus on Web forms, Apple’s iPhone presents users
with a pop-up menu control. This control displays the options in the menu in
a contained list that can be scrolled at various speeds though drag, nudge
and flick gestures. The large touch targets also make it easy to select the
right value once you’ve found it.

Similarly, Google’s Android provides a larger touch target for select menu
options. When the user taps a drop-down select menu on an Android
device, a scrollable list of menu options appears in a dialog window over the
Web page.

Compound Menu Controls
Pop-up menu controls can be applied to compound inputs as well. So,
instead of requiring three separate input fields for the month, day and year
of a requested date, one date field can bring up a set of pop-up menus that
allow people to scroll through three lists at once to find the right date. This
approach can be applied to other kinds of compound inputs as well, such as
height in feet and inches.

Google’s Android has a compound input field solution, though it makes use
of visible interface elements to move through a list instead of relying on
gesture-based scrolling alone.

Native Input Controls
In addition to having compound menu controls, most mobile operating
systems have several other custom input controls available to application
developers. Sliders, split buttons, rating widgets and scrubbers are just a
few of the components worth considering in place of standard form controls
to make inputting easier for users.

Orientation
Because people like to hold mobile devices both horizontally and vertically
in their hands, mobile forms should adjust accordingly to take advantage of
the changing screen space. The compose email form on Google’s Android
does just that.

When held vertically, the screen shows three input fields with several action
buttons. In the horizontal position, the email body input takes over the
screen, and one action button is shown on the right. This layout maximizes
the screen space available for the message content.
Voice Input
Google’s Nexus One phone allows people to use voice input for any text
field in an application. Users can swipe the virtual keyboard to switch the
phone to audio input mode, or they can use the microphone button. The
video below demonstrates both of these options in action. With effective
voice input, typing any characters into the mobile device becomes a thing of
the past.

What’s Next?
Mobile is growing exceptionally fast, and, as more designers and
developers focus on the space, we’ll hopefully see even further innovation
in mobile forms. After all, anything that makes inputting (both on mobile and
desktop devices) faster and easier will do a lot of good for both companies
and their customers.

Se#ing up Photoshop for Web and iPhone
Development
Marc Edwards
Most people who have designed websites or apps in Photoshop will, at one
point or another, have had issues trying to match colors in images to colors
generated by HTML, CSS or code. This article aims to solve those problems
once and for all.
Color Management to Match Colors Across Multiple

Devices
In the print world, color management typically involves calibrating your
entire workflow, from scanner or digital camera to computer display to hard
proofs to the final press output. This can be quite a tall order, especially
when the devices use different color spaces – matching RGB and CMYK
devices is notoriously hard.
When designing or editing for TV, calibrating the main editing display and
using a broadcast monitor are common; these show real-time proof of how
the image will look on a typical TV in a viewer’s home. In such a scenario,
color management offers many benefits and is highly recommended.
When building Web and application interfaces, the situation is a little

different. The final output is the same device that you’re using to create the
artwork: a computer display (putting aside for now differences in gamma
between Windows, Mac OS X prior to 10.6 and the iPhone, which we’ll cover
later.)

There is a catch, though. Even though you’re creating the Web or app
interface on the same device that the final product will be shown on, the
colors will have various sources: images (typically PNG, GIF and JPEG), style
markup (CSS) and code (JavaScript, HTML, Objective-C, etc). Getting them
all to match can be tricky.
The goal
When designing websites or app interfaces, we want to perfectly match the

colors that are displayed on screen in Photoshop and that are saved in files
with what’s displayed in other applications, including Firefox, Safari and the
iPhone Simulator. Not only do we want the colors to look the same, but we
want the actual values saved in the files to perfectly match the colors we
have defined in Photoshop. Colors should not shift or appear to shift in any
way, under any circumstance.
Why is this so difficult?
Photoshop applies its color management to images displayed within its

windows and to the files it saves. This is a bad thing if you’re working
exclusively with RGB images for Web or on-screen user interfaces. With the
default Photoshop settings, #FF0000 will actually display as #FB0018, and

#BB95FF will display as #BA98FD. The differences are subtle but definitely
there.
How Does Photoshop Differ from OS X and Windows?

OS X’s color management is applied to the entire display at the very end of
the processing chain, after the main buffer in video ram. This means that
although color management is applied, the software utilities that measure
color on screen (like /Utilities/DigitalColor Meter) will report the same values
that you have saved in the file or entered as your code. I believe the color
management in Windows Vista and Windows 7 (Windows Color System)
works in a similar fashion.
Photoshop’s color management is applied only to the image portion of its

windows and to the files it saves. This color correction happens as
Photoshop draws the image on screen, so software utilities that measure
color on screen often report different colors from the ones you have
specified. It’s worth noting that OS X’s color management is applied on top
of Photoshop’s.
The best solution I’ve found is to disable Photoshop’s color management for
RGB documents as much as possible. Doing so forces the RGB colors that
are on screen and saved to the file to match the actual color value. If you
need to calibrate your monitor for Web and app design work, then you
would best be served by changing it at the OS level.
Disabling color management used to be quite easy in Photoshop CS2 and

all versions prior, but it now requires a little more skill.

Disabling Photoshop’s RGB Color Management
These instructions are for Photoshop CS5 on Mac and Windows. Setting up
CS4 is very similar.
Step 1: Go to Edit → Color Settings and set the working space for RGB to
Monitor RGB.
Step 2: Open a document and go to Edit → Assign Profile, then set it to

Working RGB. This must be done for every single document you work on.
Step 3: Ensure View → Proof Colors is turned off.
Step 4: When saving files with Save for Web & Devices, ensure that Convert
to sRGB is turned off. If you’re saving a JPEG file, then also turn off Embed
Color Profile (you may want this turned on for certain photos, but chances
are you’ll want it off for interface elements and icons).
Difference Between “Assign Profile” and “Convert To

Profile”
Now would be a good time to mention the difference between Assign
Profile and Convert to Profile, so that you know which to use when.
Each Photoshop document contains a color profile that’s separate from the
actual color data stored for each pixel. Assign Profile simply changes the
profile in the document, without affecting any of the color data. It’s a non-
destructive action: you can assign a new color profile to your documents as
often as you like without doing any damage. Assigning a new profile may
change the way your document appears on screen, but the data contained
in the file will remain unaltered.
Convert to Profile is quite different. Not only does it assign a color profile to
the document, but it tries to keep your image looking the same on screen. It

does this by processing the color data contained in the file for each pixel.
Converting to a new profile will more likely preserve a document’s color on
screen, but the data contained in the file will be permanently altered. Use
with caution.
If you’re copying layers from one Photoshop document to another, you will
want to ensure that the documents have been assigned the same color
profile.
Illustrator is the Same as Photoshop

If you would like images saved in Illustrator or imported from Illustrator to
Photoshop to match as well, then follow the steps below. These instructions
are for Illustrator CS5 on Mac and Windows. Setting up Illustrator CS4 is very
similar.
Step 1: Go to Edit → Color Settings, and set the working space for RGB to
Monitor RGB.
Step 2: Open the document and go to Edit → Assign Profile. Then set it to
Working RGB. This must be done for every single document you work on.
Step 3: Ensure that View → Proof Colors is turned off.
Step 4: When saving files with Save for Web & Devices, ensure that Convert
to sRGB is turned off. If you’re saving a JPEG file, then also turn off Embed
Color Profile (again, you may want this turned on for certain photos, but
chances are you’ll want it off for interface elements and icons).

Gamma Differences
Windows has used a gamma of 2.2 since its introduction. Mac OS X has
used a gamma of 1.8 for all versions except Snow Leopard (the latest
release), which uses 2.2. What does this mean? Prior to Snow Leopard, Web
pages looked darker on Windows. Thankfully, both operating systems are
now in sync, so a Web page should look very similar on a Mac and PC that
use the same monitor.

Final Check for iPhone UI
Your iPhone or iPod’s screen and calibration will likely be different from your
Mac or PC’s screen and calibration. I often import full-screen images of the
UI into iPhoto and sync them with an iPhone to see exactly how the final
interface will look on the device (on Windows, you can sync photos using
iTunes). This gives you another chance to make adjustments before slicing
up images or committing anything to code.
This article explains how to handle the problem that while testing some
landscape iPhone app interface mocks, they seem blurrier than they appear
in Photoshop.
Please note: For some bizarre reason, the Photos app on the iPhone doesn’t
display landscape images at 1:1. Instead, it scales them slightly or shifts them
to a sub-pixel position, making the images blurrier than they should be. To
avoid any issues, always save images in portrait mode (320 pixels wide by
480 pixels high) to test your user interface mockups.
Conclusion
Now, you’re able to move bitmap and vector images between Photoshop
and Illustrator without any color shifts at all, and using any method. You’re
also able to grab a color using the color picker in Photoshop, and then use
the same HEX color value in your CSS, HTML, JavaScript, Flash or
Objective-C code, and it will match your images perfectly.

How to Market Your Mobile Application
Michael Flarup
App Store is a competitive environment. Against more than 140,000 apps,

all screaming for attention, how do you make sure your app gets its time in
the spotlight? What does it take to get good media coverage? How do you
get people to talk about your app – and, ideally, how do you get them to
buy it and show it to their friends?
Following the simple rules laid out below, you will increase your chances in
the battle for fame and glory. These tips might seem rudimentary or in-your-
face obvious, but they are so often neglected in the heat of the moment.
Be Unique
One of the easiest ways to stand out in the App Store is to create an app
that is unique. Sure, that makes sense. Yet still thousands and thousands of
apps are uninspired, shoveled out by tired developers looking for a quick
buck.
If you want to stick it to the man, make sure that you are either:
1. The first developer in your category of product, or
2. Reinventing the existing category with something unique.
If you’re just improving something that’s already available, your battle to

market it will be uphill.

Spin an existing category
At this point in the history of the App Store, very few apps create new
categories. So unless you’re sitting on a revolutionary new idea, focus your
attention on a unique spin of an existing category. So many things can be
re-imagined with little effort. Look at your competitors and flick on your
child-like consumer filter. What cool feature for this category is missing?
How can you take advantage of the iPhone’s interface, accelerometer, GPS
or multi-touch functionality to create a package that delivers a unique
experience in this category?
A unique feature will make your app stand a head taller in the crowd and
raise eyebrows. And that’s exactly the effect you want if you intend to sell
apps in the App Store.
• Think, plan and build with the intention of creating something unique.
From the conceptual drafts to the final marketing, keep iterating the
unique aspects of your product.
• Ask yourself if you are merely improving on someone else’s idea. If it

already exists in the App store, the battle to market it will be uphill.
• Try some shortcuts to create something unique, such as mixing
categories; thinking of new ways to use the accelerometer, GPS,
proximity sensor and multi-touch gestures; storytelling; etc.
• If you’re competing in a saturated market, do the exact opposite of the

leader.

Be Tweetable
Getting people to talk about your app is imperative for success. The more
people talk, the more exposure your app will get, which will hopefully
translate into sales. If your app is unique, you’re halfway there—people will
talk about it just because of its uniqueness. But how do you encourage
people to start up conversations about your product?
Learn to pitch
I’m sure you’ve pitched your app to at least a dozen co-workers and puzzled
family members. You know the ins and outs of your elevator speech, the
highs and lows, the big sells of your product and the hard-to-understand
parts. If you want your app to succeed, you will need to teach that pitch to
the rest of the world.
Be interesting
Make the conversation about your app easy and engaging. Make it so that
people want to tweet about it. Tweetability—if no one has yet, I’m
trademarking that word—refers to how well a product or message would
move on Twitter. The Twitter network, with its millions of users, has a
particular personality and disposition. Despite the diversity of people using
the service, talking about it like a homogenous mass still makes sense in
many ways. Some of the most successful apps are easily shared through
social media. Imagine the twittersphere chattering in chipmunk voices, “Hey,
guys. Check this out!” Instantly gratifying app + high tweetability = free
exposure.
Even if your app isn’t instantly gratifying or playfully humorous, you can still
compose a tweet that is highly tweetable. Just think of what you would
retweet yourself. How would you sell your app in 140 characters?

• Play to your strengths. Write good copy. And have a solid, useful and
attractive landing page.
• Find the human angle. Are there any amusing and beneficial reasons
why people would use your app?
• Have a memorable tagline. Sum up your app’s purpose in one line.
Cater To Blogs
Social media and the blogosphere are not isolated from each other. Like
ripples in a pond, the more people tweet about your app, the more likely
you’ll hit a big blog.
Review blogs and tech websites are part of the App Store’s eco-system, and
while the exact effect they have on sales is debatable, the traffic and buzz
they generate are worth pursuing.
Think like media
To get good media coverage, you need to think like the media. How good a
story is your app? Obviously, the law of uniqueness makes a difference
here, but your app should also be easy to write about. First, provide a free
press package that anyone can download. Supply people with the material
they need to talk about your app. Give them a high-res version of the icon,
screenshots and press-related texts.
Don’t be stingy with the promo keys either—in fact, dispense them liberally.
Promo keys are cheap marketing collateral and a way for you to put your
app in the hands of peer leaders. Throw the keys at your favorite blog, and
invite them to give some away for free in a raffle. If you can find a category-
specific blog, you’ve got a direct line to your target customers. It’s a great
way to reach a new audience and strengthen your relationships and
reputation.

Blogs are like kids in a schoolyard
While they may not want to hear this, blogs are a bit like kids in a
schoolyard. If you can get the cool kids to talk about you, chances are that
other blogs will pick up the story and throw you on their front page. Getting
on review and media websites is vital to your marketing success, because
they are less transient than tweets. Reviews stay there and bring in traffic for
months.
• Give out promo codes to blogs without hesitation.

• Have an extensive and easily accessible press package.
• Don’t be afraid to ask individuals to endorse your app.
• Try to crack category-specific blogs. If you’re making a wine app,
contact wine blogs.
Control "e Hype

App sales thrive on hype. Learn to control the hype, and you will have
mastered the product launch. Hype will always be partly out of your hands,
but the rules mentioned above will help you put things in motion. But hype
will amount to nothing if it’s for a poor product. While there is truth to the
saying that there is no such thing as bad publicity, hype can backfire and
harm your efforts to generate hype in future.
Hype early
Start hyping early. If you know you have a unique product, let people in on
the secret before the launch. Having an interesting “Coming soon” website
can do this, by building a mailing list and getting Google juice for your
domain.

Make your website great
Needless to say, your app should have its own website. To make any of the
rules above work, you will need a point of reference, somewhere to send
the masses. Make the website interesting, show the app in action, and think
outside the box. Make the website an extension of your app, and you will
have yet another great tool in your marketing toolbox.
Launch big
When you launch, make it big. Send out the triumphant newsletter, and hit
all social media. Have you or your team write up blog posts, and pull every
lever and handle in your network. Hype is all about critical mass. The first
wave you set in motion will give you instant feedback on how to adjust your
hype machine.
Maintaining hype is all about introducing new venues in which to exhibit

your app. Get a steady stream of review websites to cover your app. Give
away promo keys on Twitter, and serve new content on your website.
Obviously, if you can get into the “What’s hot” or “New and noteworthy”
sections of the App Store, you’ve made it far.
In the end, hype is part luck and part skill. The best way to balance the two
is to keep asking yourself whether you can do anything else to add value,
mystery, polish or spin to your product. Rely on your own judgement. What
would excite you about this app if it were made by another developer?
• Give out promo codes on Twitter and in the blogosphere.

• Run contests related to your app. Give away prizes that make sense for
your category.
• Boost popularity by timing the launch of your app to coincide with a live
event or trending topic. Climate-related apps spiked around the COP15
Climate Summit in Copenhagen.

• Release your app with a big bang. Hold an online or live event. Attract
visitors in creative ways, by building a game or puzzle or just throwing a
contest or giveaway.
Example: Being Awesome In A Saturated Market

To illustrate the application of these rules, let’s take a play-by-play look at
one successful app. For the sake of convenience, let’s just call it “Awesome
app.”
Awesome app is a weather-forecasting app. This is a classic scenario: a re-

thinking of an established category. I can’t think of a more tired and
saturated market than weather apps, making this an excellent example of
being able to re-invent and compete if we have the right frame of mind.
Unique spin
The Awesome app reverse-engineers the trend of offering up increasingly

detailed and advanced weather data. Instead, it trims down functionality and
focuses on the very playful and human idea of exploring the weather
visually, by swiping through a virtual forecast. It builds uniqueness right into
the very concept and goes in the opposite direction of the market leaders.
Early hype, big launch
Prior to launch, the website for Awesome app presents a “Coming soon”
page that collects close to a thousand confirmed emails. A teaser video of
the interface generates some buzz and earns the app a nomination in the
App Star awards. The app launches at the end of December 2009. The
release newsletter goes out; a more elaborate version of the website, with
video and screenshots, goes up; and the developers make as much noise
as they possibly can in their networks.

Review websites
As soon as sales get a lift from the early launch hype, emails are sent out to
various review websites offering promo keys. Reviews started flowing in,
and chatter about the app is monitored on Twitter, where developers offer
help and follow up on questions. A “Making the app” video is posted that
gives existing customers something to enjoy (and that humanizes the team),
highlighting user recommendations.
The website for Awesome app gets some wind of its own by being featured
in various design blogs for its modern use of CSS animations, contributing
hype that doesn’t have anything to do with the app itself.

Picked up by larger websites
A week and a half after launch, larger websites such as TUAW started
showing interest. And coverage peaks with a TechCrunch article, which
ripples out to LifeHacker and other major websites. More than a month in
and we’re still seeing continued interest in the app; it has gathered
hundreds of five-star reviews in the App Store and has been featured in
both “New and noteworthy” and “What’s hot.”
What worked?
What worked for Awesome app was a combination of the marketing rules
discussed above:
• It was sufficiently unique in a crowded market to spark interest and be

seen as a “good story.”
• The idea of a “visual weather forecast” was easy to convey and was
presented in a way that gave it high tweetability.
• It was completely the opposite of what leading competitors were doing.

• The team started hyping early with a “Coming soon” page. It was
appealing enough for people to tweet about it, and it eventually
attracted visitors not only because of the app but because of the design
of the website.
• A press package with everything you could want was freely available on
the website, making it easy for blogs to write about the app.

Parting "ought
Not a single dime was spent on marketing it, yet the Awesome app reached
tens of thousands of people. If you have a unique product and apply some
of the ideas above, you too can secure free exposure for your beloved app.
It’s a rather democratic and honest process because you are required to re-
invent apps by adding unique features. Marketing then becomes all about
making it easier and more interesting for people to talk about and share
your creation.
As with most other things in life, there’s no surefire way to create a

successful app. But keeping in mind some of the things we’ve talked about
here—both at the conception and the execution stage - will put you in a
position to build awareness of your application much more easily.

A Study of Trends in Mobile Design
Alexander Dawson
The industry has evolved in many ways, but one particular area has affected
how we build websites to a greater extent than any other. The surge in
Web-enabled mobile devices has forged a subculture of visitors who require
the adaptation of our websites to meet their needs. While mobile design is
still in its infancy (and little primary research on mobile trends exist), we
need to observe how this now critical element of our industry is evolving,
and the patterns which exist from current development efforts.
The aim of this article is to showcase the variety of methods in which some
of today’s most popular websites provide an interactive and (hopefully)
useful mobile experience for their end users. There are plenty of big names
which were analyzed, such as Facebook and Amazon, and you’ll see plenty
of useful graphs to draw some inspiration from. With statistics and some
really interesting revelations on the diversity of modern design, you can be
excited about the future of mobile Web design!
What is "is Anyway?

To determine some best practices and common trends within the ever
growing field of mobile Web design, a study was conducted to analyze how
popular websites deal with important factors relating to the information
architecture and design implementations within mobile design. Because this
research could have covered any number of variables, it’s important to state
that this study isn’t going to answer every one of your questions – but it
hopefully may help you to learn a few things!

Of the websites that are measured and accounted for within the study, we
not only examined how these websites deal with mobile devices and how
visitors are served a mobile experience, but also if they had non-Web
features, such as mobile apps, that can play a useful role in the process. In
addition, some of the layout conventions, design choices, coding levels, and
some useful features specific to mobile websites have been measured (to
their existence, their conformance level, and the method they undertake).
Note: While a great deal of effort has been put into making this study as
accurate as possible, the number of variables being considered may result
in anomalies. Factors such as websites without mobile experience have
been accounted for (as has bias – to the greatest extent possible, during the
study).
Examining the Variables

Before presenting the results of this study, it’s important to account for a few
of the variables and methodology that came into play to explain how the
research and results were formed. Using this information you can hopefully
recognize the limitations of this particular study, and, if you really feel
adventurous, perhaps you could expand on the subject and conduct some
research of your own to see how the results apply under different situations.
It could make for interesting reading!
Regarding the methodology for this study, the protocol begin by selecting
an independent group of sites (outsourced) and variables to test against –
many of which had never been examined on such a scale (or in such depth)
previously. The approval for which variables were included had to meet
certain criteria. Firstly, the results had to be interesting (and could affect how
the mobile design situation is seen), and also had to be statistically
significant (we don’t want to state the obvious).

Note: Some variables were dropped from the final analysis due to a lack of
conclusive, useful results. An example of this is the support for orientation
(portrait and landscape modes); as a result of how browsers deal with the
layout, this became a non-issue, seeing 100% native support.
Site Selection Protocol
Picking a group of websites to analyze is, of course, a critical part of the

process. To eliminate the potential for bias or for focusing on a niche, it was
decided that the top 100 websites depicted through Google’s AdPlanner list
would be a suitable candidate. While the list held 1,000 websites and the
study could easily be expanded, we used the initial 100 websites to receive
a good sample and to provide enough variety for the baseline results. This
level is used as the qualifier for statistically significant results.
Variables (Per Category)
The results of this study wouldn’t be anything without its variables. When
deciding what to test against, the focus became twofold: how the mobile
experience is activated and how that experience functions. How visitors are
directed to a mobile experience became worthy of attention due to the
increasing number of implementations that exist. Secondly, it was vital to
test those pages to ensure they accounted for speed, bandwidth, display
size, touch screens, and other best practices.

Plenty of variables were considered to give you some informative results to learn
from.
Margins for Error
As with any study, there is always a potential for error or bias to occur. To
avoid as many of these issues as possible not only were the websites
independently sourced, but all testing was undertaken on a desktop
machine, several handheld devices, and a number of emulators (this
occurred on every website). Following this practice reinforced the results
(avoiding erroneous numbers), and the testing was verified on two separate
dates to ensure that the experience resulted from consistent practices.

And Our Survey Says…the Results
Now that all of the basics (as to how the study was undertaken) have been
explained, it’s time we get down to the really interesting stuff – the results!
You should be prepared for plenty of charts and graphs, and some of the
results may be really surprising. We’ve broken down each type of result into
its own subsection and have provided various ways the results can be
interpreted, so hopefully the findings of this study will be quite apparent.
Without any further delay, let’s get down to business!
A Study of Trends in Mobile Design (2)

Method of Access
Within this test it was important to establish whether a mobile experience

was made apparent to a user immediately. When a user proactively visits a
website they want to be made aware that their device is either supported, or
that the regular website will load. In this test, we not only examined whether
a redirection or device detection occurred, but also if the mobile experience
was provided on the standard website (rather than a subdomain) and if a
regular PC could switch to the mobile version too.

The proportion of automatic redirects against desktop websites with optional
mobile support.

The distribution of websites which implemented a mobile design on the WWW
subdomain.

How mobile-friendly websites dealt with desktop PC users trying to access the
mobile website.

While the number of websites that employed a script to detect and redirect
visitors to a mobile experience wasn’t as high as one might have expected
(as many believe that the mobile website should come first to boost loading
times), an interesting trend occurred where all but one website
(answers.com) employing a mobile version of the experience (on the WWW
subdomain) forced the redirection of PC users back to the desktop view
without allowing entry to access the mobile edition (if they wished to).
Mobile TLD Usage
This second test aimed to determine the use of TLD conventions in mobile
design. In order to keep the scope of the results as strict as possible, only
subdomains (such as m.) and the .mobi TLD were considered (along with
dedicated mobile websites). As such, directory paths on the WWW domain
such as “/mobile/” were not considered. The possible implications of this
result could showcase the popularity for the .mobi TLD, and trends which
may exist in the use of subdomains on mobile websites.

The distribution of mobile TLD subdomains, including the level of extension
popularity.

The number of websites which offered no mobile-optimized experience in any
form.

A graph showcasing the number of subdomains supported per website (on
average).

The levels of which WAP- or WML-enabled devices are supported or offered
access.

The percentage of websites which redirect the user to a separate mobile TLD.

Interestingly, while many sites offered some form of mobile experience and
some redirected the visitor, the use of .mobi extensions was much lower
than expected. In addition, an unusual trend made itself apparent. Unlike
other nations’ mobile websites, Asian ones trended toward using “3G” in
preference to “m” or “mobile” (as used elsewhere). It’s worth mentioning in
addition that only Apple devices were lucky enough to receive a dedicated
website using the “touch” or “i” subdomain.
Mobile Phone Apps
While this test was not so much about the type of code rendered in
browsers, it seemed prudent to determine how many websites in the
surveyed list provided a mobile application for devices such as iDevices,
Android, or Blackberry. The results of this test simply looked for the
presence of a mobile app; the platform itself is not taken into account. With
so many apps having Web connectivity, the results of this test really push
the barriers to access in finding how mobile-friendly a website is.

The number of websites that had mobile phone-specific apps (for any platform).

The percentage of websites with a mobile app, but without a mobile-friendly
website.

While it’s not surprising that many of the top 100 websites had a mobile app,
due to the popularity and the widespread use of their services, what did
become apparent and rather interesting is that some of the listed websites
which did not have a mobile-friendly website (in any form) still had an app.
This particular trend seems to indicate that the transition toward a mobile-
friendly set of services is down to the heightened demand for apps (which
unlike mobile websites, have no fallback to function on).
Average Loading Time
In the next test, we felt it was important to measure the loading times of
each website to see how mobile experiences account for the bandwidth
restraints and temperamental speeds of the average Web user. For the
purposes of this study, each of the times were registered over a Wi-Fi
connection (not a 3G or Edge stream due to some emulator usage, to
ensure balanced results) and were done using an uncached format;
therefore, the loading time would be accurate to include any external
resources.

The highest, mean, and lowest loading times as calculated from an uncached
"cold boot."

The percentage of websites requiring more than 10 seconds loading time on a
Wi-Fi connection.

The percentage of websites requiring less than 3 seconds loading time on a Wi-
Fi connection.

While caching will produce substantially quicker loading times, the results
were fairly conclusive that the loading time of each website was pretty
evenly spread, with only a small number of websites having load times of
over 5 seconds (often in such cases it was a result of slow server response,
rather than of the physical content being transferred). As visitors obviously
don’t want to wait for long periods of time to get their data, a speedy and
effective loading time has become critical to the design process.
Home Page Asset Size
Along with the time it took to load a page, in equal measure it immediately
became obvious that the size of the files and any loaded external resources
should be measured. With many mobile Internet plans having capped
services and international browsing potentially becoming prohibitively
expensive (by the megabyte), it seemed only fair to determine how each
website was optimized and whether the amount of uncached data loaded
was as small (or big) as a regular desktop-oriented website.

The highest, mean, and lowest file (and asset) size as calculated with caching
turned off.

The percentage of websites with a total uncached asset size of more than 100KB.

The percentage of websites with a total uncached asset size of less than 25KB.

The results of this test are rather interesting. While many websites
(especially WAP-oriented ones for less capable devices) required less than
25KB to function, which seems like an acceptable level–a large number of
websites supposedly providing a mobile experience required over 100KB,
some even as high as 0.5MB! More interesting is the coincidence that the
percentage of websites that have asset sizes of fewer than 25KB, matched
(exactly) the percentage requiring over 100KB.

Doctype Declarations
When producing a website, one of the initial questions we ask ourselves is

what language or version of that language will best meet our contents
needs. The debates about HTML vs. XHTML have been endless, and as
many mobile variants exist (the mobile profiles for XHTML and WML), it
became apparent that statistics related to the types of DTD most often used
could be of benefit to readers. This test therefore examined the Doctype of
the front page to see if any patterns of usage exist.

The distribution of mobile website Doctypes, based on language versions and
profiles.

The percentage of websites using a mobile-specific profile in preference to
desktop profiles.

The percentage of websites that support both a WML and full XHTML
experience.

The results show conclusively that XHTML is currently more popular than
HTML (or HTML5). This could be down to HTML’s lack of a mobile profile
(used in most cases), though it can be noted that many smartphones
supported HTML and XHTML. In addition, the spread of mobile vs. desktop
profile usage was fairly similar. This questions the need for mobile profiles, if
the full specs are supported. In addition, Facebook’s iPhone-friendly website
was the only one which failed to provide any Doctype at all!
Code Validation
With the semantic Web and the need for our industry to maintain standards,
this test followed an earlier study by Jeffrey Zeldman in which a large
number of websites were put through a simple “pass or fail” test against
validation. While Zeldman’s research focused on the Alexa top 100, this
piece used a different set of data. While standards aren’t the be-all and end-
all of design, this test was included to provide additional comparisons as to
the stage conformity to semantics were.

Distribution of website validation (in the case of CSS, proprietary properties were
ignored).

The percentage of top 100 websites with a front page that validates against the
DTD chosen.

Because this checkpoint focused only on the front page of mobile-friendly
websites, the results are not as complete as they could be. They do instead
provide a good indication as to the care being given to mobile experiences.
Unfortunately, the results seem to correlate with Zeldman’s research in that
the overwhelming majority failed to meet the standards for the DTD they
chose to conform too. This seems to reinforce the fact that design is more
important to those designers, than optimizations or quality.
Code Separation
The next test that was carried out links quite heavily into a few of those that
were previously carried out. The separation of structure, style and behavior
has been shown to have benefits in reducing file sizes (due to avoiding
repeat coding and to cache advantages). It therefore seemed right to see
not only if websites did separate their style or behavior, but also if they took
advantage of CSS3 or jQuery in the mobile design to provide a more
dynamic behavior within the website layout.

The percentage of websites using embedded inline style rather than external
files.

The percentage of websites using external CSS2.1 or CSS3 within their designs.

The percentage of websites using external JavaScript or jQuery within their
designs.

While you would have thought that most websites would immediately break
the style and behavior from their mobile pages in order to improve
performance, a moderate number of the websites did have all of their code
directly tied into the page. In addition, only a rare number of those mobile
websites took advantage of the jQuery framework, and an equally small
number made use of CSS3 media queries to dynamically scale the layout.
The numbers for CSS3 usage were, predictably, similar to HTML5 usage.
Font Family Types
Typography is an essential element of the Web and of how information is

visualized. This particular test was created to not only see which Websafe
typefaces are being implemented on the Web but to see what font families
are being used. In addition, any websites which rely on the default typefaces
by not providing a font stack (or which have a stack with multiple typefaces)
would be noted. The elements for which this test was created were not only
based on headings, but on all manner of content in the page.

A distribution showcasing the typefaces used within the primary font stack.

The percentage of mobile designs with no font stack declared (using defaults).

A graph showcasing the number of fonts declared within a family, per website.

The results are quite surprising. In every case where a font family was
declared, the category of typefaces used was always sans serif (for both
headings and body text). In no instances did serif or another classification
get used, and, in some cases, no font family was declared at all (which could
be due to inconsistencies in available fonts for such devices). In addition,
the number of occasions where no font stacks were built–resulting in the
use of system defaults alone–was fairly significant.

Heading Contrasts
Since the evolution of the cellphone, the ability to have color screens with
as much depth and clarity as a desktop PC (using high definition graphics)
has increased the ability for us to give our headings and content the colors
of the rainbow, both in the foreground and in the background. This test was
added to the study in order to see if any trends existed, the range to which
color is used within headings, and to determine whether mobile websites
made use of background effects such as gradient colors.

Showcasing the number of colors used within the foreground or background of
headings.

A distribution of websites using a black foreground or white background in
headings.

The percentage of mobile websites using a gradient background within a
header.

As you may have expected, the majority of websites showcased in the list
made use of either black or white as the primary colors (in certain cases,
shades of grey were used). This stands to reason as a method to keep the
contrast ratio high on small screen devices, in order to boost the readability
of the content. Another trend uncovered was the preferred use of gradients
within the background of headings to give them an added layer of texture,
instead of using solid colors or an increased text size.
Body Content Contrasts
The ability to showcase color in our designs is central to how we subtly

influence our visitors. Carrying on from the previous test targeted at
headings, this one involved examining the colors used within non-heading
level elements and determining which colors they used. As this has a big
impact within accessibility and the general scope of design, a mixture of
visible foreground and background variants were recorded (though as with
the previous test, the results were limited to the front page).

Showcasing the number of colors used within the foreground or background of
body content.

The percentage of websites using a black foreground on a white background in
body content.

Within the previous set of results for headings, black and white were shown
to be dominant within the text in order to maintain a visible level of contrast.
This set of results, as you might expect, follows the same trend and uses
less additional colors in the palette. While the color contrasts were only built
up from a sample of each website’s front page (and then contrasted against
each other for the comparison), the results clearly show that a sensible
approach to text visibility has been maintained.
Authentication Required
Many places require visitors to login before full access to a service is

granted. On most desktop websites, a bunch of information is provided
without a user needing to be registered (explaining features or contact
details). However, an interesting trend seemed to exist in which mobile
users were expected to have an account and know what the service did, as
if the mobile website were simply a bonus feature of the service (thereby
only offering a login form). The aim of this test was to see if this was the
case.

The number of websites requiring the visitor to login before accessing pages.

While it’s understandable that some websites do not require users to
authenticate themselves–and this means that the number of recorded
“forced logins” will be drastically reduced–the results of this test are quite
shocking. While it should be considered bad practice to require logins on a
website without any description of the service being present (for mobile-
only traffic), a number of popular websites which were contained within the
top 100 list proved positive for doing this, as they had no useful site
information!
Returning to a Full Website
The next test depended entirely on the mobile website’s ability to follow
common requirements and return the visitor back to a non-optimized
website upon request. While a website’s mobile experience will be enough
for some, it’s important to realize that some people may not adjust well to
new a UI or may request functionality that only exists on the main website,
and offering a fallback mechanism is worthwhile. The test also aimed to
uncover any naming conventions used to represent this link (if one exists).

A graph of the various naming conventions used in links toward a full website
link.

The percentage of websites which do not have a link returning you to the full
website.

In the results, some websites offering mobile versions of their services used
common words in their links to indicate returning to the main website, such
as “full site” or even “desktop version.” In these cases, no common
preference could be found even though usage was spread fairly evenly.
What is quite surprising however is that many who force-redirected visitors
to the mobile website, refused to link or to allow access the full website.
This in turn limited the ability of mobile visitors to access some services.
Navigation Conventions
This test was focused upon what could be considered one of the most
important elements of a website. A successful navigation scheme can be
the difference between an easy-to-use interface, and a complex and
potentially unusable website. When carrying out this test, four types of
navigation conventions were checked as to whether they were being used
on the home page (most sites used more than one): text links, icon-based
navigation, image links, and special menus (such as dropdowns or panels).

A distribution of websites making use of text, icon, or image-based navigation
styles.

The percentage of icon- and image-based navigation against conventional text.

The percentage of websites which employ the use of menus (or content on
demand).

The results of this test were fairly conclusive in that every single website (as
you might imagine) had standard text anchor links, though some menus
were formed of plain text. In addition, image-based menu options were quite
popular and were actually used more often than icon-based navigation,
which, for devices that depend on icons representing apps or services, was
quite a surprise. Special menus also saw some popularity, especially when
used with content-on-demand scrolling mechanisms.
Home Page Link Ratio
Having a relatively small amount of space can be a real problem in mobile

devices, and, therefore, the potential for confusion as to navigation options
and how many links are provided can potentially increase the difficulty for
users to know the extent of where their choices will lead. If a website has
too many links (or too few), the choice can quickly overwhelm a user’s sense
of perspective. As such it seemed worthwhile to see how many options
were provided in the form of links on a single page.

The number of websites using a small, medium, or large number of links on the
front page.

The percentage of websites using a large number of links as a result of a menu
convention.

When testing the websites, the results were categorized based on the
number of links that existed in the front page of a website (these were
labeled as small, medium, or large as per the link ratio). For the websites
being measured, the results indicated that fewer links were visible on a
mobile website than on the desktop variant (even when complex layouts
were used). This seems to follow conventions in that a reduced viewing
space should hold less information to avoid unnecessary scrolling and to
reduce complexity.

Golden Image Ratio
Images on a mobile website can be a tricky affair, as these devices often

require more bandwidth than anything else and therefore can reduce the
loading times. Within this test, the trend of using small, medium, and large as
a representation of the number of images on the page were used, similar to
the link testing. Primarily focused upon the home page, the amount required
to fall into each category was reduced as most websites will naturally hold
more text links than images (per page, on average).

The number of websites using a small, medium, or large number of images on
the front page.

The percentage of websites using a large number of images resulting from
icon navigation.

The percentage of websites using a large number of images resulting from image
navigation.

As you might imagine, on mobile websites the results backed up many
assumptions that mobile websites will have not only fewer images on the
page, but will have smaller images presented on the screen (to match the
kind of experience available on small screens). This in turn helped reduce
the file sizes in earlier tests (and the speed benchmark). What makes this
result particularly interesting is that websites (such as Flickr) which oriented
around images also followed this reductionist trend.
Link Click Region
The purpose of this test was to go beyond the mere presence of links (and
images with links) and to examine how large the click region actually was on
the page. With mobile devices and small screens supporting touch
sensitivity, there is a need to keep link click regions as large as possible to
ensure the usability and accessibility of such devices (to help with big,
imprecise fingers). The scale used followed small, medium, or large, and
focused upon the link click’s size compared to other elements on the page.

A graph with the average size of a website's link click region (small, medium, or
large).

The percentage of websites with a large number of links, images, and large click
regions.

The results of this particular test were evenly spread, showcasing a good
number of websites using large- to medium-sized links that ensured
navigating could be accomplished without an accident occurring. While this
trend was especially present in more image-oriented websites (as linking
often occurred in image thumbnails), there was also an interesting trend in
which Asian or Russian websites were more likely to have smaller click
regions (fewer characters in words also reduced the click region further).
Block Placement Ratios
The next test looked at the visual layout of the page and examined how the
design was broken down into either physical or visual blocks of information.
It’s worth stating that all of the websites measured used a single column
layout, but that the way in which links and segments of content are split may
give the visual indication of separation, which was worth examining further.
As mobile websites require a lot more scrolling than desktop websites, the
separation of blocks becomes more critical to visual identity.

Distribution of horizontal elements (columns or table cells) within the viewport.

Distribution of vertical panel segments (headings or separated rules) per page.

The highest, mean, and lowest range of blocks, both in column and panel
distribution.

Interestingly, while the majority of websites held no horizontal panes
(including table cells, navigation links, and other side-by-side elements), a
number of websites defied convention and had anywhere between two and
eight points of reference within a single line on the viewport. This visual
separation was also backed up by how a number of websites had vertical
breaks, which split the content into separate sections. Most mobile
websites’ readability was increased due to such content organization.
Scrolling Experience
The final test was included as a representation of how scrolling is

experienced within the mobile website. The variables analyzed included the
number of fingers required to initiate a scroll (as when content scrolls using
an overflow, two fingers rather than one are required), and whether the
window supported the fancy flourishes of jQuery, JavaScript, or CSS3 in
providing paneled scrolling – where panes of content would rotate at
specific intervals or sections could be scrolled by request.

The percentage of mobile websites using paneled navigation over conventional
scrolling.

Percentage of overflow-based scrolling in preference to a full page scrolling
effect.
The results of this test show a general lack of paneling in general (which is
representative of the lack of “flourish” scripting in most mobile websites).
This may have been partly due to the nature of the websites being studied
(portfolio or showcase websites are more likely to have paneled
mechanisms). What is interesting, however, is that to increase the simplicity
of the designs (as none of the sites used overflow text), they also maintained
a liquid layout to reduce the complexity of required scrolling.

Going Beyond the Basics
While the sample used did constitute a wide array of Web presences, it’s
worth noting that different niches may produce varying levels of results. For
example, a study of the same variables upon websites which primarily act as
a designer’s portfolio (as denoted in the results) will obviously account for
different usage needs, and the experience may therefore vary. That said,
the trends which the websites employ do bear a resemblance to many
others (and therefore can be deemed as reliable).
Different websites will follow different trends, but they still have comparative
similarities.

To ensure that the results were not simply a result of the top 100 websites’
own popularity bias, an extra 10 websites were selected (their results
weren’t logged as it was an exercise of conformance) in order to see the
accuracy of the top 100 findings. Within these was a mixture of varying
website types, but the overwhelming majority of websites followed similar
practices, or made changes which would logically make sense under the
usage scenario. Therefore, the trends do seem to apply consistently.
Note: In addition to the above, it’s worth stating that a couple of the
websites within the top 100 listings were either subdomains, or international
versions of a website which has already been mentioned. While this could
prove an issue for repeat conventions, the results varied enough to qualify
their inclusion.
Common Factors at Play
The common factors which were widely implemented included the trend of
using scripts to redirect mobile-friendly users, in preference to giving visitors
a choice (which is interesting, as it constitutes a double-edged sword in
terms of usability). In addition, the trend of subdomains also followed a well-
trodden pattern in order to be recognized easily by end users. A final
example, which showcases the common factors, is the unfortunate issue
that few of the websites’ code validated!

Some websites actually generated their mobile layouts using automated tools
like Mobify.
Models for Other Genres
Expanding this study across a different cohort of website types may have
varying differences as to how trends are implemented. Examples include the
increased use of CSS3 and “flourishes” in portfolio websites, a reduced
number of mobile apps on small business websites, and increases in the
amount of required authentication if the study were applied primarily to
social networks. In addition, if a website is more content-focused (like
Smashing Magazine), an increase in file sizes will be an obvious side effect.

Potential Improvements
Taking this study forward, improvements could be made. While the websites
were tested using a range of real mobile devices, including an Apple iPhone
4, a Blackberry device, a Nokia device, a phone using WinMo, and a couple
of phones using Android, a greater level of compatibility could be
established if an increased number of devices were used (excluding
emulators). In addition, a larger range of websites may boost the general
accuracy of the results (such as if all 1,000 websites were tested).
Additional studies could be undertaken on particular niches, like newspaper

websites.

"e Future of Mobile Design
As interesting as these results are, hopefully they will inspire you not just to
follow design trends, but to seek them out. While the Web may still be in its
infancy, mobile design is literally only a few years old. This means that
trends will likely evolve ever more rapidly, as more usability studies and
additional research are carried out to determine how user needs are being
catered for. The future of mobile Web design is an up and coming industry,
and we need to pay it plenty of attention.
As an increasing number of handheld devices appear (with different

renderers and viewport sizes), the way we design is being affected by
frameworks like jQuery, the advancement of standards such as HTML5 and
CSS3, and the way applications are gradually being pulled toward the cloud.
While this study showcases that rudimentary trends exist for mobile designs
(such as single column layouts), it will be an interesting next few years as
more designers account for the booming mobile audience.

"e Authors
Alexander Dawson
Alexander is a freelance web designer, author and recreational software
developer specializing in web standards, accessibility and UX design. As
well as running a business (HiTechy) and writing, he spends time in Twitter,
SitePoint's forums and other places, helping those in need.
Alexander Komarov
Alexander Komarov is a Russian designer (currently residing in Philadelphia),
who has been working in the field of Web and Mobile Interaction design and
user experience for over 7 years. He runs a nimble interaction design studio
that specializes in mobile interaction design and strategy. He helps his
clients break through the wall that separates them from their customers and
stand out in the competitive world of modern technology.
Cameron Chapman
Cameron Chapman is a professional Web and graphic designer with over 6
years of experience. She writes for a number of blogs, including her own.
She’s also the author of Internet Famous: A Practical Guide to Becoming an
Online Celebrity

Jen Gordon
Jen Gordon is the owner of Atlanta-based iPhone app design studio Clever
Twist. Her studio created the iPad application iBrite. She specializes in
usable interfaces, beautiful design and straight talk.
Jon Raasch
Jon Raasch is a front-end web developer/UI designer with endless love for
jQuery, CSS3 and performance tuning.
Kim Pimmel
UX Designer at Adobe, photographer, DJ, tinkerer.
Luke Wroblewski
Luke Wroblewski is an internationally recognized Web thought leader who
has designed or contributed to software used by more than 600 million
people. He is currently Senior Director of Product Ideation & Design at
Yahoo! Inc., author of two popular Web design books, and a top-rated
speaker at conferences and companies around the world.
Marc Edwards
Marc Edwards is the Director and Lead Designer at Bjango, an iPhone app
developer. Marc has been using Photoshop and Illustrator for over 12 years,
designing for print, Web, desktop applications and the iPhone.

Michael Flarup
Michael Flarup is a Copenhagen based interface designer & iconist. When
he’s not freelancing and blogging out of PixelResort.com he’s creating
iPhone apps with his young startup company Robocat.
Nick Francis
Nick Francis builds websites with an outstanding team at Project83 in
Nashville, Tennessee. He also co-founded Brightwurks that created web
apps Feed My Inbox and Linkpatch, along with mobile website gallery
Mobile Awesomeness.
Rachel Andrew
Rachel Andrew is a front and back-end web developer and Director of
edgeofmyseat.com, a UK web development consultancy and the creators of
the small content management system, Perch. She is the author of a number
of web design and development books including CSS Anthology: 101
Essential Tips, Tricks and Hacks (3rd edition), published by SitePoint and
also writes on her own blog. Rachel tries to encourage a common sense
application of best practice and standards adoption in her own work and
when writing about the web.
Steven Snell
Steven Snell has been designing websites for several years. He actively
maintains a few blogs of his own, including DesignM.ag, which regularly
provides articles and resources for web designers.

"e Smashing Shop
Feel free to check out more of our eBooks in
the Smashing Shop.
Smashing eBook #4│Mobile Design for iPhone and iPad │ 300 V413HAV

Mobile Design For Iphone and Ipad (Smashing Ebook Series)

Uploaded by

Copyright:

Available Formats

You might also like

Mobile Design For Iphone and Ipad (Smashing Ebook Series)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mobile Design For Iphone and Ipad (Smashing Ebook Series)

Uploaded by

Copyright:

Available Formats

Imprint

Published in November 2010

Smashing Media GmbH, Freiburg, Germany

Cover Design: Andrea Austoni

Editing: Thomas Burkert

Proofreading: Brian Goessling

Concept: Sven Lennartz, Vitaly Friedman

Founded in September 2006, Smashing Magazine delivers useful and

Version: December 2011

Smashing eBook #4│Mobile Design for iPhone and iPad │ 2

Mobile Web Design Trends

Web Development for the iPhone and iPad: Ge!ing Started

iPhone Apps Design Mistakes: Over-Blown Visuals

Make it a Mobile Web App

Se!ing up Photoshop for Web and iPhone Development

Smashing eBook #4│Mobile Design for iPhone and iPad │ 3

— Thomas Burkert, Smashing eBook Editor

Smashing eBook #4│Mobile Design for iPhone and iPad │ 4

Because designing websites for mobile devices brings some unique

Smashing eBook #4│Mobile Design for iPhone and iPad │ 5

Smashing eBook #4│Mobile Design for iPhone and iPad │ 6

As high-speed Internet connections have become more common in recent

There is a great variety of speeds of mobile Internet connections and of

As a growing number of mobile users move to smart phones with larger

4. Sub-domains instead of .mobi or separate domains

Smashing eBook #4│Mobile Design for iPhone and iPad │ 7

You’ll commonly see mobile versions of websites at such addresses as

Common Challenges in Designing for Mobiles

Smashing eBook #4│Mobile Design for iPhone and iPad │ 8

Because mobile technology is always changing, screen sizes are changing

Smashing eBook #4│Mobile Design for iPhone and iPad │ 9

Smashing eBook #4│Mobile Design for iPhone and iPad │ 10

Like any other technology, rapid change is a constant. Of course, Web

Smashing eBook #4│Mobile Design for iPhone and iPad │ 11

Smashing eBook #4│Mobile Design for iPhone and iPad │ 12

Considerations for Mobile Design

1. Clean, semantic markup

Smashing eBook #4│Mobile Design for iPhone and iPad │ 14

4. Labeling form fields

6. Avoid floats if possible

Smashing eBook #4│Mobile Design for iPhone and iPad │ 15

8. Pay attention to navigation

9. Consider Color Contrast

Sitepoint’s Designing for the Mobile Web

1. Don’t mix up your markup

Smashing eBook #4│Mobile Design for iPhone and iPad │ 16

3. Target the right customers

4. Publish the bare minimum

5. Choose a great domain name

Smashing eBook #4│Mobile Design for iPhone and iPad │ 17

7. Test, Test, TEST!

Smashing eBook #4│Mobile Design for iPhone and iPad │ 18

Familiarize Yourself with the Hardware and

Smashing eBook #4│Mobile Design for iPhone and iPad │ 19

StatCounter Global Stats – Top 8 Mobile OSs

Smashing eBook #4│Mobile Design for iPhone and iPad │ 20

StatCounter Global Stats – Top 9 Mobile Browsers

Smashing eBook #4│Mobile Design for iPhone and iPad │ 21