Mobile Publishing

Publishing is probably the most complicated element of the Mobile Web. People from the desktop Web development community need to adjust their view when developing for the Mobile Web. Luckily, publishing to the Mobile Web does not have to be complicated. There is plenty of room in-between the simple and the complex for any developer and any project to find a home.

While it is easy to segue into the inner workings of device detection of the differences in browser rendering, in this section we focus on establishing a reasonable development baseline and easy ways to begin mobile publishing.

Supporting Devices & Browsers

Supporting devices and browsers can be difficult and time consuming Every year, the industry sells hundreds of different mobile device types/variants worldwide. Mobile service providers often customize mobile browsers on their devices, creating a large number of different deployed browsers. As a rough guide, every major browser version has a lifetime of approximately 50 different device models, with various minor revisions. Since most devices don’t allow over-the-air updates, faulty devices can’t receive regular upgrades leading companies to pull them from the market and replace them with a new version. This typically includes a revised version of the browser, perhaps exacerbating the problem.

Most mobile service providers recommend supporting devices for two years, a difficult task.

Simplifying Device Support

Supporting devices and browsers is a major concern for many developers from the Web community accustomed to dealing with differences in multiple Web browsers.

While supporting multiple mobile devices and browsers gets complex, the situation is not as bad as many believe. This belief comes from looking at the mobile browser landscape in the same way as desktop Web browser landscape.

Consider the following points:

  • Only Mobile Web sites that are part of a mobile service provider portal must support all provisioned devices and browsers. Mobile Web sites outside of mobile service provider portals can support whatever devices and browsers the publisher wishes.
  • Working to the capabilities of the W3C Default Delivery Context should ensure that a site will work with most existing browsers but remember that a better experience can be provided by recognizing the device and using its capabilities.
  • Depending on your target audience and locale, older or poorly designed devices may not need to be supported. Drawing a line with device and browser support is relatively easy because those with older or poor quality devices typically don’t use the Mobile Web. You can verify this by reviewing common user agents recorded in your Web server’s access logs.

One way to approach this problem is to focus on five classes of devices that span a range of capabilities. Of the hundreds of devices available, supporting five mainstream devices makes a great place to start. Obviously supporting more devices ensures greater compatibility with more devices and developers should always endeavor to do this, but supporting five devices disparate devices can do the job.

Here is an example:

  • A Nokia Series 40
  • A Motorola V series, (v3 aka RAZR, v600, v500, etc.)
  • A modern Samsung and/or LG device
  • A Smart Phone, like Nokia s60 (or Series 60)
  • A PDA, like a Treo or Windows Mobile device

 

Site Naming

Mobile pages are just Web pages published to any Web server. Nevertheless, it can be problem a problem getting mobile users enter the URL for your site.

The following options are some of the ways getting users to access a Mobile Web site:

  • Use the mobile-specific .mobi top-level domain (instead of .com, .net or .org) to indicate that your site is mobile friendly.
  • If you do not have a dotMobi domain, you may try to educate the user to enter a mobile-friendly URI e.g. example.com/mobile or mobile.example.com.
  • Detect the mobile device automatically and redirect the user to a mobile-friendly location. In this case, the user simply enters domain.com. In this case ensure that you provide an option for the user to browse the PC version of the site – many users have advanced mobile devices may choose to access the richer version of the site

For more information on how to structure your site, when to redirect the user to a separate mobile-only only site, see Chapter 9. Going further with Adaptation

dotMobi

The .mobi top-level domain is the ICANN approved top-level domain specifically for mobile devices giving publishers the option to use an alternate domain for their mobile site. Instead of using device detection, sub-domains or directors, mobile users go to example.mobi. Much like the sub-domain approach, dotMobi sites sometimes use a separate server or virtual host, separating desktop sites from mobile sites on the same server.

If you own a dotMobi domain, you can route all traffic to it using device detection or server redirects.

Server Directory

You can publish Web sites written in XHTML Basic to most Web servers without re-configuring the server.  This publishing approach works in shared hosting environments, and it’s compatible with most content management systems that can publish alternate templates.

Sub-domains

The sub-domains approach to publishing, similar to server directories, lets you publish a mobile site to a location on your server, mobile.example.mobi, wap.example.mobi or m.example.mobi, for instance.

Since most servers treat sub-domains as separate Web sites with a unique root directory and server directives, this approach is convenient for your Mobile Web site because it keeps desktop and Mobile Web sites separated.

It’s possible to redirect traffic from a server directory to sub-domains to give the user easier access while taking advantage of separated environments. For example, entering example.mobi/mobile redirects the user to example.domain.mobi

Configuring Server MIME Types

The Internet Media Type – better known as MIME type – is an Internet standard for indicating the format of a message. It is used extensively in many Internet protocols. In the context of the Web in particular, it’s used as part of the HTTP protocol to help the browser understand how to parse and render content that it receives.

For each request made from a browser to a Web server, HTTP requires that the server includes a Content-Type header identifying the format of the response. Upon receiving this Content-Type header, the browser can decide how to decode the response and render it in an appropriate form.

In the mobile context, the server sends MIME types to the mobile browser. Many Web servers, by default, do not have the correct MIME types defined for mobile markup standards. It is important set up the Web server to serve the right Content-Type headers for mobile markup languages. At best this may cause the browser to render the page more slowly; at worst your pages may be unreadable or result the mobile device to produce an error message.

Use the value

application/xhtml+xml

for all recommended mobile content types (XHTML-MP and XHTML Basic).

Testing

Testing is an vital component of mobile publishing. Mobile testing is a big job considering the many devices and the differences in how content renders on the device. Fortunately, simple testing methods exist for testing your mobile Web site.

One tip before beginning: Create a simple page on the development server containing links to the URLs for the sites you plan to test. Bookmark this site on each device used in the test. This way you avoid having entering URLs into the devices many times over.

Desktop Testing

You can – and it’s recommended – test your markup and stylesheets on a desktop browser before trying it on a device. Though desktop browsers have better CSS support, you can confirm the basic markup and stylesheets. Doing testing on the desktop comes in handy in finding errors quickly and easily compared with searching for errors on the device.

Opera

The Opera desktop browser has a small screen view that mimics a mobile screen when loading a mobile stylesheet or condenses the page. Be aware that Opera’s small screen view is a little wider than mainstream mobile devices.

Frames

Another way to test on the desktop is to create a Web page with an inline frameset or iframe, specify the dimensions to match your target mobile screen and add the URL of your mobile site like the following example:
<iframe src ="mobile/index.html" width="240" height="320" style="border:1px solid;"> </iframe>These steps create a reasonable representation of a mobile device on the desktop. You can even go as far as to wrap the frame with an image of a phone for further realism.

Firefox

When using advanced device detection methods, Firefox – with help from the User Agent Switcher extension – lets you change the User Agent HTTP header you send to the server. Once you add the data from the supported mobile user agents, you can test how each of your sites displays.

Other helpful all-purpose extensions for Firefox are the Web Developers Toolbar and Firebug (which provides very useful XHTML and CSS debugging).

Emulator Testing

Another method of testing a mobile site is to use a phone emulator. This is typically a desktop or Web-hosted application that mimics the device experience for a particular device or class of devices. The accuracy of phone and browser emulators vary from a perfect mimicking of the browser rendering to rough approximations.

While an emulator does not replace testing on an actual device, they are a very useful tool during development to do quick verification of how your code displays without loading it on a real mobile browser. Note that regardless of how perfectly a browser mimics the rendering of page on a real device, they can’t reproduce the overall experience of using a real device, since factors such as network speed and latency are involved. For this reason, emulators are a very useful step in any testing program, but should never be used to replace real device testing.

Device Testing

While getting access to devices, networks and the right data plans is a challenge, the outcome is worth the struggle.

Other methods of testing are very useful, but nothing represents the final experience better than testing on a real mobile device during the development process, since this best recreates how the user will interact with your site.

If you have only one device, borrow phones from friends and family. Talk to vendors that may let you rent phones or use their device lab. If you don’t have access to a vendor in your area, try going to a mobile service provider store and use the display phones for testing.

Prepaid SIM cards from multiple mobile service provider networks can be a developer’s best friend. Switching prepaid SIMs allows you to test on multiple devices across multiple n

Remote Access

Remote access services let you control an actual device remotely through your desktop. DeviceAnywhere is one of the few examples of such a service. The application taps into the actual device, which you rent through the company’s software. It supports most of the devices sold in North America and Europe.

Remote access provides a compelling method for testing and has the added convenience of a desktop emulator as well as showing the displayed characteristics of the actual device. Although it doesn’t replace the tactile lessons learned from using the real device, it’s a solution for small publishers with limited resources. It deals with the problem of testing on many devices some of which are not supported by networks in their own countries.

Usability Testing

The recommended approach of testing Web sites with users, offers valuable insight. Testing is a process that should occur throughout the design and development process rather than being relegated to something to do upon the site’s completion. Regardless of the site’s size, verifying the discoverability, readability and usability of the site with actual users always creates a better site. This is the perfect time to quote Jared Spool’s golden rule of usability testing, “Testing with one user is better than none.”