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?

by

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.

by

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.

by

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.

by

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 decoding=

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.

by

Mobile apps vs. the web

, , ,

Pull the iPhone out of your pocket and look at the home screen. Likely, you’re seeing some well known brands on the web: Facebook, Flickr, and Google to name just a few. You’ll also see companies like Amazon, Target, and Walmart which sell a lot of products via the web.

Like you, these sites and companies know how to build an effective website using the latest and greatest web technologies. The iPhone’s Safari browser also supports HTML5 markup with CSS3 styling and is powered by a fast JavaScript engine. So why is there a proliferation of apps instead of web pages that can do the same thing?

Longtime A List Apart readers may remember the Put Your Content in My Pocket articles I wrote soon after the iPhone launched. Recently, I published a book that explains how to create products for the iPhone App Store. With this article, I’d like to share my experiences with both mobile web and software development to guide your future developments on the iPhone platform.

Apple <3 standards

From Apple’s point of view, iPhone OS and web technologies share equal footing. When you visit their developer site, the Safari Dev Center is prominently displayed. The iPhone gets all the press, but when you click on Safari Dev Center, there’s a ton of great information that explains how to use HTML, CSS, and JavaScript on an iPhone.

When you look back on your first experiences with the iPhone, one app stands above the others: The Safari web browser. Suddenly you were free from a mobile internet full of crappy CSS support or dumbed down presentation-like WAP. The iPhone’s real browser and the fact that it was in your pocket changed how you used the web.

Apple continues to invest heavily in the development of the WebKit browser engine used in Safari on the iPhone, Mac, and Windows. The result is a browser that excels in HTML5 and CSS3 support.

Apple also views HTML5 support as an important part of its marketing message for both consumers and developers.

Because it’s open source, the WebKit rendering engine also powers browsers for many other mobile platforms. If you’re surfing the web with a Blackberry, Android, or Symbian phone, you’ll find that your content looks just as good as it does on the iPhone. The only holdout is Microsoft’s Windows mobile platform which uses a browser based on the IE rendering engine.

With great HTML, CSS, and JavaScript support, developers are doing amazing things with the iPhone. Here are a few notable examples:

Pie Guy by Neven Mrgan

Pie Guy uses HTML5’s offline application cache so that it works correctly when you’re not connected to the internet, as well as CSS animations and transforms for the game’s effects. Neven also keeps track of developments in this area via the HTML5 Watch website.

Showtime by Nial Giacomelli and Benjamin Gordon

Showtime is a simple app that allows you to keep track of when your favorite TV shows are on. It uses a jQuery plugin by David Kaneda that provides many of the controls and effects that you see in standard iPhone applications.

Every Time Zone by Amy Hoy and Thomas Fuchs

Every Time Zone is a very simple, but effective, view of times throughout the world. The slider that lets you pick the time works very well on a touch screen. This web application looks particularly good on an iPad display.

With such great tools available and talented developers that know how to exploit them, the iPhone should be overflowing with web applications, right? Actually, the opposite is true: there are over 100,000 titles on iTunes and only a handful of popular applications have been created with web standards.

Apple has promoted both the App Store and web browser as ways for developers to get their creations into the hands of customers. They even gave the web a year-long head start before beginning to sell apps in the store. Clearly there’s more at play here: what attracts developers to iTunes instead of the web?

Going native

Before looking at the motivations of the move toward iTunes, we need some definitions. Developers have come to categorize the two iPhone development technologies as “native” and “web.” Web apps use HTML, CSS, and JavaScript that loads in Safari. All the examples above are “web apps.”

“Native apps” are created using the Xcode development environment in a language called Objective-C. These are the same tools used to create Apple’s own built-in apps like Mail, iPod, and even Safari itself.

Creating native apps is much different than the process you use to build web apps. Luckily, many of the underlying concepts are the same. Many web developers find that making the switch isn’t that hard:

  • Like JavaScript, the Objective-C language is a descendent of C. In addition to sharing similar syntax, both languages are object oriented. If you’re comfortable with JavaScript, you’ll feel equally at ease with Objective-C.
  • Native and web apps share some familiar design elements. On the web, you’re used to breaking an application’s functionality into pages, creating a series of <div> elements to organize the content on that page, and using XMLHttpRequest to update that content. With Cocoa Touch, “view controllers” are used like pages, “views” provide the building blocks for your content, and NSURLConnection objects act as your link to the internet.
  • Frameworks handle much of the hard work. Just as you rely on jQuery or Prototype when working in JavaScript, you’ll find yourself doing the same thing with Cocoa Touch when you work in Objective-C. Both languages also benefit from a vibrant developer community that is happy to share development tricks and source code.
  • If you’re a Flash developer who’s frustrated because there’s no way to play your creations on the iPhone, you’ll be happy to learn that ActionScript, like its predecessor JavaScript, shares the same lineage with C. The mechanisms for creating animation and other visual effects are different on the iPhone, but the concepts are the same. The recently announced Sparrow framework can help ease this transition, especially if you’re using Flash to develop games. It’s also a great example of the kinds of contributions made by your fellow iPhone developers.

To give you an idea of how similar things are, take a look at this snippet of Javascript code:

 var beAwesome = true; var myString = "chocklock"; if (beAwesome) { myString = myString.toUpperCase(); }

Now, compare it to the same thing in Objective-C:

 BOOL beAwesome = YES; NSString *myString = @"chocklock"; if (beAwesome) { myString = [myString uppercaseString]; }

In Objective-C, the variable definitions are different and function calls are replaced with stuff in square brackets. In a larger context, these are minor details. You can still see the logic that to be awesome, you just convert your string to uppercase letters.

One of the goals for my book about iPhone app development was to make this new environment accessible to people coming from other backgrounds. I dedicated an entire chapter of the book to explaining those square brackets in familiar terms.

The motivation

Learning how to use new development tools will take some effort. So why should developers go through this hassle when they could just bank on the web skills they already have?

Some of the motivation is purely selfish: Native applications give the developer more control over the mobile environment. The other incentive is altruistic: a native app is generally easier for the rest of us to use.

  • Speed: JavaScript performance has increased dramatically in the past few years, but as an interpreted language, it will never be as fast as compiled code that runs directly on the processor. In a mobile environment where processors run slower to conserve power, every clock cycle counts.
  • Data Management: Cocoa Touch has several mechanisms that make it easy to store your application’s data. This is important because caching information retrieved from a network can greatly improve a mobile application’s ease of use. The persistent data storage in HTML5 provides simple key/value access or raw database access using SQL. Core Data on the iPhone provides a much more sophisticated system where relationships between your data objects are managed automatically.
  • Animation: One of the hallmarks of both web and native iPhone applications is animation that reinforces a user’s actions. CSS3 provides ways to animate page elements, but much more sophisticated effects are possible when you access the underlying Core Animation framework with native code.
  • Resources: Mobile developers never have enough memory, network speed, or CPU power. These limited resources are much harder to control when they’re being managed by JavaScript or the browser. It’s easier for native applications to detect these situations and adapt the user experience accordingly.
  • Usability: iPhone users feel most comfortable when they’re using the standard controls they’ve become accustomed to in Apple’s built-in apps. HTML abstracts controls like <input> and <textarea> so they can work in many different environments. JavaScript frameworks, like jQTouch mentioned above, do a fantastic job extending these basic control mechanisms, but an iPhone user will still notice that they feel a bit different than platform-native controls.
  • Productivity: From the developer’s point of view, it’s typically easier to build complex user interfaces using Cocoa Touch: The frameworks do much of the heavy lifting and allow you to focus on the problem rather than its implementation. With the limited amount of screen real estate on a mobile device, a simple form on the desktop often turns into multiple views whose state needs to be managed by your application. Apple developed Cocoa Touch specifically to deal with this situation.
  • Integration: An iPhone has many capabilities that are beyond the reach of the web browser. Some simple examples are the user’s contacts, the photo library, voice recording, and device movement. Cocoa Touch frameworks are the only way to access this information.

As the web has matured, its applications have naturally split into two parts: The front end and the back end. Back end services manage the user’s data and are typically powered by racks of powerful servers. The front end of a web app takes this information and presents it in the browser: HTML, CSS, and JavaScript are all about user experience. In most cases, this front end is a fairly thin layer on top of the much larger back end.

With iPhone apps, this thin presentation layer is replaced. The access to REST-based APIs implemented by the back end is exactly the same. Yes, you’re duplicating the efforts of any front end development you’ve already done for the browser, but this extra effort comes with the benefits mentioned above.

In practice

There are as many approaches to development as there are apps in iTunes. Every product and the people who created it are different. That being said, the evolution of a product from the web to the iPhone typically goes something like this:

  1. Design the product. No matter what platform you’re targeting: Be it the web or a smartphone, your first step is always to think about the problem you’re trying to solve. Figure out what your users want before you get anywhere near implementation specifics.
  2. Implement the product using web standards. Use the tools that you’re most familiar with. This way, you also end up with a solution that has the widest reach and can be viewed on any platform with a standards-compliant browser. Think about using CSS and Javascript that optimizes the experience for users on mobile devices (including the iPhone, Android, and BlackBerry).

    As a starting point, check out Put Your Content in my Pocket and Put Your Content in my Pocket, Part II.

    As you implement this product, pay close attention to how the front end user interface communicates with the back end services. Try to use a REST API that third parties and eventually your own more platform-specific solutions can use.

  3. Launch the product. Get your work into the hands of users as soon as possible. As people begin to use your creation, they’ll start giving you feedback. This starts the virtuous cycle of iteration and refinement.
  4. Run into problems. Eventually, you’ll encounter situations that can’t be solved with web standards. Maybe it’s something like feature requests from users who want to upload photos or access their list of contacts. Some users will explicitly ask for an iPhone app because so many of their other favorite sites have customized solutions.

    There can also be internal pressures from your own designers and developers. They’ll find that navigation and data management are more difficult as the scope of the application increases. When you start to feel like you’re reinventing the wheel, sometimes it’s best just to use the wheel that Apple’s already built.

  5. Translate product design into an iPhone app. You’ll find that many of the decisions you made while implementing web pages were done in the name of platform neutrality. As you enter the iPhone’s platform-specific world, you’ll want to re-evaluate some decisions. Layouts and user interaction should be tailored to make them feel at home in a native app.
  6. Launch product on iTunes. After developing the app for the iPhone, you’ll now have an important new way for users to find your content or service. Which leads to the next section…

Takin’ care of business

The other attraction for developers looking at native apps is simple: There are over 100 million customers in iTunes who can buy your app with a single button tap. They can also pay for your content with the same ease. If you’re running a business, there are some distinct advantages to building apps in addition to your website.

Brand marketing

For brand marketers, the App Store is another important channel to get a product or service in front of millions of eyeballs. The big brands mentioned at the beginning of this article continue to have a strong web presence: their iPhone app supplements their position.

Many of these companies look at a native iPhone app as a cheap form of advertising: 30 seconds during primetime can cost upwards of half a million dollars. An iPhone app will cost much less and when a marketer sees their icon appear in iTunes, it’s better than Christmas morning.

Smaller developers can also use the App Store to find new audiences and fine tune the experience for current users. You’ve already done the hard work with your back end, so the effort and expenses to build a new front end are usually minimal.

Media matters

Many websites have found it difficult to charge for access to content. The root of this problem is a lack of a convenient payment mechanism for the end user. There’s also a history of free access to information on the web. As a result, many sites rely on advertising to pay the bills.

If your content contains nudity or any of the other areas that are disallowed, you’ve just wasted your time reading this article. Things aren’t all bad though, iTunes offers you a simple way to charge users for content. It can be a one-time payment via app purchase, or a recurring payment (such as a subscription) with in-app purchases. In either case, a customer only has to tap on a buy button and enter their password. Apple handles all the payment processing and accounting. You just wait for bank deposits from around the world at the end of each month.

If your content contains nudity or any of the other areas that are disallowed, you’ve just wasted your time reading this article. Things aren’t all bad though, With the recent release and popularity of the iPad, publishers both large and small are finding it profitable to repurpose content for the iPhone OS. Wired magazine’s recent debut on the App Store generated 24,000 sales in the first 24 hours. At five dollars a copy, it doesn’t take a financial genius to realize that there is some serious consumer demand for innovative content delivered via iTunes.

If your content contains nudity or any of the other areas that are disallowed, you’ve just wasted your time reading this article. Things aren’t all bad though, If you think about it a little further, it makes complete sense from a customer’s point of view. You’re used to buying music and video from iTunes. Now with iBookstore, you can get mainstream titles delivered electronically. Adding your own content to this mix makes sense for you and your customers.

Proceed with caution

If your content contains nudity or any of the other areas that are disallowed, you’ve just wasted your time reading this article. Things aren’t all bad though, Getting your content into the App Store also includes a step that you’re probably not used to in the wilds of the web: Third-party review. Anything you submit to iTunes will be checked and can be rejected at Apple’s discretion. Every app you see in iTunes has gone through this process.

If your content contains nudity or any of the other areas that are disallowed, you’ve just wasted your time reading this article. Things aren’t all bad though, The iTunes review tends to err on the side of caution: At one point political cartoons were not allowed because they ridiculed a public figure. Apple has since eased that restriction, but there are still limits that you need to be aware of. These conditions, and other nuances of iTunes, are explored further in my book.

If your content contains nudity or any of the other areas that are disallowed, you’ve just wasted your time reading this article. Things aren’t all bad though, because you can still use Safari to circumvent the entire curatorial process.

by

Lessons from mobile web design

, , , , ,

Mobile development is all the rage, and the interactive industry is in great turmoil as countless tablets and smartphones come to market.

Mobile app development gets most of the attention, while the mobile web somewhat quietly creeps along. But the mobile web is making progress every day as more and more developers launch mobile-optimized interfaces.

The great thing about the mobile web is that it is fundamentally built with all of the same tools used in traditional web design and development.

This makes it far more approachable than app development. Also, many users will want to visit a company’s website on the go, without necessarily needing a full-blown app.

Building websites optimized for mobile is so similar yet so different then designing for the desktop. Certain factors take on a far more significant role. For example, screen size variations, user attention spans and usability issues are more critical then ever.

These same issues are ever present on the desktop but are sometimes easier to overlook. Here we’ll look at some lessons to learn from the optimization that is happening on the mobile web. The lessons can directly inform how we design and how we think about traditional web design and website architecture.

 

Simplified navigation on mobile websites

One of the first things that becomes evident when digging into mobile websites is the extreme simplification of the navigation. Navigation not only becomes very prominent and central on a mobile website, but is also quite often trimmed down substantially to focus on only the most critical elements.

I find it amazing how top-level navigation can be boiled down to two to four items on most mobile websites. Of course, I recognize that the content on a mobile website is quite often optimized for the intended audience. For example, Truth Tabernacle Church has six options in its main navigation, only one of which has made it into the navigation for the mobile version; and the one that made it (“Contact”) is the focus of the entire home page.

The content that didn’t make it into the mobile version is, of course, still entirely relevant. The mobile interface is intended to catch people trying to find the church or check out the service times or simply contact them. These are the most likely objectives of the mobile surfer. Those hitting the full website on a desktop computer are as likely to want those things as they are to want to research the church to see whether it is the sort of place they would like to visit.

So, what is the lesson to learn? Don’t these two interfaces target totally different audiences and have totally different purposes? Perhaps, but we can learn a lot from the extreme focus of the mobile interface. Notice how everything is about the actions you can take? The church has eliminated all of the navigation elements that feel like boxes to check off.

One interesting element is the “About” navigation option on the full website. The mobile website may be optimized for people on the go, but there is no reason to assume that they wouldn’t be interested in reading about the church and its beliefs. Someone may have mentioned the church to you in passing, prompting you to look it up on your phone.

So, the navigation option for this element should be changed. What if, instead, it communicated something like, “What you should know about us”? While a bit long, it reflects a more helpful attitude. A general “About” bucket feels like a place to hold all of the information that no one reads. “A visitor’s guide to our church” feels a lot more useful and targeted.

The simplicity and focus of the mobile interface shows that everything must have a purpose to earn a slot on the website. If the same were true of the full website, we would be less inclined to fill it with seemingly important content and more inclined to make sure everything has a clear function.

This reflects a very task-oriented mentality. Every option challenges the user to take some active step. It is as though every passive option has been purged and reduced to actionable items on the mobile website. This leads us to the next lesson: be extremely task-oriented.

 

Mobile websites are task-oriented

With a task-oriented mindset, let’s reconsider the full website. While the home page is beautifully designed, the call to action is far less evident. The content is full of bits of information waiting for you to decide to be interested.

For example, the large banner highlighting a coming event fails to call me to some kind of action; very passive. With a task-oriented mentality, we could vastly improve on the “Read more” call to action. This could be as simple as making the call to action much more prominent; for example, a large button in a contrasting orange. Additionally, the call could be changed to “Learn more and sign up.”

Another example is the welcome message. I appreciate the intention and the message being communicated here. The message shows that real people are behind the website, and it attempts to make the page feel personal. But again, let’s dissect this with a task-oriented mentality. A great follow-up to an introduction like this would be a clear call to action encouraging visitors to take the next step. After all, the only people who will be reading this are newcomers. Current members will skip right past this to things like the event calendar. So, offer a conversion point for users, like “Ask us a hard question” or “What to expect when you visit.”

By contrast, the “Special guest” box is fantastic. It addresses key issues and drives people to dig deeper. I only wonder whether it could be a more prominent element of the page. Again, members will get to where they need to go; so focusing on those who are new to the website and the church would go a long way to maximizing the opportunity.

I know I am really beating this website up, but it is not because I dislike it or think that it doesn’t serve its function. My goal is only to challenge our thinking and our preconceived notions of what a website should look like and do. I actually commend this church for having a beautiful and functional website, with a mobile extension to boot!

 

Mobile websites dramatically shrink their content

Another obvious lesson related to paring down the navigation is that mobile websites invariably shrink their content. Not only are the number of options reduced to the core functionality and purpose of the website, but the copy is vastly reduced, too.

In some cases, much of the copy is eliminated entirely! This begs the question, is this content necessary on the full website if the mobile version functions well without it? Divi Aruba is a great example of this. The alluring marketing speak laid overtop the photo might seem like a must-have element for the home page, but it has been nuked on the micro mobile website.

On the mobile version, the logo is placed on top of the same image, and yet it still conveys the exact same message: if you want to go some place like this, read on. Why not use this prominent spot to drive people to the desired action? Surely the designers know what is the most critical element for converting visitors to customers. Put this information to work, and drive people there with a prominent call to action instead of fluffy marketing speak.

 

All the good stuff, sans fluff

This leads us to the next lesson: lose the fluff. The next example is a positive demonstration of this. Travel Tex is a travel information website for the state of Texas. It has a clear purpose and audience in mind. Fortunately, the designers have fully embraced the fluffy-less mindset.

Not only does the mini mobile website focus entirely on the topic at hand and the key actionable items, but so does the full website! What a relief to see almost no fluff at all. Including something dreary like a history of Texas would be all too tempting. If people wanted a history lesson, they wouldn’t come this website. You will be hard pressed to find content that is not relevant to this website’s singular purpose.

Get into the habit of questioning everything. This is the only way to really boil a website down to its critical elements, which is exactly what happens on a good mobile website. Tough choices are made and otherwise valuable content is cut in order to streamline the website. Call fluff for what it is and nuke it!

 

Branding is king on the mobile web

I am all about creativity on the web. In fact, many of the greatest changes in the industry have come about as a result of a refusal to stick to the status quo. But there is a time and place for everything. So many designers use their assignments as an excuse to release their creative juices, for no other purpose than to do something creative. This turns the website into a design for the designer, not for the client and their needs. This is one thing the mobile web warns against rather boldly.

Branding is incredibly consistent on the mobile web, and one of the most consistent parts is the placement of the logo. On mobile websites, you won’t find any crazy logos at the bottom with fixed footers. Functionality is king, and logos always appear at the top. Can you imagine hitting a mobile website and not seeing the logo right away? Yet this is commonplace on many full websites.

Here are a few websites that, while minimal and lacking in mind-blowing style, are rich in branding that can’t be missed.

The lesson here can have a profound impact on how you approach your work and on the fundamental value you pose to your clients. For every designer who figures out that the client’s needs should be their entire purpose for the project, there is another who wants to show the world how creative and original they are.

Like anyone else involved in the production of a website, the web designer should be single-minded in serving the client, helping their business and improving the bottom line. With every element you put on a mobile website, considers its role and the benefit it will bring. Apply this mentality to everything you do, and you will soon find a strong ally in your client.

The more we embrace the needs of the client and do everything we can to bring value to their website, the more we will see a fundamental shift in our work. We will go from building “cool stuff” to looking at everything from the client’s perspective. Does this feature stand to increase their profit? How can the design be changed to improve their business? If a byproduct of your work is more money for the client, then you will find opportunity everywhere.

 

Websites without the gimmicks

One of the greatest achievements of the mobile web is the total lack of gimmicks. To be fair, there is a time and place for gimmicks on the web. In fact, I dedicate whole sections of my books to them. But the lack of gimmicks on mobile websites demonstrates that these seemingly great ideas serve no real purpose.

Everything that goes on a mobile website should go through several filters. Is the content relevant and utterly useful? Is the content critical, and does it serve the core purpose of the website? Is the website easy to use and understand? Is the navigation unconventional? If so, is it critical to the function of the website? The answer may well be yes, but more often than not, it will be a decisive no.

Some gimmicks that are noticeably absent from mobile development are splash screens, unusual navigation, meaningless animations and interactivity, inline scrolling regions, odd layouts and fixed-width layouts. The efficiency of the mobile web is amazing.

 

Conclusion

As you can see, we have a number of lessons to learn from the mobile web; particularly, its ability to reveal unnecessary elements of a website. As with many things in life, a slight change in perspective often opens our eyes to the true value of things we have long taken for granted.

I am not suggesting that we have lost sight of the purpose of the web. Rather, I am proposing that we adopt a far more strategic mentality.

by