dotmobi Switch On! Web Browsing Guide

Version 0.5
Revision 3
Status Consultative
Date 3-Feb-2006
Editors Ronan Cremin
Jo Rabin

1. Document Information

1.1 Status

This document has the status "Consultative". This means that its mandatory provisions are not in force. The document will be updated to "Current" status at which point its mandatory provisions will be enforced. The lifecycle of the dotmobi Switch On! Guide is discussed in [Lifecycle]

1.2 Time Limits

There are no time limits associated with compliance to this document.

1.3 Document History

This is the first public draft of this document. The document will be updated from time to time. Dotmobi registrars will be notified when the document is updated.

The latest version of this document is available at: http://mtld.mobi/

This version can be found at http://mtld.mobi/

1.4 Acknowledgements

Parts of this document are derived from W3C Mobile Web Best Practices, W3C Working Draft, [MWBP], © 2005 World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University). All Rights Reserved.

1.5 References

MWBP
W3C Mobile Web Best Practices http://www.w3.org/TR/mobile-bp/
Lifecycle
dotmobi Switch On! Guide Lifecycle http://mtld.mobi/
CCTLD
IANA list of CCTLDs http://www.iana.org/cctld/cctld-whois.htm

1.6 Copyright

This document contains information proprietary to Mobile Top Level Domain Limited ("mTLD" or "dotmobi"). You may not modify, copy, reproduce, republish, upload, post, transmit, or distribute in any way any material from this document including code and software without the express, written consent of mTLD.

This document as a whole is copyrighted as a collective work, and individual works appearing on or accessible through this document are likewise subject to copyright protection. You agree to honor the copyrights in this document (including the selection, coordination and arrangement of the contents of this document) and in the works available on or through this document. In addition, trademarks and tradedress belonging to us or to third parties appear on this site or are accessible through this site. The fact that we have permitted you access to this site does not constitute authorization to reproduce such trademarks for any other purpose.

Copyright © 2005 - 2006 Mobile Top Level Domain Limited

2. Overview

2.1 Purpose of Switch On! Guides

Dotmobi Switch On! Guides are a set of guides governing certain technical protocols and services in the ".mobi" (dotmobi) domain. These guides are a combination of mandatory rules and optional best practices that, when applied to content and services associated with the domain, ensure a good user experience for users interacting with the domain and its services via a mobile device. The rules mentioned in Switch On! Guide documents are specifically designed to be:

Dotmobi Switch On! Guides are primarily oriented at domain registrants, since registrants are the owner of and content and services hosted at any domain, but are also useful for tool vendors and solution providers whose products and services may be involved with dotmobi.

2.2 Mandatory Rules Audit, Notification & Enforcement Process

Dotmobi domain name registrants agree to implement the mandatory registrant rules listed in this document whenever they publish a web site linked to a dotmobi name on the internet. It is strongly recommended that registrants also ensure that their applications also comply with the Highly Recommended Best Practices to improve the end-user experience.

mTLD will audit all dotmobi domains for compliance to the mandatory rules. mTLD will audit these domains in whatever way or frequency decided by mTLD to be practical and reasonable. When a web site using a dotmobi name is not compliant with the mandatory rules, an exception report for the dotmobi name will be created by mTLD.

Dotmobi names not in compliance with mandatory rules will have 60 days to become compliant. mTLD shall send two notices to the registrant's registrar asking the registrar to contact the offending registrant with the exception report. The registrar will be required to provide a 60 day, then a 30 day notice of this non-compliance. If a name is not in compliance with 15 days left to go, then mTLD may chose to contact the registrant directly after making best efforts to make contact through their registrar.

Dotmobi names that are not brought back into compliance shall be removed from the zone file for resolution on the internet. The dotmobi names shall not be deleted from the registration system, but their name will be placed on hold until they are in compliance with the mandatory rules.

2.3 Registrar's Obligations

Registrars are obliged to make registrants aware of all Switch On! Guides associated with the dotmobi domain in advance of any registration taking place. Registrars must either make a copy of these documents available to the registrant or point them to the authoritative versions on the mtld.mobi web site.

3. Introduction to Switch On! Web Browsing Guide

3.1 Scope

The dotmobi domain is intended as a sign to users that web sites within the domain are especially suitable for use on mobile devices. Registrants are expected to make sure that their dotmobi web site works well with mobile devices. Following the guidelines in this document will assist them in doing this.

This document is the authoritative source of rules governing web content served from a dotmobi domain. It also acts as a guide for web site developers and solution providers whose tools and services are used in this the dotmobi domain, or to produce content for a site in this domain. These rules are designed to ensure a good user experience for users browsing these web sites from mobile devices.

3.2 Use Cases Covered

The Switch On! Web Browsing Guide covers the use case of browsing a dotmobi application/web site from a mobile phone, PDA or other hand-held device. This guide specifically does not cover use cases involving desktop PCs or other device types, nor does it cover other Internet-based applications such as email or instant messaging.

3.3 Relationship to Other Standards

The best practice recommendations in this document are primarily based upon the W3C Mobile Web Best Practices [MWBP]. In addition a number of dotmobi specific rules and best practices are introduced.

3.4 Structure of the Best Practices

Dotmobi-specific best practices are identified as follows:

[dotmobi] The text of a dotmobi rule or best practice

W3C-derived best practice statements are identified as follows:

[W3C EXAMPLE] The text of a W3C Best Practice

For each W3C statement a link is provided to the corresponding W3C best practice statement. Readers can follow these links for further discussion on the meaning of the statement and how to test compliance.

The rules and best practices are classified into the following sections:

4. Registrant Rules

4.1 Mandatory Registrant Rules

4.1.1 XHTML Mobile Profile

[dotmobi] When a dotmobi web site is accessed using a URI consisting only of the second-level domain name or second and third level domain name (e.g. example.mobi, www.example.mobi, de.example.mobi) the response must be encoded in XHTML-MP unless the device accessing it is known to support an alternative choice of markup.

If the site provides its home page by redirection then all intermediate pages that are delivered in the course of the redirection must comply with this rule.

What it Means

It is not the intention to restrict the uses that dotmobi registrants put their site to. However, in order to contribute to the overall usability and premium user experience of the dotmobi domain it is important that visitors to sites have the best possible experience of them, even if their devices do not support the formats that registrants wish to support. Consequently, at a minimum, visitors to dotmobi sites must receive a message that is displayable by their browser, directing them to a portion of the site that is accessible to them, or identifying the type of device that is necessary to experience the site properly.

Some web sites will adapt their content dynamically to accommodate the type of browser and formats supported by that browser. In this case the site should generate a page formatted in valid XHTML-MP if, following consultation of its list of device types or formats, it cannot find a match for the device in question. The user in this case stands a very good chance of receiving a page that their device can display. The content of the page is at the site owner's discretion, and may be a message allowing the user to select a particular type of experience, or may be a message detailing the types of device required to access the service. Site owners are encouraged to support the widest possible range of devices.

In cases where the site infrastructure does not provide the ability to detect the browser type or formats that are acceptable there must be a page at the domain root that is delivered in XHTML-MP. This does not mean that the rest of the site has to be formatted in XHTML-MP. Sites that cater specifically for some other format may have their entry point identified by a path e.g. a site that is specifically targeted at WML devices only could have its home page at example.mobi/wml.

The preferred method of redirection is by using HTTP 3XX codes (see below).

4.1.2 Second-Level Domain Site

[dotmobi] Sites must implement a page at the second level domain i.e. a web server must respond to HTTP requests to example.mobi (if necessary in addition to www.example.mobi.)

What it Means

Research has shown that typing in URLs on a mobile phone is a significant barrier to entry for users using mobile devices. Entering the repeated "www" text is particularly troublesome on a mobile phone with a numeric keypad.

4.1.3 Use of Frames

[dotmobi] Do not use frames under any circumstances. i.e. in HTML, XHTML or other mark-up languages that support similar constructs, frames must not be present. [See also W3C NO_FRAMES]

4.2 Highly Recommended Best Practices

4.2.1 URIs for Country Specific Sites

[dotmobi] Identify national variations of dotmobi sites by using the corresponding country code top level domain identifier (ccTLD) as the third level domain identifier.

What it means

Companies often wish to offer web sites that are tailored to a specific country. For example, the company Example Inc. may wish to offer different experiences in Japan, the US and in Germany. Example Inc. should distinguish these sites by using jp.example.mobi, us.example.mobi and de.example.mobi to identify them.

The authoritative list of ccTLDs can be found at [CCTLD]. Note that this list, while similar to the ISO 3166-1-alpha-2 code list is not exactly the same as that list.

4.2.2 General Best Practice

[W3C CONTEXT] Take all reasonable steps to find out about the device/browser (client) capabilities, adaptation and other transformation that takes place for any instance of an access to a resource.

[W3C CAPABILITIES] Exploit device capabilities. Do not take a least common denominator approach.

[W3C DEFICIENCIES] Take reasonable steps to work around deficient implementations.

[W3C TESTING] Carry out testing on actual devices as well as emulators.

4.2.3 Navigation

[W3C URIS] Keep the URIs of site entry points short.

[W3C NAVBAR] Provide minimal navigation at the top of the page.

[W3C BALANCE] Design the service with a broadly balanced navigation tree where numbers of links on pages is balanced against depth of navigation.

[W3C NAVIGATION] Use navigation mechanisms in a consistent manner.

[W3C ACCESS_KEYS] Assign access keys to links in navigational menus and frequently accessed functionality.

[W3C LINK_TARGET_ID] Clearly identify the target of each link. Use clear, concise, descriptive link text to help users decide whether to follow a link. Identify the implications of following a link if the target is notably large and the user might not anticipate this from the context.

[W3C LINK_TARGET_FORMAT] Note the target file's format unless you know the device supports it.

[W3C IMAGE_MAPS] Do not use image maps unless you know the target client supports them and has sufficient screen area and an appropriate means of selection, such as a stylus or navigation keys. When using image maps under these circumstances, use client side image maps unless the regions required cannot be described with an available geometric shape.

[W3C SERVER_SIDE_IMAGE_MAPS] Do not use a server side image map unless you know that the client provides a means of selection within the image map.

[W3C POP_UPS] Do not cause pop-ups or other windows to appear and do not change the current window without informing the user.

[W3C AUTO_REFRESH] Do not create periodically auto-refreshing pages, unless you have informed the user and provided a means of stopping it.

[W3C REDIRECTION] Do not use markup to redirect pages automatically. Instead, configure the server to perform redirects by means of HTTP 3XX codes.

4.2.4 Page Content and Layout

[W3C LIMITED] Limit content to what the user has requested.

[W3C PAGE_SIZE_USABLE] Divide pages into usable but limited size portions.

[W3C PAGE_SIZE_LIMIT] Ensure that the overall size of page is appropriate to bandwidth, the memory limitations of the device and other device and delivery channel characteristics if they can be determined.

[W3C SCROLLING] Limit scrolling to one direction, unless secondary scrolling cannot be avoided.

[W3C SCROLLING_LIMIT] Limit secondary scrolling to objects that require it, where it cannot be avoided.

[W3C GRAPHICS_FOR_SPACING] Do not use graphics for spacing.

[W3C LARGE_GRAPHICS] Do not use images that cannot be rendered by the device. Avoid large or high resolution images except where critical information would otherwise be lost.

[W3C USE_OF_COLOR] Ensure that information conveyed with color is also available without color.

4.2.5 Page Definition

[W3C PAGE_TITLE] Provide a short but descriptive page title.

[W3C STRUCTURE] Ensure that perceivable structures within the content can be programmatically determined.

[W3C TABLES_SUPPORT] Do not use tables unless the client is known to support them. Do not use multi-layer tables.

[W3C TABLES_LAYOUT] Do not use tables for layout.

[W3C TABLES_ALTERNATIVES] Where possible, use an alternative to tabular presentation.

[W3C NON-TEXT_ALTERNATIVES] Provide textual alternatives for non-text elements.

[W3C OBJECTS_OR_SCRIPT] Do not embed objects or script in pages unless you know the device supports them.

[W3C IMAGES_SPECIFY_SIZE] Always specify the size of images in markup.

[W3C IMAGES_RESIZING] Resize images at the server.

[W3C VALID_MARKUP] Create documents that validate to published formal grammars.

[W3C STYLE_SHEETS_USE] Use style sheets to control layout and presentation, unless the device is known not to support them.

[W3C STYLE_SHEETS_SUPPORT] Organize documents so that they may be read without style sheets.

[W3C STYLE_SHEETS_SIZE] Keep style sheets as small as possible.

[W3C MINIMIZE] Use terse efficient markup.

[W3C CONTENT_FORMAT_SUPPORT] Send content in a format that is known to be supported by the device.

[W3C CONTENT_FORMAT_PREFERRED] Where possible send content in a client's preferred format.

[W3C CHARACTER_ENCODING_SUPPORT] Ensure that content is encoded using a character encoding that is known to be supported by the target device.

[W3C CHARACTER_ENCODING_USE] Indicate in the response the character encoding being used.

[W3C ERROR_MESSAGES] Provide informative error messages, and a means of navigating away from an error message back to useful information.

[W3C COOKIES] Do not use cookies unless you know the device supports them.

[W3C CACHING] Attach caching information to the content.

[W3C AVOID_FREE_TEXT] Avoid free text entry where possible.

[W3C DEFAULT_INPUT_MODE] Specify a default text entry mode, language and/or input format, if the target device is known to support it.

[W3C TAB_ORDER] Create a logical tab order through links, form controls and objects.

[W3C CONTROL_LABELLING] Label all controls appropriately. Explicitly associate labels with controls where the device supports this. Position labels relative to controls appropriately.

4.3 Other Best Practices

[W3C THEMATIC_CONSISTENCY] Ensure that links provide a thematically coherent experience when accessed from a device other than the one on which they were captured.

[W3C SUITABLE] Ensure that content is suitable for use in a mobile context.

[W3C CLARITY] Use clear and simple language.

[W3C CENTRAL_MEANING] Ensure that material that is central to the meaning of the page precedes material that is not.

[W3C COLOR_CONTRAST] Ensure that foreground and background color combinations provide sufficient contrast.

[W3C BACKGROUND_IMAGE_READABILITY] When using background images make sure that content remains readable on the device.

[W3C MEASURES] Do not use pixel measures and do not use absolute units in markup language attribute values and style sheet property values.

[W3C MINIMIZE_KEYSTROKES] Keep the number of keystrokes to a minimum.

[W3C PROVIDE_DEFAULTS] Provide pre-selected default values where possible.

Valid XHTML 1.0 Transitional