As an attentive and responsive web master, you follow your website statistics carefully. In your case, the numbers show remarkable changes in the past few years or even months. You see newer agents, such as Symbian and Android, and this ties in with the amazing growth of sales and use of mobile devices compared to stationary desktops. You project that this seismic shift will continue into the future as the sales of intermediate devices such as tablets increase.

In addition, you subscribe to the view that sales and marketing are not entirely the same thing. So, your website is both a sales tool and a marketing agent. For sales, it describes in great detail your products and services and invites orders; as a marketing tool, it has encouraged duplex communication between you and the client and educated you about your customer base and its changing needs. Now, you sense that the efficiency of your online tools is falling. You begin to receive feedback from mobile users that they cannot view some parts of your site while riding to work on the bus. The reality is that because devices are overwhelmingly visually oriented, large and small screens provide different services. Large screens are better at providing sales information because they have the ability to show visuals and interrelationships. Small screens are more efficient in a marketing context, with short and snappy interactions using different media. Tablets are the ideal location for ePub and PDF documents.

You are anxious to adapt to this new reality, but you are not sure what to do. When setting up the site in a purely desktop and notebook world, you found that many clever tools separated you from exposure to HTML and JavaScript. Your knowledge of HTML disappeared because of lack of use. So, you are now tied to the offerings of a content management system (CMS) or a full-blown website design application that has, until now, done a remarkably good job.

Immediate short-term patch

In the short term, if you're in a large corporation, you just buy one of each of the new devices, assign a programmer to make sure the site works on the device or make recommendations, and job done. And some CMS providers are gearing up to refine their concept of separation of data from the actual presentation to deal with mobile devices, although the small screen is obliged to present the information in a manner dictated by its big brother, the desktop.

Back to top

The longer-term view

Dealing with visits from a wide variety of devices calls for a complex and impressive desktop page and a specialized mobile page. Each page has an optional link to the other. In this way, users still have a choice and can zoom in or out on the familiar page as they like. Some sites that have already attempted to address this issue pick up on the user agent in the HTTP request and herd mobile users like sheep away from the main site into a different set of pages based on that information. They think they are being helpful, but the danger is that if users are familiar with your main site and you offer them a different experience on the mobile, you risk alienating them when they don't find what they need and they don't have the option to view what they know exists.

Back to top

Planning and implementation

Here are some short points to bear in mind while building pages to be viewed on both types of devices:

• General setup:
  • Choose between (X)HTML and Wireless Markup Language (WML) for the mobile pages. Although mobile browsers can handle general HTML varieties, WML is generally specific to mobile devices. For pages to be displayed on both desktop and mobile devices, use XHTML Basic 1.1 Doctype.
  • Where should the mobile page live in the directory structure? Should it be in its own folder and its own subdomain? One advantage of placing *.wml pages in their own directory is that you can then use a server directive that changes the default page and extension for that directory. If the .htaccess file contains the line DirectoryIndex index.wml, if readers request the directory, they are automatically fed the index.wml file instead of the directory contents, even if the main domain serves PHP and HTML files by default.
  • Although ideally, each platform should have code written for it, each should keep the other in mind. Large displays can lean toward small by avoiding large images and complex JavaScript and CSS files; pages for small devices that contain markup that may not make sense on a large display can be optionally hidden.
  • If the desktop page is well-formed XHTML, advanced programmers can use the structured XML as a database of information, extracting the data and building the mobile page on the fly using PHP or another scripting language on the server side.
  • If CSS is respected on a mobile device, the float style attribute in displays is useful, because it can automatically either use the width of a wide screen or line up vertically, turning the side-to-side panning into much more convenient up-and-down scrolling.
  • Use no CSS or JavaScript on a mobile page: Some of the time, it will be ignored or patchily supported. Think in terms of plain XHTML elements and attributes. Some mobile browsers will ignore common elements, so be prepared for surprises. Yes, this is bowing to the lowest common denominator, but at least you capture the entire audience. Whether you pitch your mobile website to the lowest, average, or greatest capability of a browser is a subject for your own market research.
  • Use a carefully-worded, short title element in the head section. Mobile browsers may not handle long titles well, resulting in overlapping and unreadable text.
  • Use <div> and <p> elements sparingly. They are essential for allowing validation of the XHTML, but they force blank lines, which is poor use of mobile screen real estate. Blank areas can assist with readability, but use them sparingly to reduce the need for scrolling.
  • Text needs to be short and succinct. Say what you have to say in as few words as possible. A shorter page means less scrolling. Limit images: They may not be displayed, so provide alternate text.
  • In special cases, images can provide special benefits on mobile devices. The mobile Opera browser uses the top left corner of a page as an image when it sets up shortcuts, making your page easy to find from the shortcuts array.
  • Is it better to scroll a single monolithic page or a series of pages? Your choice—it depends on the context.
• Usage:
  • Prominent in the body of any page, post a link for those who arrive at this page but really need the alternative version despite the difficulties they might encounter. The link needs to be in the first pageful of information that the mobile browser retrieves. It is frustrating to have to scroll all the way to the bottom of a long desktop page just to find the link to the mobile page. Minimize the link on the big page with a style attribute, because the desktop browser can handle the CSS, but if the reader is viewing your page from a mobile device that ignores CSS, it will helpfully appear full size.
  • URLs that the user must type, that are long, or that contain non-alphabetic characters may be an issue if a mobile user has a limited keyboard. It's also inconvenient to shift from alpha to numeric or special characters and back.
  • Use columns effectively. One excellent experience browsing a desktop page on a small screen is to find that panning horizontally across the page brackets a column that is a sub-portion of the original page, fitting neatly into the width limit of the small screen. Up and down scrolling without panning offers an acceptable reading experience.
  • When presenting charts, use right-hand axis labels or limit the width. Wider charts that oblige the user to pan right to view the latest data may leave the axis labels hidden, requiring left and right panning.
  • Provide content that is relevant in a mobile environment, such as clickable links to other mobile-aware sites or telephone protocols (Wireless Telephony Application Interface, tel) that initiate an interaction with the phone to make a call or send SMS. Use bar codes.
• Validation and emulation
  • It is important to validate. Mobile browsers are less forgiving than desktop browsers. The W3C provides a cool validator for mobile contexts: See Resources for a link.
  • Many online emulators are available that give programmers an idea of what their page will look like on a particular device. Emulators show what you would get, rather than the validator, which would list what might not be displayable. Emulation might be justified if your statistics point to high use of one special device. See Resources for a link to the Android Emulator, for example.

Listing 1 shows a simple page that could be displayed on a wide variety of devices. It incorporates many of the suggestions from the list of suggestions, and might provide an acceptable user experience on any device which has at least a rudimentary HTML browser. You can use the basic HTML parts of the list of suggestions, but the WML elements are definitely a hindrance to broad device acceptance. Which coding works will depend on the capacity of the browser at the user end. As noted before, sometimes you just have to pitch to the lowest common denominator.

	
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN"
    "http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Very few words</title>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8" />
</head>
<body>
  <div style="float: left">
    <p>
      <a href="..." style="font-size: 75%">Our main desktop site</a>
    </p>
  </div>
  <div>
    <p>This is an example of a very simple website.</p>
  </div>
</body>
</html> 

A compromise page such as that in Listing 1 might be fine as a trial balloon in situations where the marketing or sales role and audience is unclear. You can then modify based on usage and feedback.

Back to top

Conclusion

In the not-too-distant future, you will be able to point your smart phone at a plain white wall (or the back of the person sitting in front of you on the bus) and have it project clear content, no longer confined to the small screen. Then, this immediate problem goes away—but laws relating to trespass may have to be rewritten.

In the heyday of the complex web page development environment, the folks who pecked out their websites in plain HTML were laughed at and frowned upon by their colleagues, hampered by false superiority. No doubt the CMS providers are working hard at providing suitable alternative experiences based on their offerings. In the meantime, a simple editor and a knowledge of HTML can serve very well.

Resources

Learn

• Find out more about JavaScript support in mobile devices.
  
  
• Find out how mobile friendly your site is at the W3C mobile validator.
  
  
• Learn about CMS in a mobile context.
  
  
• Learn about Developing WML applications using PHP (Vivek Malhotra, developerWorks, March 2002).
  
  
• Learn about Deliver XHTML applications to mobile devices (Naveen Balani, developerWorks, March 2003).
  
  
• Check out Using open source software to design, develop, and deploy a collaborative Web site, Part 7: Structuring content for theming using XHTML (Alister Lewis-Bowen, Stephen Evanchik, Louis Weitzman, developerWorks, October 2006).
  
  
• Learn about XHTML: Use XML to develop Web content by the W3C (developerWorks, April 2007).
  
  
• Check out Put XHTML 2 to work now: Benefit from richer content structures even before browsers can handle the next version of XHTML (Bob DuCharme, developerWorks, June 2007).
  
  
• The Web development zone specializes in articles covering various Web-based solutions.
  
  
• Stay current with developerWorks' technical events and webcasts.
  
  
• developerWorks on-demand demos: Watch demos ranging from product installation and setup for beginners to advanced functionality for experienced developers.
  
  
• Follow developerWorks on Twitter.
  
  

Get products and technologies

• Find out more about Android Emulator.
  
  
• Learn how Joomla! CMS can handle mobile requests.
  
  

Discuss

• Create your developerWorks profile today and setup a watchlist on mobile web development. Get connected and stay connected with developerWorks community.
  
  
• Find other developerWorks members interested in web development.
  
  
• Share what you know: Join one of our developerWorks groups focused on web topics.
  
  
• Roland Barcia talks about Web 2.0 and middleware in his blog.
  
  
• Follow developerWorks' members' shared bookmarks on web topics.
  
  
• Get answers quickly: Visit the Web 2.0 Apps forum.
  
  
• Get answers quickly: Visit the Ajax forum.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Immediate short-term patch
• The longer-term view
• Planning and implementation
• Conclusion
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into Web development on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers