|
Data gathering using wireless technologies
|
 |
 |  | Find |
|
Abstract
|
As the number of non-PC devices accessing the internet increases, the
ability to use a single-source of information that can be tailored to the
device accessing it increases. The presentation outlines how this can be achieved,
with particular focus on data gathering.
Firstly, let us assess why we need to gather data from
users of a product or service. Feedback is essential if the quality of a product
or service is to be assessed. Magazines often include surveys that users can
fill in and return to publishers. In return for providing this information,
the magazine may offer the chance to win a free subscription or some other
enticement.
However, the drawbacks of traditional paper-based data gathering techniques
are many and varied, starting with the cost of distributing the survey in
the first place. This may include cost of printing the survey, posting it
to a representative sample of respondents and including a pre-paid envelope
to encourage users to return it.
When the organisation receives the returned surveys, responses are often
double keyed into a database to avoid error. There is obviously a cost associated
with this, and even then there is no guarantee that the information will be
keyed correctly.
Even if the question is entered into the database with 100% accuracy,
there is no gaurantee that the respondent has answered in a non-ambiguous
way. For example, consider that a survey may ask the user to identify whether
they are male or female. Depending on the answer, the survey may ask men to
answer questions 2-6 and women to answer questions 7-10. There is nothing
to stop a respondent indicating that they are male, and then answering the
questions designed specifically for women. This will effectively result in
a spoiled survey.
Web-based surveys can address these issues provided the architecture
of the system is designed correctly. Firstly, distribution costs do not exist
as such because the survey will be placed on a web server. There is no need
to single- or double-key any responses as they are stored directly in a database
for further analysis. Most importantly, web-based surveys can be designed
to support question branching i.e., the next question presented to the respondent
is dependent on the answer to the previous question. This removes all ambiguity
from the responses given.
So where do wireless devices fit into this scenario? Forrester research
predicts that by 2002, 50% of all devices connecting to the internet will
be non-PC. This means that in order to attract a representative sample of
respondents, anyone wishing to gather data over the web will need to have
in place an architecture that can support collection from PCs and non-PCs
alike. One of the best established non-PC internet devices is the mobile phone,
and already it is possible to purchase a phone that allows you to connect
to selected internet services using the Wireless Access Protocol (WAP). Information
is presented in WML (Wireless Markup Language), a meta-language that adheres
to XML.
The presentation will demonstrate how a single example survey can be
used to gather information from a web browser on a PC and also to a mobile
telephone.
The main technical emphasis is on WML and building applications which
integrate with existing data and applications rather than on WAP protocols.
|
Contents
|
Background
WAP technology: is it a good idea
looking for a use. Is it technology for its own sake? Is it practical to surf
the Web using a telephone?
Some predictions about mobile commerce from The Open Group:
- The global Mobile Commerce market is set to reach 50 million customers by year end 2001.
- The global market for mobile devices is larger than that for personal computers.
- Everyone will have one or more mobile devices.
- The mobile device will become the preferred means of personal communication for both voice and data
- Customers will be able to access comprehensive personalized product and service information – and make their purchases instantaneously.
But is this all hype? In the real world, in a typical real-life business,
what benefit can be gained from using wireless devices to gather and consolidate
data?
Working with a client in the automotive industry, OpenMIND have implemented
an applicaton to test out an application implemented over the Internet, accessible
from desktop browsers and from WAP-enabled devices e.g. mobile phones. It
is a real business requirement that is likely to be supported by this type
of application. This paper looks at the characteristics of the requirement
that make it appropriate to use WML
technology. It goes on to describe how we used the technology to address the
requirement. It ends with looking at some of the issues that will affect future
development of this type of application.
Previous
Table of Contents
The business requirement
CareerMAP is a training scheme devised by a European motor vehicle manufacturer
and retailer. It is the name given to their Modern Apprentice (MA) Programme
which the manufacturer is in the process of revamping in line with its overall
business strategy. The programme will change the way the existing MA scheme
is managed within the manufacturer's retail dealerships around the UK. A key
feature of the programme is its use of Internet technology to support the
delivery of education in a controlled, distributed environment. In order to
reinforce commitment from local vehicle retailers, the programme manager committed
himself to carry out a survey of opinion around the country. This feedback
was used to configure the programme in accordance with dealerships' views.
Various mechanisms were used to gather the feedback from dealers: personal
visits, visits by representatives, paper mailings, survey feedback pages on
the Web Site and, as an experiment, a WML
interface to the survey database to be used by cool
associates of the programme.
Solution
Why wireless devices?
Image is everything. The representatives are out visiting vehicle retail
outlets. Vehicles are becoming more and more sophisticated. We are keen to
show that we have technology in place that is at the cutting edge. Yes, it
is a gimmick, but we want to capture people's attention, make our apprentice
programme stand out from the crowd.
However, it is also cost effective. There are some 150 representatives
around the country. To equip them all with a WAP-enabled
mobile phone would cost approximately £20,000 (capital cost), whereas
to provide them all with an internet-enabled mobile personal computer would
run to some £225,000. This is a considerable cost difference.
The main problem in March 2000 was not the cost or training implications
of rolling out a wireless solution, however, it was the availability in the
UK of Internet-navigation capable mobile phones. There was a choice of 2 telephone
handsets, one of which had a four week waiting list for delivery, and one
which was impossible to come by in retail outlets.
Technical
The main technical elements of a WAP-enabled
Internet application are summarised below:
- WAP Gateway - for public access, this is provided by the telephone service provider i.e. in the UK: BT Cellnet, Orange, Vodafone. For a dedicated corporate solution, providing restricted access to an authorised set of users, this gateway could be provided by a company for its own applications and user community.
- IP Connection between WAP Gateway and Internet (TCP/IP) - this interface is usually administered by the provider of the WAP Gateway. Without this interface, the WAP Gateway is essentially a dead end.
- Web Application Server - small changes need to be made to the Web Server to ensure it supports files of type WML, WMLC, WMLS and WMLSC. This is required to instruct the server how to handle requests for the appropriate file types. In our case, it is an ASP-enabled Internet Information Server. Development and testing is carried out on Personal Web Server using WAP development toolkits from UP and Nokia.
- WAP and Internet enabled Mobile Phone - these handsets are available
at the high end of the price band, naturally.
Database linkage
What database connections are in place and how do we make the link?
The HTML based application uses ODBC
connectivity to communicate with a Microsoft Access database to store and
retrieve the results of the survey. The HTML is delivered from a Microsoft
Internet Information Server using Active Server Pages containing ADO calls to retrieve and store data. In
terms of technology, this involves using VBScript, WML and WML Script. VBScript
is used to access the local file system, to communicate with the Web server
and access data. WML is used to control layout and application flow in the
user interface. WMLScript is used to provide procedural application logic
support.
The WAP-enabled service uses the same architecture to deliver WML pages
instead of HTML. We are able to ensure that all data (whether from the WML
or the HTML services) is stored in a common area.
Tips, tricks and lessons
This section addresses issues that we have learned about this technology
and the approach to using it over the last few weeks of development.
Why WML?
Using a WAP-enabled mobile phone it is possible to browse the Internet's
current content. This provides a way to interpret existing HTML-based sites,
so what value do we get from WML?
Of course, sites dedicated to being viewed through traditional browsers
tend to rely more on graphical content than it is possible to provide on the
current generation of mobile devices. There appear to be no plans to port
Flash or AVI formats to the platform: if nothing else, the bandwidth will
militate against that in the short to medium term. Micro-browsers supplied
in today's mobile phones will work very well with text-based versions of sites
supported by traditional HTTP servers. However, even text-only versions of
Web pages tend to be too wordy for an Internet-enabled mobile phone. They
can even allow a phone user to enter information into Web forms and submit
it in the traditional way. Internet mobile phones provide an adequate re-interpretation
of well-formed HTML.
However, for those of you who remember the days of Gophers and Veronica
on the Internet, the Web by mobile phone is just as much a disappoint as it
always was. Remember when you showed non-techno friends the latest World Wide
Web thing, and their reaction was: "Is that all there is?" Web via WAP is
like that: slow transfer rates, small screens, words and no pictures.
WML allows you to build applications dedicated to mobile phone users.
They contain rudimentary graphics, content can be focussed to give the best
layout for the keyhole screen, you can work within the restricted level of
memory currently available, you can almost guarantee how your applications
will be interpreted (almost). In fact, WAP and WML provide application developers
with the opportunity to reclaim the Internet for the geeks: the opportunity
to wrest control back from corporate marketing.
Application layout and design
Small Screen Real Estate. The small screen size
currently available provides a real challenge to today's WML application designers.
The availability of Graphical User Interfaces have spoiled us. We assume there
will always be a little more that we can do. One more fancy trick we can pull.
With the current generation of handsets available, there is only limited scope
for frills. In fact, you cannot even guarantee exactly how much screen space
there will be in the micro-browser on different handsets. A carefully crafted
graphic will be just too big for some people, just too small for others.
Limited set of elements at your disposal. There
are at present only a limited set of tags supported by WML: namely to provide
paragraphs, rudimentary tables, event "buttons" and simple graphics.
Specialised version of an application rather than re-using
HTML. Today's mobile phones are capable of delivering the text
content of existing Web pages, however, this can make for an unusable application.
Who wants to read the full text version of a broadsheet newspaper's Grand
Prix report 8 words at a time on a phone display? To make the most of the
medium demands a dedicated set of pages delivering cut-down content.
Varying interpretations of the application. With
desktop browsers, one man's HTML does not look quite like another. It is the
same with current WML-interpreting micro-browsers. A good example is the <SELECT>
or <OPTION> tag which causes varying behaviours even within phones supplied
by the same manufacturer (if their emulators are to be believed).
Application structure
Decks and Cards structure. The basic application
architecture revolves around a metaphor built on Decks and Cards. Loosely,
a card is a screen or transaction and a deck is an application, or series
of cards. A deck contains a series of cards. Control is passed from card to
card within decks or from deck to deck. Decks can also make use of procedural
code stored in external script files.
WMLScript. Procedural logic is implemented as
a series of functions in WMLScript which approximates to Javascript in HTML.
It can be used to perform calculations based on screen inputs, store and work
with memory variables etc.
Memory constraints on emulators/phones. Even
in the early days of development using emulators only, we came up against
memory usage problems: Nokia's emulator would run a deck that the UP emulator
complained about. Even on my handset, there are occasional errors such as
"Error 12011: HTML Translator is out of disk space".
Limited development tools. At time of writing
there are two freely available toolkits in which to develop WML decks: the
UP.SDK from Phone.com which contains the UP.Simulator and the Nokia WAP toolkit.
It is of course possible to develop applications using standard Web page editing
tools, using these simulator products to demonstrate the resulting code. The
Nokia toolkit, in particular, provides a range of features and supporting
technical documentation describing WML syntax and requirements.
Speed of delivery of an application to the handset.Currently,
GSM mobile phones in the UK transfer data at the rate of 9600bps. When typical
PC transfer rates exceed this by a factor of 5, the difference can be a little
frustrating. The constraints of text-only delivery, however, mitigate this
problem. This, of course, makes it all too irritating accessing non-WAP friendly
sites from a mobile phone: in fact, it can render a web site useless.
Limited data entry facilities from a phone keypad.
If you have tried to use a telephone keypad to write a message, you know the
problem. Features like "predictive text input" from Nokia and "iTap" from
Motorola purport to make things easier. But roll on the next generation of
WAP-aware PDA devices
with predictive handwriting recognition. Now that is bound to make things
easier! Or voice-enabled PDAs that let you say "double-u double-u double-u
dot oh pee ee en dash em eye en dee dot see oh dot you kay enter". That is
bound to make things easier.
Accessing databases
WML and its associated scripting language are designed to deliver client-side
applications and, as such, do not have in-built access to databases. In order
to deliver information from databases, it is necessary to supplement these
facilities with a server-side scripting environment such as ASP or CGI. In
the CareerMAP application, deployed on a Microsoft Internet Information Server,
we used ASP and VBScript to link to ADO objects.
Deploying the application
Very few changes need to be made on the server in order to start delivering
WML-enabled applications. The major factor is to extend the scope of supported
file formats on the server to support files of type WML and WMLS. All the
hard work is done by the WAP gateways that convert the telephone protocols
to tcp/ip packets.
The real development challenge is to integrate WML applications and
HTML applications at the code level rather than at the database level: to
write intelligent code that knows what format of markup to deliver to which
type of browser.
Example application
The application was originally developed as part of the existing Web
Site in order to support our contention that the CareerMAP programme is taking
the manufacturer on into new technology areas. It was designed to allow registered
members of the programme to express their opinions on certain key issues regarding
future developments in the MA programme. The registered users in this case
refer either to the 800+ dealerships spread round the country or to the 120+
representatives of the training management organisation that recruit apprentices
and dealerships into the programme.
The application is availale either as an HTML-based page for traditional
browser access, or as a WML-based application, both of which store data into
a common area.
Using the Nokia emulator, the following screen shots show several views
of the application during its early stages of development. The first diagram
illustrates an entry point into the survey.
On the whole, these emulator screen shots give a faithful presentation
of how the application will appear on a genuine mobile phone display. The
second screen grab shows a selection menu to control navigation around the
application.
The next shots illustrate a selection sequence as it is supported in
the micro-browsers within the two Nokia models. Note there are several differences
in screen layouts, fonts, wording on the menu options and the selection mechanism
itself. These two examples come from Nokia's 6150 emulation.
The next two examples come from the Nokia 6110 emulation.
And a final sign off after the dealer's views have been submitted.
Future plans
Where will the application go next?
We are gradually proving this approach with the organisations concerned.
At present, they are pleased to be at the forefront of technology, however,
there are some inevitable frustrations: size of the screen, usability of phone-based
text entry systems, availaility of handsets and so on. Selected representatives
are becoming used to this method of entering information and we are exploring
ways in which we could support them further in their work: other applications
that would neatly fit this model. We now have the technology to start to explore
how far WAP and WML
applications can go.
We are currently looking at other business areas to which we may be
able to deliver applications to support a similarly widely-dispersed field
force.
In the UK, there will be available later this year the second generation
of WAP-type protocols available to support higher bandwidths and faster access.
However, any applications built to exploit these developments will still revolve
around WML (albeit an expanded version of the current standard). Any effort
expended now in understanding the structural constraints imposed by the technologies
will not be wasted.
Bibliography