Inputting free-form textual input is perhaps one of the most common tasks when working with electronic forms. In fact electronic forms can be viewed as a means of collecting semistructured information from the user and automatically tagging such information for later processing. Thus, a travel report might be modeled as an electronic form where most if not all of the fields collect free-form textual input from the user. Yet, when the travel report is filled in using a well-designed form that populates an underlying data model like the one provided by XForms, the information that is collected is immediately ready for further machine processing. In contrast, if the same travel report were directly authored as a word processor document, the data collected by the travel report would need to be reentered into the relevant systems in order to be processed further. As an example, consider a more detailed version of the questionnaire form introduced in Section 1.2.1 and shown in Figure 3.4. Once the information collected by the questionnaire is modeled using XML Schema, binding a set of user interface controls that facilitate entering this information creates an efficient user interface for editing and maintaining XML documents that conform to the questionnaire schema. Figure 3.4 Data collected by the questionnaire.< questionnaire xmlns:q ="http://example.com/q"> < name >< first />< initial />< last /></ name > < email xsi:type ="q:email"/> < home-phone xsi:type ="q:phone"/> < work-phone xsi:type ="q:phone"/> < address > < name />< street />< city />< state /> < zip xsi:type ="q:zip"/> </ address > < age xsi:type ="xsd:integer"/> < date-of-birth xsi:type ="xsd:date"/> </ questionnaire > XForms provides three variants of the generic enter some text user interface control, all of which have the same markup structure:
We demonstrate the use of these controls to author a simple e-mail application in Figure 3.5. Figure 3.5 Sending e-mail using XForms.< html xmlns ="http://www.w3.org/1999/xhtml"> < head >< link rel ="stylesheet" href ="email.css"/> < model xmlns ="http://www.w3.org/2002/xforms" id ="m1" schema ="email.xsd"> < instance > < email xmlns =""> < from type ="email"/>< to type ="email"/> < pin />< message /> </ email ></ instance > </ model ></ head > < body > < group xmlns ="http://www.w3.org/2002/xforms"> < input class ="address" appearance ="my:email" model ="m1" ref ="/email/from"> < label class ="address">From</ label > < help >Enter your email address</ help ></ input > < input class ="address" appearance ="my:email" model ="m1" ref ="/email/to"> < label class ="address">To</ label > < help >Recipient's address</ help ></ input > < secret class ="pin" ref ="/email/pin"> < label >Pin</ label > < help >Secret phrase</ help ></ secret > < textarea class ="message" model ="m1" ref ="/email/message"> < label >Message</ label > < help >...</ help >< hint >...</ hint > </ textarea >...</ group > </ body ></ html > Controls input , secret , and textarea use all of the common markup attributes and child elements described in Section 3.2. 3.3.1 Customizing Input ControlsControls input , secret , and textarea are commonly rendered as edit boxes in a visual interface. Notice, however, that the XForms design leaves considerable flexibility for a client to implement these controls in a manner most suitable for the facilities available on the accessing device. This section gives examples of how different clients and interaction modalities might leverage the information encapsulated in the XForms markup to deliver an appropriate end-user experience. We illustrate these scenarios using the e-mail application introduced in Figure 3.5; see Figure 3.6 for the visual rendering of this interface. Figure 3.6. Visual presentation of the XForms e-mail composer.
End-user experience is a function of the look and feel delivered by a user interface. As the phrase look and feel implies, this is made up of two halves : the presentation that is delivered to the user and the interaction behavior exhibited by the user interface, that is, the way the interface reacts to different user interface events. In XForms, the look is authored via CSS; the feel is specified using XML Events. Notice that in Figure 3.5, we used class="address" on the input controls used to collect the from and to e-mail addresses. An accompanying email.css can define appropriate presentational properties that help visually distinguish input fields that collect e-mail addresses; the same CSS style sheet might also define presentation rules for other output modalities, for example, aural output, by defining aural presentational rules for class="address" ”see Figure 3.7. [2]
Figure 3.7 CSS style that defines how fields for collecting e-mail addresses should be rendered in various presentation modes.< style type ="text/css"> @namespace xf url(http://www.w3.org/2002/xforms); xflabel { font-weight: bold; font-size: 20px; width:100px;} xfinput::value.address { font-weight:bold; width:500px;} xfsecret::value.pin { font-weight:bold; width:100px;} xflabel.address { color :white; background-color :blue;} xftextarea::value { width:800px;} @media speech { xfinput.address {pitch: 1; pitch-range: 9; } xflabel.address {pitch: 1; pitch-range: 9; } } </ style > Further media specific sections in the CSS file might fine-tune the presentation for different device types. [3] Factoring out presentational aspects from the user interface markup and delegating this responsibility to CSS enable the XForms author to design applications that can be delivered to a variety of different devices and presentation modalities.
The interaction behavior of user interface controls is primarily determined by the type of the bound instance data. As an example, input controls that bind to instance nodes of type date might be rendered as a date picker control. This can be further customized via attribute appearance . [4] XForms 1.0 defines three standard values for this attribute as described in Section 3.2. In addition, it allows for custom controls by allowing additional values for attribute appearance as long as such values are namespace qualified.
The example shown in Figure 3.5 takes advantage of this feature by setting attribute appearance to my:email on the input controls used to collect e-mail addresses. [5]
Notice further that when defining the model in Figure 3.5, we declared the type of the /email/from and /email/to fields to be my:email . An XForms client that includes an e-mail picker ”a widget that can access the user's e-mail address book ”can use that widget rather than a plain edit field. Notice that this mechanism enables clients to deliver an end-user experience that best leverages the facilities available on a client. At the same time, the XForms e-mail application can be used on a device that does not provide an e-mail picker control. We declared field date-of-birth in Figure 2.11 to be of type xsd:date . This information could be used to pick a custom date picker control when rendering an input control that binds to the date-of-birth field. By setting an appropriate value for attribute inputmode , entering the date or e-mail address can be made easier when using devices such as cell phones. More ambitious use cases would include invoking an appropriate speech interface that is capable of collecting a valid date; advanced user interaction including speech and multimodal interfaces will be discussed in Chapter 10. |