The following text is intended for people with technical interests only.
It contains the rules that have to be obeyed when creating websites for
.mobi domains. There are three categories:
Mandatory: These rules
have to be followed.
Very recommendable: These rules
should be followed, although it is not required.
Best practice: These rules are
advisable.
It will be checked in certain cycles whether the mandatory rules
are being followed. In case of violations, a warning will be sent to the
responsible registrar via e-mail. If compliance with the rules is not
being enforced, the domain may be deactivated.
The most important rules at a glance
The following rules are important for
operators of domain name servers:
The website has to be directly accessible via the second level domain.
That saves the user some typing. Example: “http://knipp.mobi”.
The website may also be accessible on the third level.
Example: “http://www.knipp.mobi”.
Following are the most important rules for
Web designers.
To make things easier, no differentiation between the categories is made here.
All answers of the webserver have to be sent in XHTML-MP (Mobile
Profile). This is also true for redirects.
Frames may not be used.
Localized Websites: If there are different Websites for users
from different countries, the ISO-Code 3166 should be named in the third level of the URL. Example:
“de.knipp.mobi”, “eu.knipp.mobi” oder “us.knipp.mobi”.
The URLs of the entry page should be short.
Image-Maps shall not be used, except the client supports them
(pre-check).
Pop-up windows shall not be used.
Cyclic autorefresh shall be avoided. Exception: If a means of
stopping (e.g. a button) is provided.
Pages shall have a “usable” size. If scrolling should be necessary
only scroll in one direction (X- or Y-coordinates).
Typographical layout (e.g. spacing) shall not be achieved via
graphics.
Tables should be avoided, except the client supports them
(pre-check).
When using pictures, the size shall always be provided
(img-Tag).
Style-Sheets may be used, but the pages should also be
displayed reasonably without them.
Cookies should be avoided, except the client supports them
(pre-check).
Coloring, especially that of foreground and background, should be
rich in contrast.
Pixel or absolute sizes should never be used as measuring units.
The following section contains the original text of the style 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.
IANA list of CCTLDs http://www.iana.org/cctld/cctldwhois.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 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:
Useful
Achievable
Measurable
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.
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:
Mandatory Rules
High Recommended Best Practices
Other Best Practices
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 autorefreshing
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.
