How to Write for Both Languages
Hopefully, you are convinced that even if you have an existing, sophisticated HTML site, providing a WML interface to your content (rather than relying on translation) is a good idea. You probably would not be reading this book if you didn't already think so anyway. So when you start building the WML side of your application, there are some things to think about.
Phone Considerations
The WAP client is a phone first and foremost, and for your application to be compelling it needs to take this fact into account. You can cause the phone to make a phone call, you can deliver a real-time alert to some phones, and phones have numbered keypads, not keyboards. How you present your data is significant. When you think about delivering content to a phone, think about how the phone is going to be used.
Tip
Employ the code that allows users to generate a call from their phone as often as you can. If you're presenting a phone number, wrap it in <a href="wtai://wp/mc;phone number></a> (replacing phone number with an actual number) so that the user can call the number by selecting the link.
Consider the following:
Unlike a PC keyboard with an Enter key and mouse navigation, the phone has one or more soft keys to which actions can be bound.
An HTML page gives the user the ability to choose from several possible actions with Input/Submit fields, links, and buttons. How should these features be mapped on to a WML card?
What is the most relevant information on a page that needs to be presented onto the phone?
Clearly, everything on the HTML page is not going to work on a phone.
What about frames?
Which frame should be sent to the phone?
Is it possible to get back and forth across the frame pages?
What about banner ads? How would these work?
Nobody is going to advocate removing banner ads from your HTML pages (this may be one of your current revenue sources), but with limited screen real estate you should think twice before using them.
PC Browser Considerations
Keep It Simple Stupid is one of the guidelines that HTML developers have a strong tendency to avoid. There are plenty of sites out there that are ultra slick and super confusing. The temptation to employ all of the newest/latest technology can be too much to resist at times, and developers have the tendency to overlook the fact that their user base may or may not have the ability to handle this latest technology on their client. I'm not suggesting that you regress to the days of Lynx and build a text-only site, but I do recommend that you consider the usability implications of a clean, easily navigable site. And I can't say it often enough: Just as you would with your HTML code, test your code on as many browsers/platforms/clients as you possibly can. Don't just test it to see whether it breaks, test it for usability. Can uneducated (about your site, not in general) users accomplish simple tasks? Do they get lost in your site? Do they get overwhelmed by your content or presentation?
Are end users going to be driving while they use the browser (I hope not), or are they going to be sitting in a coffee shop? Are they going to be waiting for a train? They're not likely to be at a desk. They are going to use their phones to find specific information quickly, or possibly they are going to want to kill some time and be entertained. Extra information that might enhance your HTML site will likely clutter a WML site.
Exactly what data you present to users on an HTML page versus what you present them with in a WML page can and should vary. Take a stock application, for example. On an HTML page, it would be simple, and would probably be a good idea, to display a chart showing a stock's performance over a day/week/month range along with any other data when you present a stock quote. However, the phone may or may not be able to display such a chart. If it can, the displayed image may not be large enough to be meaningful to the user.
One of the larger issues in dealing with the phone is the fact that users are not multitasking when using the browser. When you sit at your desk and you're waiting for a Web page to load, it is not likely that you have the browser taking up the whole screen. Maybe you're looking at different content in another browser window. Maybe you're reading your email, maybe you're proofreading a document, or maybe you're petting the cat. It all boils down to the fact that you're willing to put up with some degree of latency because your attention can be drawn away to other things. When users are accessing content on their phone, they are staring at the phone screen, waiting for a response. What may in quantitative terms be a short response time can seem much longer because attention is focused directly and exclusively on the device. A 10 second wait may be tolerable for an HTML page to load in a Web browser, but a 5 second wait can seem like an eternity when using a WAP-enabled phone. Keep this in mind when you decide what part of your site you are going to deliver to the user. Of course, what is acceptable varies from one application to the next, you'll have to use your judgment (and some real-world user feedback) here.