Supporting Mobile Phones

Why would you want to access the intranet via a mobile phone? The answer, most of the time, is that you wouldn't. Mobile phones are slow, have a very small screen size, and the numeric keypad is a very poor input device for anything other than phone numbers. In addition, the WML browsers on mobile phones are much less sophisticated than HTML web browsers on handhelds.

However, mobile phones do have some advantages that may make them suitable for accessing small amounts of intranet data:

• Mobile phones are ubiquitous - many employees will not have laptops or handhelds, but almost all are likely to have mobile phones (although they may not all be WAP-capable).

• Mobile phones are appropriate for accessing small amounts of time-critical information on the intranet.

• Mobile phones can send and receive SMS messages - therefore they are appropriate for "push" applications based around the intranet.

Mobile phones are best suited to using custom-written intranet applications rather than browsing the intranet as a whole.

Note

One possible use for a mobile phone intranet application is for a user who is frequently out of the office to find information on their schedule - this might be appropriate for an engineer who travels to a number of client sites. Support staff at the engineer's office can enter the appropriate information into a database via the normal intranet web interface, and then the engineer can access their schedule and the details of the client via their phone. In addition, the intranet application could send an SMS (Short Message Service) message to the engineer if the schedule changes.

An open source server for sending SMS messages is Smash, available from http://sf.net/projects/smash/.

WML

WML is the equivalent of HTML for mobile phones. Just like HTML, it is used for displaying content and for specifying user-interface elements such as forms. It uses XML syntax, so every WML page must be a valid and well-formed XML document. It must also include the XML declaration and the DOCTYPE declaration. A sample WML file looks like this:

 <?xml version="1.0"?> <!DOCTYPE wml PUBLIC     "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wm1_1.1.xml"> <wml>      <card title="Intranet">          <p align="center"><b>Welcome to the mobile intranet</b></p>          <p><a href="news.wml">News</a></p>          <p><a href="addressbook.wml">Address book</a></p>      </card> </wml> 

By analogy to HTML, it should be fairly clear what's happening here. This creates a WML page that contains the text "Welcome to the mobile intranet", and two links, one to the news and one to an address book. Although in this page there is only one <card> element, it is possible to have several small cards defined in one page, that can be quickly swapped between, a bit like a deck of cards, or relative links in an HTML page. This improves application responsiveness at the cost of initial download time.

Although it shouldn't be too hard to create a template that will automatically generate WML rather than HTML from your CMS, it's also not very useful. Because the screen size and allowed file size is very limited, automatically converted intranet pages are barely usable. Instead, WML should be hand-written for those pages which must be accessed from mobile phones. This means that accessing the majority of the intranet content is impractical - most authors will not be able to spend the time writing a highly condensed mobile version of their page. Instead, the only real use for mobile phones accessing the intranet is to access a few custom-written intranet applications.

Entering data (for example, to fill in forms in a web application) on a mobile phone is particularly painful. The only form of data that is easy to enter is purely numeric information. You may be able to exploit this. For example, a customer search that bases its searches on the phone number of the customer would be easy to use for a sales executive, because phone numbers are both easy to enter on a phone keypad, and likely to be stored in the phone.

For more information on WAP, see Professional WAP (Arehart C., et al., Wrox Press, ISBN: 1-86100-404-4).

Note

This screenshot is of a Nokia 7210. It was made using the Nokia 7210 Mobile Handset Simulator, available for free from http://www.forum.nokia.com/.

All the major phone manufacturers provide similar emulators that are available from their developer web sites.

It is well worth using a phone simulator (in addition to actual phones!) to test your WAP code, rather than just a desktop web browser that understands WAP. Some phones have limitations that will not show up in a desktop browser - for example, some early models of Nokia phones wouldn't accept WML files that were over 1.4 kb in size.

Voice Recognition and Synthesis

An alternative to accessing intranet information using WAP is to use VoiceXML. A VoiceXML gateway uses voice recognition and speech synthesis to provide a voice interface to a computer over the phone. It uses VoiceXML files that describe the words that can be understood by the system at each point, and what the response should be. It's similar to the "Press 1 to access your account balance, press 2 to pay a bill, etc."-style menu that is used by telephone banking systems, but uses voice recognition rather than the numbers on the keypad.

VoiceXML is backed by a number of major companies including IBM and Sun. An alternative, backed by Microsoft and Intel, is SALT (Speech Application Language Tags). SALT is more recent than VoiceXML, and so far VoiceXML seems better supported, but it's certainly far too early to discount SALT.

In this section, we'll concentrate on describing VoiceXML, but bear in mind that much of it is also relevant to other forms of voice recognition and speech synthesis.

The advantage of VoiceXML over WAP is that talking into the telephone is a more natural interface than using the WAP browser. It's accessible from any employee's phone, rather than just those that support WAP, and it can be used hands-free if necessary. However, as with WAP, it's only suitable for conveying quite small amounts of information at a time.

The VoiceXML file that determines which words are recognized and spoken can be generated on-the-fly by server-side script. For example, a VoiceXML gateway could be used as an interface to a company's client database. A company sales professional could phone up, and say the name of a client. This would trigger the same search that entering the client name into the "Client database" search box on the intranet would give. If the results from that search are returned in XML format, then they can be automatically converted to HTML for display on the intranet, or automatically converted to VoiceXML to be read to a user on the phone.

Another possibility is that a technician could use the VoiceXML gateway to perform searches on the intranet's technical support database. The results of the search can be read back to the technician, and he could use it as a step-by-step prompt to perform some support task.

Both of the previous examples could have been solved with a handheld, or a laptop - but providing all employees who are out of the office with handheld computers or laptops may be more expensive than the cost of a VoiceXML gateway and mobile phones. In addition, the hands-free access to information may be valuable to the technician.

A very simple VoiceXML file looks like this:

 <?xml version="1.0"?> <!DOCTYPE vxml PUBLIC "-//W3C//DTD VOICEXML 2.0//EN" "http://www.w3.org/TR/voicexml20/vxml.dtd"> <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml">   <form>     <field name="news" type="boolean">       <prompt>Hear intranet news?</prompt>       <filled>OK.         <if cond="news">Loading news now           <goto next="news.vxml" />         <else />           Going to next page.           <goto next="other.vxml" />         </if>       </filled>     </field>   </form> </vxml> 

This will say the words "Hear intranet news?" and if the user replies "Yes", then it will redirect to the news page. Otherwise it will redirect to another page. This example is using the built-in "Boolean" type that will accept only "Yes" or "No" as answers. A more sophisticated page would include a specific grammar, or reference an external grammar file, that listed a number of options that would be accepted.

There are obvious security concerns in allowing voice access to sections of your intranet. VoiceXML gateways will typically allow you to limit the valid users of the system based on the phone number from which they are calling, or by using a user ID and password system.

VoiceXML is of limited use for intranet access, but it is an option that may be appropriate in some circumstances. You can find more information on VoiceXML in the book Early Adopter VoiceXML (Breitenbach, S. et al, Wrox, ISBN 1-86100-562-8), or online at http://voicexml.org/.