Posts

Why we should not make separate mobile websites

There has been a long-running war going on over the mobile Web: it can be summarized with the following question: “Is there a mobile Web?” That is, is the mobile device so fundamentally different that you should make different websites for it, or is there only one Web that we access using a variety of different devices? Acclaimed usability pundit Jakob Nielsen thinks that you should make separate mobile websites. I disagree.

Jakob Nielsen, the usability expert, recently published his latest mobile usability guidelines. He summarizes:

“Good mobile user experience requires a different design than what’s needed to satisfy desktop users. Two designs, two sites, and cross-linking to make it all work.”

I disagree (mostly) with the idea that people need different content because they’re using different types of devices.

Firstly, because we’ve been here before, in the early years of this century. Around 2002, the huge UK supermarket chain Tesco launched Tesco Access—a website that was designed so that disabled people could browse the Tesco website and buy groceries that would be delivered to their homes.

It was a great success—heavily stripped down, all server-generated (as in, those days screen readers couldn’t handle much JavaScript) and it was highly usable. One design goal was “to allow customers to purchase an average of 30 items in just 15 minutes from login to checkout.” In fact, from a contemporary report, (cited by Mike Davis), “many non-disabled customers are switching from the main Tesco site to the Tesco Access site, because they find it easier and faster to use!” It also made Tesco a lot of money: “Work undertaken by Tesco.com to make their home grocery service more accessible to blind customers has resulted in revenue in excess of £13m per annum, revenue that simply wasn’t available to the company when the website was inaccessible to blind customers.”

However, some blind users weren’t happy. There were special offers on the “normal” Tesco website that weren’t available on the access website. There were advertisements that were similarly unavailable—which was a surprise; whereas most people hate advertisements, here was a community complaining that it wasn’t getting them.

The vital point is that you never know better than your users what content they want. When Nielsen writes that mobile websites should “cut features, to eliminate things that are not core to the mobile use case; [and] cut content, to reduce word count and defer secondary information to secondary pages,” he forgets this fact.

Tesco learned this:

“We have completely redesigned Access so that it is no longer separate from our main website but is now right at the center of it, enabling our Access customers to enjoy the same features and functionality available on the standard grocery website. As part of this work we have had to retire the old Access website.”

Nielsen writes:

“Build a separate mobile-optimized site (or mobile site) if you can afford it … Good mobile user experience requires a different design than what’s needed to satisfy desktop users. Two designs, two websites, and cross-linking to make it all work.”

From talking to people in the industry, and from my own experience of leading a dev team, I’ve found that building a separate mobile website is considered to be a cheaper option in some circumstances—there may be time or budgetary constraints. Sometimes teams don’t have another option but creating a separate website due to factors beyond their control.

I believe that this is not ideal, but for many it’s a reality. Re-factoring a whole website with responsive design requires auditing content. And changing a production website with all the attendant risks, then testing the whole website to ensure it works on mobile devices (while introducing no regressions in the desktop website)—all this is a huge task. If the website is powered by a CMS, it’s often cheaper and easier to leave the “desktop website” alone, and implement a parallel URL structure so that www.example.com/foo is mirrored by m.example.com/foo, and www.example.com/bar is mirrored by m.example.com/bar (with the CMS simply outputting the information into a highly simplified template for the mobile website).

The problem with this approach is Nielsen’s suggestion: “If mobile users arrive at your full website’s URL, auto-redirect them to your mobile website.” The question here is how can you reliably detect mobile browsers in order to redirect them? The fact is: you can’t. Most people attempt to do this with browser sniffing—checking the User Agent string that the browser sends to the server with every request. However, these are easily spoofed in browsers, so they can’t be relied upon, and they don’t tell the truth, anyways. “Browser sniffing” has a justifiably bad reputation, so is often renamed “device detection” these days, but it’s the same flawed concept.

More troublesome is that there are literally hundreds of UA strings that your detection script needs to be aware of in order to send the visitor to the “right” page. The list is ever-growing, so you need to constantly check and update your detection scripts. And of course, you only know about a new User Agent string after it turns up in your analytics—so there will be a period between the first visitor arriving with an unknown UA and your adding it to your detection scripts (in which visitors will be sent to the wrong website).

Despite all this work to set up a second parallel website, you will still find that some visitors are sent to the wrong place, so here I agree with Nielsen:

“Offer a clear link from your full site to your mobile site for users who end up at the full site despite the redirect … Offer a clear link from your mobile site to your full site for those (few) users who need special features that are found only on the full site.”

Missing out features and content on mobile devices perpetuates the digital divide. As Josh Clark points out in his rebuttal:

“First, a growing number of people are using mobile as the only way they access the Web. A pair of studies late last year from Pew and from On Device Research showed that over 25% of people in the US who browse the Web on smartphones almost never use any other platform. That’s north of 11% of adults in the US, or about 25 million people, who only see the Web on small screens. There’s a digital-divide issue here. People who can afford only one screen or internet connection are choosing the phone. If you want to reach them at all, you have to reach them on mobile. We can’t settle for serving such a huge audience a stripped-down experience or force them to swim through a desktop layout in a small screen.”

The number of people only using mobile devices to access the Web is even higher in emerging economies. Why exclude them?

Mobile usability. Developing sites for all devices.

Mobile Usability

I also agree with Nielsen when he writes:

“When people access sites using mobile devices, their measured usability is much higher for mobile sites than for full sites.”

But from this he draws the wrong conclusion, that we should continue making special mobile websites. I believe that special mobile websites is like sticking plaster over the problem; we generally shouldn’t have separate mobile websites, anymore than we should have separate screen reader websites. The reason many “full websites” are unusable on mobile phones is because many full websites are unusable on any device. It’s often said that your expenditure rises as your income does, and that the amount of clutter you own expands to fill your house however many times you move to a bigger one. In the same way, website owners have long proved incontinent in keeping desktop websites focussed, simply because they have so much room. This is perfectly illustrated by the xkcd comic.

As I wrote on the website The Pastry Box on April 13th:

“The mobile pundits got it right: sites should be minimal, functional, with everything designed to help the user complete a task, and then go. But that doesn’t mean that you need to make a separate mobile site from your normal site. If your normal site isn’t minimal, functional, with everything designed to help the user complete a task, it’s time to rethink your whole site.

“And once you’ve done that, serve it to everyone, whatever the device.”

In a previous article, Nielsen wrote in September 2011 that he dropped testing usability with featurephones:

“Our first research found that feature phone usability is so miserable when accessing the Web that we recommend that most companies don’t bother supporting feature phones.

“Empirically, websites see very little traffic from feature phones, partly because people rarely go on the Web when their experience is so bad, and partly because the higher classes of phones have seen a dramatic uplift in market share since our earlier research.”

This is a highly westernized view. Many people can’t afford smartphones, so they use feature phones running proxy browsers (such as Opera Mini), which move the heavy lifting to servers. This is often the only way that underpowered featurephones can browse the Web. Statistics from Opera’s monthly State of the Mobile Web report (disclosure: Opera is my employer) shows that lower-end feature phones still dominate the market in Eastern Europe, Africa and other emerging economies—see the top 20 handsets worldwide for 2011 that accessed Opera Mini. Since February 2011, the number of unique users of Opera Mini has increased 78.17% and data traffic is up 142.79%.

A caveat about those statistics: not every user of Opera Mini is a featurephone user in developing countries. They’re widely used on high-end smartphones in the West, too, as we know that they are much faster than built-in browsers, and users really want speed.

Nielsen’s dismissal of feature phones reminds me of some attitudes to Web accessibility in the early 2000′s. His assertion that companies shouldn’t support feature phones because they see little traffic from feature phones is the classic accessibility chicken and egg situation: we don’t need to bother with making our website accessible, as no-one who visits us needs it. This is analogous to the owner of a restaurant that is up a flight of stairs saying he doesn’t need to add a wheelchair ramp as no-one with a wheelchair ever comes to his restaurant. It’s flawed logic.

Developing Usable Websites For All Devices

The W3C Mobile Web best practices say:

“One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. The context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation. Furthermore, some services and information are more suitable for and targeted at particular user contexts.”

There will always be edge cases when separate, mobile-specific websites will be a better user experience, but this shouldn’t be your default when approaching the mobile Web. For a maintainable, future-friendly development methodology, I recommend that your default approach to mobile be to design one website that can adapt to different devices with viewport, Media Queries and other technologies that are often buzzworded “Responsive Design.”

Combining these techniques in a smart way with progressive enhancement allows your content to be viewed on any device (and with richer experiences available on more sophisticated devices), with the possibility of accessing device APIs such as geolocation, or the shiny new getUserMedia for camera access.

Although many other resources are available, I’ve written “Mobile-friendly: The mobile web optimization guide” which you’ll hopefully find a useful starting point.

7 points how to build responsive website

While it may be exciting to work at a quickly expanding ecommerce company such as Lot18, our fervour was tempered a few months ago when the development team was faced with a choice: keep building on top of the site’s engine, which was never intended to be used for more than a few months after launch; or build an entire new platform from the ground up, one that could last us for years. We opted for the latter, cramming a year’s worth of work into three and a half months.

We also knew our visitors were accessing Lot18 in increasingly diverse ways, and that this trend would continue. Rather than anticipate our users’ preferences, we developed a responsive site that adapts and feels natural on a wide range of web-connected devices. Responsive web design was central to our development strategy, but it forced us to think differently than we ever had in development work.

Here are seven things we learned in building a responsive site in a short amount of time.

1. Really, how many sites can you build?

The good thing about being a developer is there’s always another device, browser or operating system to adapt to – no shortage of work. But building one version or app after another isn’t a sustainable strategy at a small company. Developing, testing and deploying a single code base streamlines almost every step in the process. When it’s crunch time and your eyes are tired, you can focus on one critical path – without distraction.

Responsive web site

2. The business comes first

The holiday shopping season is the busiest for ecommerce – and it’s completely mental for sites specialising in food and wine, as Lot18 does. With thousands of shoppers planning parties and buying gifts, we couldn’t assume every purchaser would be sitting at a desk or, alternatively, would take the time to search for an app, download it and use it.

It was an equally unsafe assumption that any particular user would employ the same type of device for each and every visit to the site, or that any of a user’s friends invited to join Lot18 would have similar devices. Taking a responsive approach prioritises the business and reorients our thinking as a development team. We’re closer to customer experience and not solely focused on our own schedules and timetables.

3. Stop chasing platforms and build features

Freed up from targeting platforms, we could dedicate more time to building features for the new site. For example, as we overhauled our checkout system, we could focus on one UI/UX strategy without worrying about device-specific builds. Moving forward, the development team will be more feature-focused and efficient.

Responsive web site

4. Everyone is QA

At a small company, everyone is busy and may not have time to walk through the new version of the site to help find bugs or unintended complications. But we encountered a nice consequence with our new responsive design: everyone could test the site on their own time.

If someone wanted to test or just check out the site in progress, they could use their phones during their commutes, or their tablets – or their TVs at home. Even better, this type of testing is likely closer to how our members use the site.

5. Be consistent across native apps and the mobile web

Lot18 will release a native iPhone app soon. Like most native apps, it is designed for iPhone and feels natural.

However, even the most dedicated app users will run into the mobile site via email, Twitter, Facebook, etc. The responsive site provides a consistency across the native and mobile web experiences, and reinforces the overall brand experience.

Responsive web site

6. Explore new interactions

Leading up to the launch, we observed a new behaviour in people previewing the site. Once they figured out that the site responded to them, they started playing with it. Responsiveness adds dimension to the experience and provides a fresh look as users move from one device to another – or one device mode to another.

What I saw was an emotional reaction that translated as, “This is fun.” This is always a good thing.

7. You’ll get reliable analytics

Finally, when comparing stats, it’s nice to know that users are hitting the same code and interacting with the same content. We’ve also gained new perspectives on how users behave, and have already seen positive changes reflected in our metrics.

The best thing about our recent launch is that, for us, there’s no longer a ‘real’ Lot18.com. Instead there’s a Lot18 experience, with any visitor – regardless of the device used – capturing a particular facet. As a result, our development group is closer to the business and can act almost like an extension of the customer-service department, providing a better online-shopping experience – which can’t be bad in the highly competitive ecommerce space.

Services to convert websites for Mobile devices

The rise of the mobile is undeniable. Many even say that the future of the web lies on mobile devices. Gone were the days when people can only access the internet at home or in their office, but now some of them even throw away the heavy PC and adopted the mobile devices for web surfing experience.

mobile website conversion services 5 Services to Convert Websites For Mobile Devices

Sensing the importance stated above, it will be really wise for you to consider a mobile version of your website. Well, going mobile entails another hefty development process, but the good news is there are cheap but quality solutions, and what’s better: right here is a list of services that you can use to either convert your website into mobile version, or create it from scratch.

Details after the jump!

5 Recommended Services:

mobiSiteGalore

mobiSiteGalore claims itself to be the easiest mobile web builder, for as average as 54 minutes their customers can already build a fully functional mobile version of their website. Another good thing is, as you may have noticed, many of the services listed below focuses on smartphones. Well, mobiSiteGalore do support low end phones that aren’t so smart. (Free – $225/year)

mobisitegalore 5 Services to Convert Websites For Mobile Devices

mofuse

With mofuse, there are two ways to convert your site to mobile: building it yourself through mofuse or hiring them to build it for you. By building it yourself using their application, you have more control over the design and development process, only you’ll have to pay a monthly subscription to keep the service going, else you can hire their design experts to build it for you. (Self Service: $7.95/month – $199/month)

mofuse 5 Services to Convert Websites For Mobile Devices

bMobilized

Turns your website into mobile version really fast with bMobilized. It offers the fast conversion with comprehensive customization as an option available for you to tune the design well.

bMobilized claims they support more than 13000 mobile devices, including all major brands. Also the more website you host using their service the higher the discount you get. So if you have a network of websites that needs conversion, bMobilized is the perfect service for you! ($19.99/month)

bmobilized 5 Services to Convert Websites For Mobile Devices

ConvertWebsite

ConvertWebsite requires their customer to send them the PSD file of the website they wish to convert. Why? To determine what approach is best in the redesigning process from desktop to mobile. Its method is quite similar to Code My Concept, which means handcrafting your provided PSD into mobile website.

Unlike other services, this service actually takes days for the conversion. For a general conversion the delivery date is 9 days, with option to expedite the process. The price is fairly high compared to other service, but consider that your site is handcrafted by industry professional. ($307 – $362)

convertwebsite 5 Services to Convert Websites For Mobile Devices

Mobify

If you are engaged in e-commerce, Mobify is probably the best service out there for you. Mobify offers HTML5 features for its clients, and their experienced teams will design your mobile site to your specific requirements, with the fact that most stores going from concept to launch within 3 weeks. You can also go for self-serve solution by referring to their Publisher page. (Publisher Pricing: $0 – $1000)

mobify 5 Services to Convert Websites For Mobile Devices

More:

onbile

In a hurry to create a mobile version of your website? Well, with only 3 very simple steps and 5 minutes at hand you can! Onbile supports smartphones like iPhone, Android, and Blackberry. The only disadvantage here will be its limited templates, but their templates are generally awesome! (Free)

onbile 5 Services to Convert Websites For Mobile Devices

Mobile App America

Mobile App America promises better SEO for your website, and most of all it helps to gain a competitive advantage among your competitors who doesn’t have an elaborated mobile version of their websites yet. As of writing this, it supports devices including iPhone, Blackberry, and Android. (Free)

mobile app america 5 Services to Convert Websites For Mobile Devices

MobStac

MobStac delivers the future-ready, HTML5-enabled experience for your mobile website. It also got easy customization, and supports several themes (if you want a change of design) and CMS integration.

Among other services, MobStac is probably one of the few that has an in-depth monetization plan for mobile websites. The only disadvantage is the service is currently in Beta, but you can sign up for an invite. (Free – $19/month)

mobstac 5 Services to Convert Websites For Mobile Devices

Conclusion

Think if you will really need a mobile version of your website. Mobile conversion has its ups and downs. The pros are indeed easier navigation, optimized user experience, and focused site content.

Its disadvantage, however, is there will be limited advertisement space. Really. Also, if your website exists with heavy and tantalizing graphics and you want it the same in mobile version, you might need to think to redesign the current site or abandon the conversion as the mobile website should be designed with minimalism in mind.

So consider carefully between the pros and cons, and make the wise decision that will benefit your users and you.

How to build a Mobile Website

Over the past few years, mobile web usage has considerably increased to the point that web developers and designers can no longer afford to ignore it. 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 buying PCs 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 legacy browsers.

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.

Smartphone in How To Build A Mobile Website

Source: Nielsen Study, Image credit

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

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.

Facebook-mobile in How To Build A Mobile Website

Large image

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. Even though, browsers have spoofed their UA string to get around this type of detection in the past. 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.”

Client-side Methods & Media Queries

Alternately, the easiest approach involves detecting the mobile device on the client side. One of the earliest techniques for including mobile stylesheets involves taking advantage of the stylesheet’s media type, for instance:

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 (you can see another practical adaptation of media queries in Ethan Marcotte’s article Responsive Web Design). Since mobile devices typically have smaller screens, we can target handheld devices by detecting screens that are 480px and smaller:

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:

Finally, define another stylesheet handheld.css with additional styling for mobile browsers and link them on the page:

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

Ikea-website in How To Build A Mobile Website

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

Cnn-regular-vs-mobile1 in How To Build A 

<p>Mobile Website” width=”500″ height=”265″ /></p>
<p>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 <strong>single columns</strong>.  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 <code>display: none;</code> on any less important elements. Finally, save additional pixels by reducing margins and padding to create a tighter layout.</p>
<h4>Reduce Bandwidth</h4>
<p>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 <code>display: none</code> on any unnecessary content images.</p>
<p>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 <code>as-text</code> class for <code>img</code> and make sure that <code>alt</code>-attributes are properly defined in your markup):</p>
<h4>Other Changes</h4>
<p>Besides addressing screen size and bandwidth concerns, there are a  few additional changes that should be made in any mobile stylesheet.  First, you can <strong>improve readability by increasing the font size</strong> of any small or medium-sized text. Next, clicking is generally less  precise on mobile devices, so make sure to increase the clickable areas  of any important buttons or links by setting <code>display: block</code> and adding padding to the clickable elements.</p>
<p>Additionally, <strong>floated elements</strong> 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 mobile, so you should always opt for adding  vertical scrolling as opposed to horizontal.</p>
<p>Finally, <strong>mouseover states</strong> do not work with most mobile devices, so make sure to have proper definitions of <code>:active</code>-states. Also, sometimes it may be useful to apply definitions from the already defined <code>:hover</code> states to the <code>:active</code> 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.</p>
<h3>Beyond Stylesheets</h3>
<p>In addition to mobile stylesheets, we can add a number of special mobile features through mark-up.</p>
<h4>Clickable Phone Numbers</h4>
<p>First, most handheld devices include a phone, so let’s make our phone numbers clickable:</p>
<p>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).</p>
<p>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 <code>phone-link</code> class to disable the link styling in your screen stylesheet, and then include it again for mobile.</p>
<h4>Special Input Types</h4>
<p><img src=

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:

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 the current 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:

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:

However, similar to disabling the scrollbars, this technique takes control away from the user and should only be used for a good reason.

Additionally, it is possible to add certain styles based on the device orientation. This means that different styles can be applied depending on whether the user is holding their phone vertically or horizontally.

To detect the device orientation, we can use a media query similar to the client-side device detection we discussed earlier. Within your stylesheet, include:

Here portrait.css styles will be added for vertical devices and the landscape.css will be added for horizontal.

However orientation media queries have not been adopted by all devices, so this is best accomplished with the max-width media query. Simply apply different max-width queries for the different orientation widths you want to target. This is a much more robust approach, since presumably the reason to target different orientations is to style for different widths.

Special Concerns For iPhone / iPad

Iphone-41 in How To Build A Mobile Website

With a market share of 28% and estimates of as much as 50% of mobile browsing going through iPhone, it makes sense that developers make special accommodations for the mobile giant.

No Flash

Regardless of Apple’s ethics, the reality is that iPhones do not play Flash unless they are jailbroken. Fortunately, there are alternatives to Flash, and iPhone’s issues with this technology are often easy to get around. The main use for Flash in modern websites is Flash video, which can easily be circumvented using HTML5 video. However since older browsers don’t support HTML5, make sure to include a Flash backup for non-supportive browsers (this is why the whole debate about Flash vs. HTML5 is a bit pointless, because you can actually offer both to your users and the user’s device will pick up the one it can render automatically).

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.

Apple-loves-adobe in How To Build A Mobile Website

A spoof of Adobe’s “We Love Apple” campaign, where the heart is replaced by the broken plugin icon.

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 will only cache files 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 serve these files only 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 EOT for IE (IE has actually supported @font-face since IE4).

After obtaining the necessary files, tie them all together with the appropriate CSS:

For more information, read this article on cross-platform font-face support.

Special iPhone / iPad Enhancements

Despite iPhone’s various shortcomings, the device offers a wonderfully rich user experience that developers can leverage in ways not possible with older mobile devices.

First, there are a variety of JavaScript libraries that can be used to access some of the more advanced functionality available in iPhone. Take a look at Sencha Touch, jQTouch and iui. These three libraries allow you to better interface with the iPhone, and also work on similar devices such as Android. Additionally, keep an eye on the much anticipated jQuery Mobile which has just been released in alpha.

Next, the App Store isn’t the only way to get an icon on your users’ iPhones: you can simply have them bookmark your page. Unfortunately the default bookmark icon is a condensed screen shot of the page, which doesn’t usually look very good, so let’s create a special iPhone icon. Also check the Icon Reference Chart by Jon Hicks for further details.

Start by saving a 57 x 57 pixel PNG somewhere on your website, then add this snippet within your <head> tag:

Don’t worry about rounded corners or a glossy effect, iPhone will add those by default.