mobile design for iphone and ipad

ImprintPublished 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: March 29, 2011

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

http://www.smashingmagazine.com

http://www.smashingmagazine.com

Table of ContentsPreface

Mobile Web Design Trends

Mobile Web Design: Tips and Best Practices

How to Build a Mobile Website

Web Development for the iPhone and iPad: Getting 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

Setting up Photoshop for Web and iPhone Development

How to Market Your Mobile Application

A Study of Trends in Mobile Design

The Authors


PrefaceWeb 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 e-book 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 e-book 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.

This e-book is not protected by DRM. A copy costs only $9.90 and is available exclusively at http://shop.smashingmagazine.com. Please respect our work and the hard efforts of our writers. If you received this book from a source other than the Smashing Shop, please support us by purchasing your copy in our online store. Thank you.

— Thomas Burkert, Smashing eBook Editor


http://shop.smashingmagazine.com


Mobile Web Design TrendsSteven 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


http://sender11.typepad.com/sender11/2008/04/mobile-screen-s.html


http://sender11.typepad.com/sender11/2008/04/more-on-mobile.html


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.


http://chrispederick.com/work/web-developer/

http://chrispederick.com/work/web-developer/

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 markupThe 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 CSSAlongside 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 tagsBecause 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 fieldsLike 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 headingsWith 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 possibleEven 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 paddingMost 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 navigationMost 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 ContrastBecause 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.


http://www.sitepoint.com/article/designing-for-mobile-web/

http://www.sitepoint.com/article/designing-for-mobile-web/

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 PracticesCameron 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 Software 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 Theme

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 WebsiteJon 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:


http://www.456bereastreet.com/archive/201004/html5_input_types/

http://www.456bereastreet.com/archive/201004/html5_input_types/

http://www.standardista.com/html5-input-attributes-browser-support




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.


http://en.wikipedia.org/wiki/Embedded_OpenType

http://en.wikipedia.org/wiki/Embedded_OpenType

http://www.sencha.com/products/touch/

http://www.sencha.com/products/touch/

http://www.jqtouch.com/

http://www.jqtouch.com/

http://code.google.com/p/iui/

http://code.google.com/p/iui/

http://jquerymobile.com/

http://jquerymobile.com/

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: Getting 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.


http://www.teehanlax.com/blog/2010/02/01/ipad-gui-psd/

http://www.teehanlax.com/blog/2010/02/01/ipad-gui-psd/

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 ApplicationsThis 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 GuidelinesThis 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 GuideThis 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 DetectionDavid Walsh provides good examples of proper browser detection for the


http://developer.apple.com/safari/library/documentation/InternetWeb/Conceptual/iPhoneWebAppHIG/Introduction/Introduction.html#//apple_ref/doc/uid/TP40007900

http://developer.apple.com/safari/library/documentation/InternetWeb/Conceptual/iPhoneWebAppHIG/Introduction/Introduction.html#//apple_ref/doc/uid/TP40007900

http://developer.apple.com/iphone/library/documentation/General/Conceptual/iPadHIG/Introduction/Introduction.html

http://developer.apple.com/iphone/library/documentation/General/Conceptual/iPadHIG/Introduction/Introduction.html

http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariWebContent/Introduction/Introduction.html#//apple_ref/doc/uid/TP40002079-SW1

http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariWebContent/Introduction/Introduction.html#//apple_ref/doc/uid/TP40002079-SW1

http://davidwalsh.name/detect-ipad


iPad and for the iPhone on his blog. Options for PHP and Javascript are included.

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

Detecting iPad Window OrientationDetecting 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">




http://davidwalsh.name/detect-iphone

http://davidwalsh.name/detect-iphone

http://net.tutsplus.com/tutorials/tools-and-tips/learn-how-to-develop-for-the-iphone/

http://net.tutsplus.com/tutorials/tools-and-tips/learn-how-to-develop-for-the-iphone/

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.


http://www.project83.com/blog/how-to-test-iphone-websites-locally-with-the-iphone-simulator/

http://www.project83.com/blog/how-to-test-iphone-websites-locally-with-the-iphone-simulator/

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 ApplicationJen 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.


http://www.teehanlax.com/blog/?p=1628

http://www.teehanlax.com/blog/?p=1628

http://www.smashingmagazine.com/2008/11/26/iphone-psd-vector-kit/




http://www.coroflot.com/

http://www.coroflot.com/

http://www.crowdspring.com/

http://www.crowdspring.com/

http://www.elance.com/


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.


http://www.odesk.com/

http://www.odesk.com/

http://www.iphonefreelancer.net/

http://www.iphonefreelancer.net/



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 The 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 Pretty List ViewsYou 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 The 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 ReviewedAlex 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”


http://www.akomarov.com/newcritique/

http://www.akomarov.com/newcritique/

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.”


http://www.mybudget-planner.com/

http://www.mybudget-planner.com/

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”


http://itunes.apple.com/us/app/id333198406?mt=8

http://itunes.apple.com/us/app/id333198406?mt=8

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 VisualsAlexander 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.


http://www.pinchmedia.com/blog/appstore-secrets/


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:


http://gizmodo.com/5133070/iphone-app-store-hits-500-million-downloads-we-break-down-the-numbers

http://gizmodo.com/5133070/iphone-app-store-hits-500-million-downloads-we-break-down-the-numbers

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.


http://www.unece.org/trans/conventn/Conv_road_signs_2006v_EN.pdf




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:


http://www.asktog.com/papers/raskinintuit.html

http://www.asktog.com/papers/raskinintuit.html

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 ContextAlexander 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 That 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 The 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 The Challenges Specific To The 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: 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. 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 AppJen 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 AppKim 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.

Retrofitting 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 DevicesLuke 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.


Setting up Photoshop for Web and iPhone DevelopmentMarc 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.


http://bjango.com/articles/photoappscaling/

http://bjango.com/articles/photoappscaling/

How to Market Your Mobile ApplicationMichael 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 The 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 Thought

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 DesignAlexander 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 This 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.A Study of Trends in Mobile Design (3)

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.A Study of Trends in Mobile Design (4)

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.A Study of Trends in Mobile Design (5)

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.


The 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.


The 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.


The Smashing Shop

Feel free to check out more of our eBooks in

the Smashing Shop.




mobile design for iphone and ipad

Documents

user agent

apple voice

virtual alphanumeric

embed color

special input

app sells

mobile devices

html5 input