 |
|
    |
 |
|
 |
Forms: Collecting User Data Just like the Web, wireless services would not be as tremendously useful if users couldn't interact with remote services. That's where HTML forms come in handy. A form lets users enter unique user information like name and telephone number, as well as select the number of seats they want to reserve at the movies. You've probably done this hundreds of times as a Web user. The wireless experience is analogous, even though the lack of a full fledged QWERTY keyboard makes things much slower. We will touch on usability later on in this chapter. As usual, HTML is not exactly the same as XHTML MP, but if you are familiar with HTML, XHTML-MP forms are nothing new. In addition, we will touch on a couple of extra features that the Openwave browser imported from WML to improve end-user experience. One word about the back-end Of course, (X)HTML forms are not very useful unless you have some application managing them on the back-end. Managing forms on the server-side is exactly the same as managing Web forms and therefore totally outside of the scope of this document. The choices of languages, web servers and operating system is vast. The most popular choice include Microsoft Active Server Pages (ASP), Java (Servlets and JSP pages), PHP, and Perl, just to name a few. Generally speaking, web programming is more complex than dealing with static mark-up, so we leave it up to you, the developer, to decide what back-end environment and logic works best. The guidelines we provide in this document are focused purely on the front end and can be implemented using any language. Here are some references to get you started:
One example worth one thousand words Rather than delving into the boring details of each tag, we look at an example that will illustrate the big picture. The following is a purely fictional (and sort of pathological) form:
 Image 1: Form code displayed in a traditional web browser  Image 2: Form code displayed in the Openwave 6.2 Browser As you can see, this is what Web programmers were doing back in 1994. The form renders effectively the same on the Openwave Browser as it does on a traditional web browser, albeit with more scrolling. You may have noted those non-HTML 'format' attributes: <input type="text" name="minutes" value="" format="NNNNN" />
The semantics are exactly the same as WML 1.X, and constrain the range of acceptable user input to digits. In this particular case, we are telling the browser that a value made up of exactly 5 digits is required. In case we wanted to collect a number of up to 5 digits, we would have used: format="5N"
This is an Openwave extension, but we just could not let wireless programmers down on this. Collecting user data on a mobile device is an activity you want to keep as brier as possible. It is best to use input formats to guide the users and minimize the number of clicks required. Typing digits when the keypad is in alphanumeric mode is a sure fire way to make users hate your application. Future version of the browser (6.2 and on) will support a more elegant CSS syntax too: <input type="text" name="minutes" value="" style="-wap-input-format:NNNNN" />
It is worth noting that either of these methods of constraining input data types, using either style or the format attribute, may not work on all WAP 2.0 devices. For a complete spec of the acceptable values for the format attribute, you can refer to the WML 1.3 Reference Guide on the Openwave developer website: http://demo.openwave.com/pdf/51/wml_ref.pdf Please refer to the section "Specifying a Format Mask" under the section describing the <input>
element.
One more item worth noting in the sample code is the use of the selected="selected"
and checked="checked"
attributes. These may appear odd if you are used to traditional HTML development, but this is simply the result of XMLification.
The format attribute is not the only WML extension for the input element. The emptyok attribute can be used to specify whether the user can leave the field blank. Specifying emptyok="false"
indicates that the field is required and the user may not be able to submit the form without a value filled in. However, as with the format attribute, support for this attribute may vary from device to device.
Submitting a form Submitting form data requires a submit button; you cannot submit a form with a plain hyperlink as could be done in WML. The presence of WML variables allowed developers to collect data locally and pass it on via a hyperlink. There are no local variables in XHTML MP, and it is not possible to submit forms with hyperlinks in vanilla HTML either (unless you recur to JavaScript). Since there is no scripting language currently associated with the current release of the WAP2 specifications, the only way to submit and process data is by sending it to a server via an <input type="submit">
Special Considerations for the <select> ElementXHTML MP contains a construct which allows multiple options to be activated from a select list. The Openwave browser will render the code below as a series of checkboxes:
 Image 3: Multiple Select item on the Openwave Browser Another feature of the select element is the disabled attribute that makes a form inactive: <select name="category" disabled="disabled">
Users will not be able to highlight and activate a disabled widget. This attribute made it into the spec through HTML, because it is particularly useful in wireless. Due to usability considerations, you are better off not displaying the UI control at all to avoid confusing the user. Yet another attribute available for the <select> element is size, which specifies how many items should be made visible when the pop-up control is activated. <select name="category" size="3"> Image 4: Select attribute with a size attribute applied The size attribute should be applied with caution. Applications should be tested to determine if the experience is better with few items displayed requiring scrolling within the widget, or if more options within the widget are visible. It is also important to note that the size attribute is ignored when multiple="multiple" is used.
Wizards vs. Elective Forms In previous style guides for WML published by Openwave, we recommended the use of wizard forms for user input. A wizard is a way to collect user data by having the user focus on one bit of information at the time. When implemented correctly on the Openwave WML browser, wizards reduced the need to type and proved more usable on devices with tiny screens. With the introduction of XHTML, wizards have to be implemented manually and they do not save clicks anymore. In addition, each page of a wizard would require a trip to the server for processing as users would be required to post many small forms (which was not the case in WML where a new stage was presented automatically upon completion of the previous by using cards in a deck with local variables). When building forms for XHTML-MP devices, all widgets for collecting data should be presented on a single page. However, since these are mobile devices, often without convenient input methods, it wise to keep forms as short and simple as possible. What's Next Over the past three chapters, we've looked at core features of XHTML-MP and CSS as they can be used to build compelling applications. In our next chapter, we will discuss compelling ways to use images in XHTML applications. XHTML-MP Style Guide Chapters XHTML-MP Style Guide Index 1. History of XHTML Mobile Profile 2. XHTML MP in practice 3. Menus in XHTML Mobile profile 1.0 4. Text-flow 5. Forms: Collecting User Data 6. Images and Objects 7. Testing Your Applications Appendix A Appendix B |