Building a Successful Wireless Web Site
Building a Successful Wireless Web Site
By: Joshua Fox
Mar. 14, 2001 02:26 PM
So, you've just led the successful creation of a full-featured Web site with a three-tier back end, and you've now been asked to lead the company's new wireless Web site project. You wonder how your experience will carry over from the World Wide Web (W3) to the Wireless World Wide Web (W4).
You have to hire the personnel, buy the hardware and software for the QA and integration labs, and start sketching out the high-level architecture.
Reusable components are the Holy Grail of software engineering. Ideally, you can reuse everything from your WWW site: skills, software, hardware, data, and architecture. In practice, though, wireless sites have some very different requirements, and careful selection is required to distinguish between what is reusable and what isn't.
In this article I'll review how the special technological requirements of a WAP project influence your planning and leadership. For the purposes of this article, I'll assume you're a development manager charged with developing a WAP site to complement the offerings of your existing high-end three-tier Web site. Your goal is a WAP-based thin-client application with the Wireless Application Environment on the front end and the existing database for the back end, reusing whatever you can and maintaining a good design.
Most aspects of software development management are independent of the type of software under development. If you have experience in leading projects, you're familiar with the basics of time and cost estimation and can focus on the aspects that are particular to WAP projects, including software components, employee skills, infrastructure needs, and an n-tier architecture. In this article I'll focus on the points of difference.
The tiers of an n-tier system map to your personnel: in a large site, different people will handle the layers; in a smaller site, the same person will develop several layers. For some of the tiers, the skills will be reusable. The general rule is that the closer to the back-end infrastructure, the more the existing skills can be reused.
Database skills, such as RDBMS ER models and SQL, are identical for wired and wireless systems, as are those for enterprise integration software like asynchronous messaging. Developers for the business logic tier and forward, however, need to learn the design considerations and special techniques suitable for wireless.
Dynamic content generation technologies, such as servlets, JSP, CGI, ASP, and ColdFusion, are also quite similar. More of these people will be needed for the development effort, since the W4 requires more dynamism in content generation to deal with different client capabilities. Your move from the W3 to the W4 may be the opportunity for HTML programmers to add dynamic generation technologies to their skillsets.
With the rise of the Internet, graphic artists have discovered a new niche: designing artistic Web sites. In the wireless Web, where minimalism needs to be taken to an extreme, the role of the usability expert replaces that of the graphic artist. Start looking now for one of the rare usability experts, particularly if he or she has experience and skills in the WWW; that person will prove invaluable for structuring user interfaces for ease of use with tiny screens and keypads.
What goes for graphic artists is true for writers as well: find writers who can cultivate the art of making the point in the fewest possible words.
Likewise for code: handheld devices promise to revive demand for tightly written code, a software skill that has fallen out of favor. As memories, disk space, and bandwidth have swollen and CPUs have become ever more powerful, good software practice has been to favor ease of maintenance over efficiency in code. The capabilities of handheld devices, however, resemble those of PCs 10 years ago. People who remember how to write good efficient code will prove invaluable, whether writing in C, Java, or WML/WMLScript. Some older programmers, ignored during the dot-com mania, are now finding themselves very popular again.
Recently, Jakob Nielsen's controversial study (see "WBT Resources" section), which indicated that most WAP sites are next to useless, drew attention to this problem. It set off a storm that swept as far afield as articles in popular magazines such as Newsweek. In the aftermath some commentators were already declaring WAP dead. The problem, however, is not WAP, but the application of W3 design principles to the W4. Once designers realize that they have to think differently, WAP sites - including the one you're about to develop - will come into their own. In this way, designers will relearn the lessons of the early Web, when elaborate graphics-heavy Web sites proved impractical and a cleaner style emerged.
Usability differences between the W3 and W4 start on the client side. Handheld devices have tiny screens and keyboards. Worse, their screens range from a small hi-res color screen to a few lines of black and white with low resolution. Keyboards generally lack the full 104-key complement of the typical PC. Users cannot see complex pages and cannot enter complex input. So, not only are most Web pages useless on handheld devices, but the methodology of the page designer must change completely. You must think less about flashiness than about usability, and even the text must be kept to a minimum. This approach is useful on the W3; it is an absolute necessity on the W4. For wireless devices you must present a small amount of useful information, predicting what the user is most likely to want yet still giving the user options for navigation.
Besides the user interface, networking considerations are also different in W3 and W4 clients. Wireless devices are often annoyingly slow, as a result of their limited bandwidth. Transfer rates are often under 14 Kbps, rates that are now outdated in the wired world. The bandwidth is also of lower quality, with more latency and jitter and frequent loss of signal. (In the wired world, on the other hand, most data loss is due to congestion, not link-layer point-to-point loss.)
Minimizing download size is important on the wired Web; it is vital on the wireless Web. In addition to minimizing the number of downloaded bytes, you should think about other design optimizations like merging related pages in a "deck," validating input on the client side, and matching output to client device capabilities.
The use cases for wireless require a far deeper change of approach than page design and site layout. Many WWW surfers are looking to pass the time by reading interesting text that they find serendipitously.
Wireless users, on the other hand, have one of two goals in mind: to find a specific item of useful information, or to pass the time playing with a cool new toy while waiting for something.
The first category of use cases consists of searches for specific items: a traffic report, a weather forecast, or a book to buy. Such users do not want distraction, and because of the screen and input limitations of wireless devices, you should not distract them (yes, that means you should forget about online ads). The designer needs to predict what the users are most likely to want and then let them navigate there with a minimum of keystrokes.
The second category of use cases is whiling away the hours when on the go - waiting for a plane, for example. Passing the time on handheld devices must be fundamentally different from wasting time on the World Wide Web, since it is impossible to read any significant amount of content on most small devices available for WAP. The next WAP killer app will be a game that overcomes limitations on screen size, input, and bandwidth to make use of the features of handheld devices, like the ability to communicate at any time.
Usability design is an area where you should avoid reuse. In wireless site design, reuse is the most common mistake in the industry today.
From your server out to the "cloud," however, the architecture differs somewhat between wired and wireless sites. Whereas a regular browser talks directly to your Web server over HTTP, a microbrowser on a wireless device needs a WAP gateway between it and the server. The gateway translates WSP into HTTP and may provide other services to adjust the content to the requirements of the client devices. For your development team, this means that you must develop your software not only for the wide variety of client devices and microbrowsers, but also for the different gateways on the market. Fortunately, there are fewer types of gateways in common use than there are clients.
Reusing Software Components on the Tiers
Some have hoped for 100% reuse. They thought that wireless devices could be treated as miniature PCs, and that they could surf to any HTML-based site on the WWW. In practice, though, most HTML Web sites are useless given the design constraints and use cases of wireless devices. Even with the Palm and Windows CE devices that can display HTML, the view of most Web pages is too small to be useful.
DoCoMo's highly successful i-mode is known for using HTML rather than WML. In reality, only a subset of the HTML spec known as cHTML is usable. This means that a wireless site must still be written alongside the WWW site to serve the needs of wireless devices.
Since the HTML site shouldn't be sent directly to the devices, you need to consider what layers of software can be reused. Let's start at the presentation tier and work back, seeing whether we can achieve software reuse. The general rule is that the closer the layer is to the back-data tier, the more easily it can be reused.
On the presentation tier, some software packages offer to automatically convert HTML to WML, whether in batch mode or on demand. However, it is impossible to automatically produce output of a high enough quality to be acceptable for serious WAP content providers. Automatic conversion does not handle differences in use cases between the W3 and the W4. Moreover, most modern Web sites are almost impossible to parse automatically: most HTML pages don't conform to the XML standard, and the HTML typically comes intermixed with an unholy mixture of client-side and server-side scripting in various languages, ActiveX, applets, browser-dependent DHTML, and offbeat hacks on undocumented browser features. All these make it impossible to reuse code on the presentation tier.
Significant changes are also needed on the layer of dynamic content generation. For example, your W3 site might use a separate servlet for every screen, allowing the user to step from screen to screen through choices on the Web page. In this case, one servlet in a W4 site can serve the role of many in a W3 site, since, in WML, a number of cards (pages) are sent at once in a deck. You may further reduce the number of servlets in a W4 site by switching from server-side input validation to client-side validation using WML and WMLScript. On the other hand, the role of dynamic content generation increases in W4 sites, since wireless devices are much more heterogeneous than ordinary Web browsers. You can get away with minor client-side twiddling to provide cross-browser sites on the WWW, but good wireless sites need to be formulated differently for each device on the server side, using a Resource Description Framework document to characterize the device's capabilities.
There would seem to be more hope for reuse on the business logic tier, since business logic is entirely on the server side, unconstrained by limitations of client devices. However, the different use cases of wireless devices demand at least a partial rewrite of your EJBs and COM components. Since wireless sites need to offer less information and fewer options than wired sites, they require a simplified business logic dedicated to providing the simplest and most commonly accessed types of information. If you write your EJBs with care, using appropriate default values, you may be able to actually formulate beans suitable for both purposes, but it's unlikely that you can reuse existing ones without change.
It will help if you structure the business objects' output for dual use. By creating all content in XML rather than directly in HTML, future content development can be directed at both HTML and WAP with XSLT processing.
The data access layer, often written in SQL using JDBC or ADO, is even more susceptible to reuse. Still, if the business logic intends to present different categories of data, some adjustments may be needed to the queries.
At the very back end, you can probably use the database without change. The data is the raw material that your company offers, so unless you decide to present completely different categories of information on the wireless site, you can keep the data as it is. Messaging systems and other components of your enterprise integration software can also be considered part of this tier and need little change.
Types of Software Reuse
At it's simplest, reuse means plugging directly into an existing component. On some layers you can do this, carefully choosing the parameters to account for the needs of wireless software.
If that's not possible, consider whether you can write adapter software to change the output and input of the component appropriately, and determine the correct layer for doing so. For example, if your business logic layer produces XML, write XSLT to process the XML into WML. If a number of servlets generate distinct HTML Web pages, which in WML should be presented together in a deck, consider writing another servlet to gather the outputs of these servlets, process them into WML, and output them to the client side in a deck.
Where adapters won't do the trick, you'll have to plan to rewrite components. In doing so, design for reuse. For example, instead of simply writing EJBs appropriate for wireless, write EJBs whose output can be channeled into both types of site. The same EJBs, in the same EJB container, can serve data to both the wired and wireless sites, with different parameters in the method calls.
At runtime you can reuse components by simply installing them in two sites: wired and wireless. In this model you have a replicated database, two application servers, two servlet engine and server farms, and so on.
Since replicating the database can cause consistency problems, you will probably have a shared database for wired and wireless. Given that at least part of the architecture will be shared, consider another model for reuse: running the two types of sites within the same application framework, including the same database, application server, and front end.
This will save on purchase and maintenance costs. On the other hand, you will encounter an increased organizational cost: the need to coordinate the two different sites, running on the same infrastructure but under the responsibility of separate teams, will slow development.
Parts of the dual-use material can be processed in batch mode: for example, transforming large amounts of XML with XSLT at once. This has the performance advantage of not requiring runtime conversion, at the cost of a considerable loss of dynamism. You should do this only for easily converted static material.
The good news on the server side is that most of your existing infrastructure is directly reusable. Hardware and software for the database, application server, front end, LAN, and load balancing can carry over directly to the W4 site when no longer needed for the W3 site.
Your existing infrastructure will have to be supplemented with a variety of WAP-specific devices. Despite the efforts of the WAP Forum, clients, service providers, and client devices have their own quirks in the form of prestandard implementations (like HDML instead of WML), unsupported features in the standard, WAP extensions, and just plain bugs.
For proper testing, real client devices are a must. If you thought it was bad developing for Netscape and Internet Explorer on Windows and Unix and Mac, just wait until you see how many different types of client devices are out there, running an assortment of different microbrowser software. The nature of the devices will depend on the area you intend to cover: GSM/PCS, for example, is just now becoming popular in the United States. Be sure to find out not only what models are on sale now, but also what models are already widely used. Right now, along with the device manufacturers' proprietary browsers, Microsoft Mobile Explorer 2 and the UP.Browser 3/4 from Openwave (formerly Phone.com) are in widespread use.
Some of this variety in clients can be supplied by emulators (often provided with the SDKs). Although no emulator can guarantee compatibility with the real devices, in-process tests - automated functionality tests or manual usability tests - on a variety of different emulators can give a preliminary indication of your application's cross-platform flexibility. A reasonable combination might be to use the Nokia, Ericsson, UP.Browser, and Microsoft emulators (see "WBT Resources" section). This should catch most cross-platform variation in WAP compliance.
Along with the client devices, you will need subscriptions to a variety of service providers to get the most widespread test coverage possible. Although some W4 content is designated for a specific service provider, we can expect the wireless Web to develop in the direction of full openness, like the wired Web, requiring developers to fit their sites to the needs of a wide variety of gateways and client devices.
Gateways are needed for translating WAP to HTTP. You can start inexpensively with freeware such as Kannel or with development-only versions, but setting up a wide variety of wireless gateways for testing can get complicated. One alternative is to use publicly available gateways. By pointing your clients at test gateways, you can do much of your work through the open Web. To get access to the widest range of gateway and client hardware, you can also consider contracting with an outsourcing company that has its own wireless testing labs. Such companies can save you on costs, but can't do all your testing; they must serve as a complement to iterative testing in an in-house lab.
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week