8 Steps to Successful Wireless Projects

Report Prepared by: Technical Staff

AVIDWireless

Overview: This paper will present a managerial and high-level technical overview of the process of developing
wireless applications. Initially, developing a wire less application may be viewed as a difficult challenge, but this
paper will introduce an 8 step repeatable process that speeds and simplifies development. It will discuss the
peculiarities of wireless applications, and once understood, a typical software development group should have a high
success rate on completing their first wireless application. This paper also supplies a case study and follows a project
from start to finish. The application can be accessed at http://aviddemo.com from any wired or wireless device.
Much has been written about the “Wireless Web”, giving many developers, managers and executives the impression
that wireless devices are just PCs in a reduced size. Unfortunately, this is a vast oversimplification and it has led to
many disappointing and failed wireless initiatives. The point is not to provide a replacement for the Internet in a
small screen (there is probably just as much demand for this as there is for handheld televisions), but to add an
invaluable tool for remote personnel.
The main purpose and benefit of a wireless device is improved communication between distant locations anytime,
anywhere. Wireless communication has been around since the early part of the last century, and has provided
enormous benefit to corporations and governments by allowing their people to talk to one another from remote
locations (cars, job sites, etc.). Wireless data communication has also been around for the last 30 years or so, but the
equipment was very expensive, often custom manufactured, and the coverage was extremely limited. In the past two
to five years, low cost equipment and ubiquitous networks allowed the wide spread adoption of wireless computer-
to-computer and remote data access.
Implementing a successful wireless project is more than plugging a wireless modem into a laptop – it requires
specific design and understanding of the equipment, the network and the nature of wireless communication. In this
paper, we will review what makes wireless development unique while showing how it fits into the existing
development process. It is important that enterprise IT organizations do not abandon existing software development
processes and techniques just because they are dealing with wireless devices.
To illustrate, we will follow a typical project from the genesis to completion. We will follow their steps as they
progress through the project and show how they handle each activity in terms of mobile devices during their project
life cycle.

The Problem:
“Where do I start?”
Joe has just left a meeting with his COO and VP of Sales. In the meeting, they discussed issues brought to their
attention by the buyers and sales personnel. The issues stemmed from the lack of real-time access to inventory
information. Sales people were taking orders for non-stocked items and the buyers were purchasing products for
which there was little demand. Last year, when business was booming their company could live with these errors
and inefficiencies, because demand was great everything was moving. But now, with a slowing economy, inventory
levels need to be closely monitored, and every order should be filled as soon as possible. The VP of Sales said that
if his sales people knew a certain item was backordered, they could suggest an alternative in-stock item to their
resulting in a 20% increase in fulfillable orders, improving inventory turnovers.
Joe’s group completed a web-based inventory reporting application six months ago, which he felt should have
solved these problems. It was a pretty amazing application, filled with charts, graphs and tables. The only mistake
was that the buyers and sellers worked mainly out of the office and did not have instantaneous access to this
information. About a year ago, the COO equipped her buyers with Palm computers that synced with a subset of the
inventory database, but she explained that all to often the buyers used information that was a week old or they
needed information that was not in the subset of synchronized data. On the VP’s last business trip, he read an article
in an airline magazine that talked about the new wireless web phones and PDA’s. He thought if Joe’s group could
connect these wireless devices into the company’s databases, then his buyers would always have up to the minute
information. He told the COO about his idea and she instantly saw how this could improve her buyer’s efficiency
and in turn reduce poor purchasing decisions.
So, the wireless initiative has been approved and Joe’s group is on deck to perform.

Copyright © 2001 AVIDWireless / VoiceDataWare Inc. http://www.avidwireless.com Page 1 / 14

7750 N. MacArthur Blvd., #120-340, Irving, Texas 75063 Ph. 888-772-4570/214-853-4646
 Successful Wireless Projects in 8 Easy Steps

Step 1. Choose the Information you need to Access

There is a classic cartoon about software development that shows a room full of programmers at their keyboards and
one of them (presumably the leader) leaving the room and saying “You all start writing the software while I ask the
users what they want.” This behavior results in a system that does what the developers think the users need, not
what the users need.
Your users (the buyers and sellers in Joe’s case) need to be part of the project team. But how can they contribute
when they do not write software? In a properly managed project, you should spend reasonable time performing
analysis of the problem before designing a solution. The analysis phase of a project uses a diagramming notation
called Use Cases, part of the Unified Modeling Language (UML), an industry standard for specifying user
requirements.
A Use Case is a simple graphical representation of how the user will use the application. It does not take a
programmer or software developer to specify a Use Case; in fact, it has been our experience that end users
(managers, salespeople, marketers, field workers, etc.) are often better at developing Use Cases. This is because
they think in terms of describing the problem, not solving the problem (like many software developers do). For
every important operation identified by your users, a Use Case diagram is created. Other people (vendors,
customers) will be represented in the use cases, as will the systems they need to work with (the Inventory
Management System). It is important to note that Use Cases include all the steps in an operation. Use Cases are not
simply flow charts, and they do not only show computer-based operations (the “offer made” in the illustrated Use
Case in figure 1 is a manual operation).
At this initial stage you may not think you are doing anything specific to a wireless application – this is a basic step
that should always be included in projects, but is often skipped. You may think that since you are just porting an
existing application or web site you do not have to determine how the users will be using the system – the wireless
users will use it the same way your existing users do, right? Wrong. There are unique concepts to consider when
developing a mobile application, such as:
• The user will ALWAYS have their device with them. When you think of the Use Case, think of what you could
do if you had immediate access to ANY piece of information. It is important not to be limited to existing ways
or processes.
• What is the end result of information the user must have? For example, instead of thinking about the user first
looking up some information from System A and then something else from System B, determine what is the
final information you need and let the back end system do the lookups or processing.
• Wireless devices can have information “pushed” to them (think of a pager). So you do not have to limit
yourself to the user being at a terminal or calling up a particular report – you can send them the information
they need.
• Is there particular information that the user will need at a certain location or at a particular time? If so, you
should build a Use Case for this need.
Upon completion of the Use Cases, your team will have an understanding of how the users plan to use the system,
and which people or systems will be involved with this application.

You will also see common concepts emerge (like both the Buyers and Salespeople need to look up current on hand
information). From the Use Cases the software development team will be able to approximate the effort and
estimate the project’s complexity, duration and cost. Use Cases are extremely useful for reviewing and prioritizing a
project – you may choose the five most important Use Cases to the customer to implement in the first phase of a
project, and save other less important items for another phase.

Copyright © 2001 AVIDWireless / VoiceDataWare Inc. http://www.avidwireless.com Page 2 / 14

7750 N. MacArthur Blvd., #120-340, Irving, Texas 75063 Ph. 888-772-4570/214-853-4646
 Successful Wireless Projects in 8 Easy Steps

Let’s check in on Joe

One of the Use Cases defined by Joe is for when the Buyer is meeting with a Vendor and the Vendor makes a
special offer to the Buyer (“If you agree to buy 10,000 of these now we can offer you an extra 15% discount.”). The
Buyer would need immediate access to the number currently in inventory (Current On Hand) and the past three
weeks sales to make an informed decision.

DETERM INE BUY

NEED

Match Vendor
offering with
Potential Need

Vendor
Buyer Analyze Current on
Hand & Last 3
Week Sales

<<actor> >
Inventory
Management
System

Use Case to Dete rm ine if there is a Need to Purchase fro m ou r Vendor.

Figure 1. Use Case for the Buyer meeting a Vendor and
Needing Access to Current on Hand and Last 3 Week Sales

Step 2. What Should the Screens Look Like?

The initial project team (end users and developers) will then think about how the application will perform on the
mobile device. Mobile devices may have a 1 by 1 inch screen, which makes 80 columns by 24 lines extremely
difficult to see. Unique factors to consider for mobile devices are:
• Limited display size. Phones may be able to display 12 to 20 characters by 3 to 10 lines. PDA’s may have 30 to
60 characters by 10 to 18 lines. Use short, meaningful words and phrases.
• Monochrome with no graphics or limited graphics. On a phone, you may have 48 by 96 pixels, and a PDA 160
to 240 pixels limiting your graphic size and resolution. Graphics may be used to replace several lines of text,
but do not assume your device will have graphic capability. Many of the web-enabled phones currently
available, are text only.
• Difficult data entry. Choosing data from a list of choices, is much faster and less frustrating than pressing the
“1” button three times to produce a “c” and so on. Do not ask the user to input a date, give them predefined data
(the Use Cases will aid you in determining important dates or other fixed information).
• WAP Phones are telephones. (People sometimes forget that) The WAP protocol supports the ability to instruct
the phone to dial a number. Instead of long text screens, think of having the content delivered via a phone call
and integrate a voice response system or text -to-speech into your technology.
• Limited Interface. Menus should be limited to five to seven items, remember over three items will usually
require the user to scroll down to view them.

Copyright © 2001 AVIDWireless / VoiceDataWare Inc. http://www.avidwireless.com Page 3 / 14

7750 N. MacArthur Blvd., #120-340, Irving, Texas 75063 Ph. 888-772-4570/214-853-4646
 Successful Wireless Projects in 8 Easy Steps

• Inconsistent Interface. With WAP phones you can only really presume a single selection button will be
available (the second, or OPTIONS button, may be designated for choosing the text entry modes). The reliance
on more than one button will limit the devices that can be used.
• Segmented Input Screens. A wireless device may not present the items on the screen as you would expect. For
example, Openwave (formally Phone.com) browsers present each input field on a separate screen, unable to see
previous inputs or prompts. Some phones show a placeholder for input fields but do not show the content of the
fields.

What will Joe’s screens look like?

In practice, we have found it extremely useful to draw mock-ups of screens. Therefore, we designed a “flexible,
rapid prototyping tool” that looks like a typical cell phone screen on “Post-It’s”(® of 3M Corp.) Using these
“Stickies” while brainstorming with users is helpful in enabling everyone to visualize the layout of the application
and aid in making the user interface more intuitive and useful to them1 .
Having the Mobile Device form factor in front of the users and developers is invaluable to change their “Desktop
PC” mentality and help them realize the interface challenges that are associated with working with mobile devices.

Choose report for SKU

ROM34345 3
1. Current On Hand
2. La st W eeks S ales
3. La st 3 W eeksSa les

S ELE CT HO ME
SelectReport
Initial

Figure 2. Joe’s Sample Screen Layout

Prototype screens are designed as required for each of the Use Cases. Some Use Cases will require multiple screens
to illustrate their user interaction.

Step 3. Determine the Screen Flow

It is important to understand the navigational aspects of your wireless application. On a desktop PC most users do
not mind if they have to go through three to five screens to get to what they need. On a WAP phone or 2-way pager
this is very laborious, as well as time consuming. Studies have shown that for every time a user is required to
navigate to another screen on a WAP phone, you potentially lose up to 1/3 of your users. Therefore, you should
ensure the user can access their information in one or two screen clicks.

1
A current trend in software development is Extreme Programming (XP). One of XP’s principles is simple tools, of
which our stickies are a perfect example. Using sticky notes, whiteboards and some formal models (to aid
understanding and communication) support XP’s paradigm of communicate, collaborate and feedback.

Copyright © 2001 AVIDWireless / VoiceDataWare Inc. http://www.avidwireless.com Page 4 / 14

7750 N. MacArthur Blvd., #120-340, Irving, Texas 75063 Ph. 888-772-4570/214-853-4646
 Successful Wireless Projects in 8 Easy Steps

Important guidelines to consider are:

• Number of Screens to Result (NSR). Reduce the number of screens the user has to view before they get the
required information. Tricks include:
§ Profiles. Maintain a profile for each user, or group of uses, and prioritize the navigations based on
the profile (each profile will see the application behaving differently).
§ Location. Give the users information appropriate to their location. If a user is in Dallas and the
information you present them is location-based information show Dallas information first and then
provide them the option to provide a different city. By doing this you will have taken care of 90%
of your users request and yet provided them with the flexibility to gather additional information.
§ Time. Provide time-sensitive information. An example would be if a user requests their current
travel itinerary, do not show them the flights they have already taken – first list the upcoming
flights.
§ Priority. From your Use Cases you know what operations the users will be performing the most
often. Put these items at the top of the menus and put less used operations last. You should limit
your menu choices to no more than nine items (we recommend limiting them to 4 items).
• Escape. Give your users a way to return to a common starting point. If you think getting lost with a web
browser is bad, getting five menus deep on a WAP phone is worse. A WAP phone does not have a title bar or
history list to tell you where you are or how you got there; you can only go back. Likewise, WAP phones do
not have a forward button. It is recommended that you provide a HOME or MAIN button to allow the user to
return to a known starting point.
• Plan your Route. As a TV or Movie producer plans their sequence using Storyboards, the designer needs to plan
the route their users will follow. The screen prototypes from step 3 can be connected to illustrate the path the
user will travel executing each Use Case. Between each Screen you should label the reason why the user will
move along this path (example “Selected Current On Hand Report”). Some of the movements will be as the
result of calculations, database entries, user inputs or selections, or external inputs.

Let’s take a look at Joe’s Screen Flow

SKU NotFound
Screen:Inquir y Screen:SKUInquiry Screen:NoRecords

Mode: None Return Mode:None Return Mode:None

Reports Enter
Return /Mode=Dept
Return /Mode=SKU

Legend
STD STD: Season To Date
Screen:Reports Screen:DeptList COH: Current On Hand
Mode:Dept/SKU Mode:STD/Last3/COH Last3: Last 3 Weeks Report
Return

COH
STD Last3
Report Report
Report

Screen:SeasonToDate Screen:Last3Weeks Screen:CurrentOnHand

Mode:Dept/SKU Mode:Dept/SKU Mode:Dept/SKU

Figure 3. Screen Flow for the Inventory System.

Copyright © 2001 AVIDWireless / VoiceDataWare Inc. http://www.avidwireless.com Page 5 / 14

7750 N. MacArthur Blvd., #120-340, Irving, Texas 75063 Ph. 888-772-4570/214-853-4646
 Successful Wireless Projects in 8 Easy Steps

Step 4. Architect the System

Great buildings are not assembled solely by expert craftsmen. The expert craftsmen must follow an architect’s
blueprint to build the structure. Your software developers (expert craftsmen) need a blueprint if they are to assemble
a scalable system that will provide maintenance free operation. BEFORE the coding phase begins, have one or two
of your top software developers work as architects to develop a blueprint for how your system will be constructed.
Fortunately, there is an equivalent to prefabricated buildings; they are called middleware servers. There are general-
purpose middleware servers (empty shells) that require you to write the internal guts and mobile specific software,
and there are wireless mobile middleware servers (completely assembled).
Wireless middleware servers have special features, which include:
• Ability to work with multiple devices. Each device has its own nuances and particular use of markup
commands. The ideal wireless middleware would allow you to develop a single program source for every
device; without this, you will have multiple copies of similar code for different devices.
• Provide user profile and customization database. This will allow you to provide more user-friendly systems
which feature custom navigation (see Step 3) and user-customized screens (see Step 2).
• Allow easy capture and access to the user’s subscriber number, device identification and user location. The two
primary unique features of a wireless device are that users think of them as personal items and they always have
the device with them. Often they need access to information based on the context of their current location.
Your middleware needs to recognize this and be able to capture and store the information.
• Maintain user sessions throughout disconnects and intermittent connections. A wireless device may go out of
range (EVERY wireless system has “dead spots” – unfortunately), be turned off, or exhaust its battery. When
the user is back on-line, they want to be able to reconnect to their current screen and not s tart over again.
• Ability to easily add support for new devices and technologies. Wireless is a rapidly changing field. Not only
are there new phones, PDA’s and pagers, there are new technologies, markup languages and operating systems.
Your middleware vendor must be able to quickly respond to these changes WITHOUT forcing you to rewrite or
change your application.
Many software developers feel they can create better programs than packaged software can provide, and perhaps
they are correct. However, once you build your own middleware you then become a software vendor (to a customer
base of one). With that comes all the support and maintenance efforts and costs of a software vendor, but without
the wide customer base to finance the support.

Did Joe decide to make or buy?

Joe chose a middleware package that works with his existing Java Servlet Engine and JDBC database, and will
continue to work with his future J2EE Application Server. The system architecture looked something like this:

Figure 4. System Architecture

Copyright © 2001 AVIDWireless / VoiceDataWare Inc. http://www.avidwireless.com Page 6 / 14

7750 N. MacArthur Blvd., #120-340, Irving, Texas 75063 Ph. 888-772-4570/214-853-4646
 Successful Wireless Projects in 8 Easy Steps

Step 5. Develop Screen Objects

Now comes the main work, developing the programming that lies behind the screen, right? If you have spent the
required up-front time (Use Cases, Determining Screen Design, Screen Navigation), you will have completed most
of the work at this point. It is unfortunate that many projects rush to the coding phase (which is where most
software developers are most comfortable) and then investigate how the system will be used, what the screens will
look like, etc., as they are developing the system. Since they start with incomplete information, such as the behavior
of the system, screens and navigation is refined, the developers must constantly go back and modify their code. This
results in wasted work and rework of things that were not considered or completely thought through. That is why
some software projects seem to spend 10% of their overall time to reach “90% done” and then 90% of the total time
completing the last 10% of the project. 2
Because of the stateless nature of web and wireless applications, we find it easy to partition each screen the user sees
as a separate object. In very simplistic terms, an object is something that has values and can do things (execute
actions). For example, an airplane, wh ich is an object, has values of a flight number, departing airport, destination
airport, and number of passengers. It has actions of departing from a terminal, taking off into the air, flying to the
destination airport, landing and arriving at the gate. We can think of the values on the screen and the actions we will
do based on user selections or operations (buttons pushed). Each screen object will correspond with the screens we
developed during the screen design, giving us a consistent path and flow from our earlier work to our coding and an
identifiable work product we can track. In addition, we have found the screen objects to be highly reusable, not only
in a single application, but between applications.
Our paradigm is each user screen is an object that has two operations: display and submit. The display action will
paint the screen, an operation that may involve looking up information, querying databases or other calculations. If
the screen is asking for user input, the submit action will handle processing of the user’s input – again performing
required calculations, database accesses and other information retrieval. Each action needs software to be written to
perform the needed operations.
When developing code for a mobile application consider:
• Mobile units may roam in and out of range, which can result in disconnections. Your software should allow the
user to continue if the connection has been dropped for a reasonable amount of time. Likewise, if the time is
exceeded the program should “timeout” and restart the user at a known starting place.
• Given the difficulty entering information, try to preserve information and reuse previous selections or entries. It
is infuriating to go to the trouble of entering your name or an address, and then for some reason you must return
to that screen and the application asks you to re-enter the information.
• Most mobile servers have very aggressive caching software and will try to redisplay a page from the device’s
internal cache rather than send it again. This can help improve response, but in dynamic systems, it may present
the user with outdated information. Your software should be able to account for the wireless server or
gateway’s caching algorithm.
• WML is an open standard that is loosely implemented. It allows each manufacturer to optionally implement
various portions of the specification where capabilities can be omitted or extra features added. Since WML is
still young, there are older, incorrect implementations of it on some devices. If you choose to code in WML,
note that WML does not behave the same on all devices.
• Wireless networks have what is called “latency” or delays in which the information is transmitted from the
server until it reaches the device. Internet latency is measured in seconds or fraction of seconds; with wireless it
is measured in seconds or minutes. We have seen push messages delayed for up to 20 minutes or more (which
diminishes the real-time nature of wireless).
• Message length. Many mobile devices and networks have limits on the length of a message. Your application
must be cognizant of these limitations and handle them appropriately. You can break up a message or choose to
display a subset of the message.

2
This is not to imply a pure single pass or “waterfall” model for software development. We recommend a planned
interactive approach where these steps are followed for each iteration – from use case analysis to testing. Each
iteration has a defined goal and completion criteria and their duration may span from several days to several months.

Copyright © 2001 AVIDWireless / VoiceDataWare Inc. http://www.avidwireless.com Page 7 / 14

7750 N. MacArthur Blvd., #120-340, Irving, Texas 75063 Ph. 888-772-4570/214-853-4646
 Successful Wireless Projects in 8 Easy Steps

How is Joe doing?

The Screens listed in the Screen Flow in Step 3 were implemented for Joe’s system. The middleware technology
implemented each screen as a reusable Java object that reduces the amount of code to write and improves the
maintainability.3 Appendix A contains a list of the SeasonToDate screen Java source code.

Step 6. Develop Data Objects

It is good design practice to partition or encapsulate the portion of your system that connects to your database or
information repository in a separate object, or group of objects. Done properly, you can reuse this software among
multiple applications (not just wireless), reduce maintenance efforts (changes are all localized to a single area),
reduce errors and development time and improve performance (since a database expert can develop this portion of
the system and the entire system will benefit from his/her knowledge). You want to avoid having each developer
hard code the database calls into each of their modules.
If you have followed this principle in previous projects, it is very likely that you already have this portion of the
project completed and your screen objects can “plug-in” and use this work. Even so, you should review the work to
ensure it is compatible with mobile devices.
While developing your data objects consider the following:
• It is customary to lock portions of a database during updates. Due to latency and dropped connections, ensure
locks are not maintained across user actions. If your application requires this behavior, time out these locks and
roll back incomplete operations.
• Security may be a factor. Wireless devices are easily stolen or lost. Most wireless devices have unique
identifiers or subscriber numbers so you can identify a particular device, but you do not know who is using it.
Make sure passwords are not cached.
• Utilize location information from the device to make queries that are more intelligent. Instead of asking the
user for their location, if the wireless device/network provides location information, you can use it to localize
the results for where the user is.
• Add geographic location information (latitude and longitude) to items in your database and allow queries that
are “near” or “close” to something. You may provide a query asking to list hospitals near the user, and if your
database contains geographic coordinates, you can resolve “near” to be within a three-mile radius. It is difficult
to determine “near” from a street address.

Joe’s data objects

Each database table Joe connected to was implemented as a reusable Java bean. The bean provides methods that
implement the queries needed for his application, such as "findCurrentOnHand" and "findBySKU". The database
developer wrote these methods once and they were used in many of the screens.
The alternative to this would be coding the database queries in each screen. Not only does this take a long time, but
also each developer would need to be familiar with the structure and content of the database resulting in a greater
potential for errors. When there are new changes to the database (and any system will undergo changes in its
lifetime) these changes would need to be implemented multiple times in multiple programs. Having your data
access encapsulated in a layer, like a Java bean, leads to increased reliability and reduced development /
maintenance time.

Step 7. Test, Test and Retest

Along with your standard testing procedures, test your application in a live scenario, on the device that it will be
used on and in the locations where it will be used. The Use Cases will provide a framework of expected situations
from which you can construct a complete testing strategy. The Screen Flows will also guide you in the sequence of

3
For those interested in viewing the source code created for this example you can view it on-line at
www.avidwireless.com.

Copyright © 2001 AVIDWireless / VoiceDataWare Inc. http://www.avidwireless.com Page 8 / 14

7750 N. MacArthur Blvd., #120-340, Irving, Texas 75063 Ph. 888-772-4570/214-853-4646
 Successful Wireless Projects in 8 Easy Steps

allowable operations. Since the Screen Flows will enumerate all possible logical flows through your application, a
finite set of test cases will provide a statistical confidence that you have completely tested your application.
Mobile and wireless applications require specific testing:
• Coverage. Test where the units move out of range in the middle of a transaction and then come back into range
1, 3, 5, 10, 15, 30, 60 or 90 minutes later. Test the effect when the device is moving between network cells or
receivers and the "hand-off" between these cells. Does the connection get lost? Is it hung up? Remember that
these are mobile devices and they will be moving around.
• System Failures. Simulate failures of any external system to this application, including networks, databases,
data sources, incorrect data, missing data and any external system component.
• Device Failures. Simulated failure modes of the device (dead battery, interference, missing accessories).
Document procedures to identify and rectify the failure – this will become the basis for your wireless help desk.
• Data dependent testing. Mobile devices are more susceptible to errors with long data messages. Some will
display partial messages, or an error screen, or just ignore the message. Understand the limitations and keep
messages concise.
• Latency testing. As mentioned before, wireless systems have delays (the Internet has delays but the high speed
and maturity of the technology usually makes this imperceptible). Latency is dependent on the carrier, their
equipment, transmission technology and system loading. Test your devices at various times of the day to ensure
the latency is within your requirements. Latency is also affected by your connection to the carrier. The more
direct a connection (leased lines, Frame-Reply) the less the latency.
• Middleware traffic capacity. Test that your server will be able to handle the projected traffic capacity. Wireless
servers are different from web servers in that they serve short, bursty messages while web servers serve
messages with longer content. A wireless page may contain 1,500 characters, while a web page may contain
10,000 or more characters. You may serve five wireless pages for a single web page containing the same
content. Servers that are based on CGI or scripting technology may become a bottleneck, while compiled
servers (Java) will be able to handle the load due to their faster performance and lesser amounts of processing
required for each request.
Wireless application testing is a new area and there are few tools available. The YoSpace SmartPhone Emulator
(www.yospace.com) has scripting capability to allow implementation of regression test scripts. Mercury Interactive
and other web testing tool vendors are in the process of developing and offering tools for wireless testing.

How did Joe fare in his testing?

During the testing of the application, Joe purposely introduced errors such as dropped connections, server restarts,
disconnected databases to stress test the application. During these tests Joe uncovered some error conditions not
previously considered and added additional tests or connections between the screens to handle these conditions.
Joe used test scripts developed from the Use Cases by using the YoSpace Emulator. This allowed for easy
regression testing of the system, and as Joe added new features, he could easily retest previous functionality to
ensure he did not break something.

Step 8. Deploying Wireless

You should implement the deployment of your wireless application in phases after completion of a thorough pilot.
Even if you have a small group of users (less than 20), it would be a good idea to first pilot the application with three
or four of the users to uncover any unknown factors or limitations. During the pilot sample, users should represent a
cross section of the user base and not just the "power" users. These initial users need to receive the same training,
documentation and support that the will be given the final users of the system.
Important Note: A classic mistake we see is when an application is given to the pilot users, without the previously
mentioned support materials or training, and then the pilot fails due to user frustration or inability to use the system.
An important part of a pilot project is to gather feedback and information to improve the system or the general
deployment. To these ends you should:
• Have the users record any anomalous behavior, incorrect operation or unexpected results.
• Have the users record areas of poor coverage or no signal. This may uncover unknown "dead" spots.

Copyright © 2001 AVIDWireless / VoiceDataWare Inc. http://www.avidwireless.com Page 9 / 14

7750 N. MacArthur Blvd., #120-340, Irving, Texas 75063 Ph. 888-772-4570/214-853-4646
 Successful Wireless Projects in 8 Easy Steps

• Have the pilot users rotate by using various types of devices. It is important to understand what they view as
preferred devices and identify any differences between the applications operation with the different devices.
• Conduct review sessions and focus groups to analyze the results. Use the results to improve the system.
Expect the pilot project to last one to two months. If there are problems or changes that need to be made, do not be
afraid to delay deployment until these are all fixed. If the system is performing per the initial specification
(determined with your Use Cases) and the feedback is considered future enhancements, you should not delay
deployment of this system. The initial effort you made with the help of Use Cases will delineate initial requirements
from enhancements.

Joe’s pilot results

Joe’s application was deployed to five buyers, each from different departments and each interfacing with different
vendors and different types of goods and buying schedules. It was uncovered that durable goods buyers needed
three and six month reports, as well as reports covering the previous year. This was an enhancement, but due to the
ease of implementation, this was quickly added to the system (it was just an additional report and the existing
screens could accommodate the change).
Buyers preferred devices with wider screens since the display was "wrapped" on the smaller devices. They also
preferred devices on packet networks since they were "always on" and did not require a connection time. The
application allowed the buyers to make "real-time" decisions and take advantage of better pricing over their
competition and there was a reduction in the purchase of slow selling items, this improved the overall margins.
After a 30-day pilot, the application was deployed to all the buyers. In the future they plan to distribute this
application to all store managers.

Figure 5. Final Report Screen Figure 6. Report Screen (above)

(compare to Figure 2) Figure 7. Palm Screen (right)

Figure 8. Department selection screen on Ericsson R380 Phone/PDA

Copyright © 2001 AVIDWireless / VoiceDataWare Inc. http://www.avidwireless.com Page 10 / 14

7750 N. MacArthur Blvd., #120-340, Irving, Texas 75063 Ph. 888-772-4570/214-853-4646
 Successful Wireless Projects in 8 Easy Steps

Summary
Wireless is available now and can be used for productive applications with immediate results. The devices and
networks will continue to advance, but these future enhancements will improve your application, not make them
possible.
An intelligent selection of middleware and selection of a vendor that is firmly committed to the wireless space will
"future-proof" your investment. Some wireless servers allow development of device agnostic applications, allowing
your developers to concentrate on business rules and quickly create applications. Wireless devices are "anywhere,
anytime" information devices that provide a very different set of benefits from conventional web applications.
Limiting yourself to simple translation of your current web or terminal applications to the wireless world will not
provide you the benefit, or payback, that an application designed for the wireless paradigm will give you. To have
value, wireless applications must provide seamless connection to your database and information repositories.
Screen drawing tools will not allow you to create data intense, dynamic applications. The web is largely used for
marketing and therefore is mainly a display medium (like television), wireless is a two way communication medium
(like 2-way radios or telephones). Use technology that understands this medium and allows you to take full
advantage of it. Now is the time to start your first wireless application!

For futher information

please contact us at:

AVIDWireless
7750 N. MacArthur #120-340
Irving, Texas 75063
972-401-3655 888-772-4570
[email protected]
www.avidwireless.com

Copyright © 2001 AVIDWireless / VoiceDataWare Inc. http://www.avidwireless.com Page 11 / 14

7750 N. MacArthur Blvd., #120-340, Irving, Texas 75063 Ph. 888-772-4570/214-853-4646
 Successful Wireless Projects in 8 Easy Steps

Appendix A – Code listing for SeasonToDate screen object

package com.avidwireless; // your package name appears here

import java.io.*;
import java.util.*; // uncomment for Vectors, Hashtables
import java.text.*; // uncomment for NumberFormats
// Custom classes
import com.voicedataware.*; // for our AVIDRapidTools classes

/**
* SCREEN: SeasonToDate<p>
* PURPOSE:
*
* MODE: The allowable values for mode are:<p>
* None - We do not care about mode for this screen it will all be handled the same<p>
* RESULT: The form will return these result codes:<p>
* Style - sends the user to the style inquiry screen<p>
* Program - sends the user to the program inquiry screen <p>
*
*/

public class SeasonToDate extends ARTMain implements Serializable

{
// EVERY form defines the NAME constant which points to their correct name
public final static String NAME = "SeasonToDate";

/* Static constants for this screen. Typically used for items to be initialized once*/

static private final int debug = 1; // our debug level (Apps are 1)

/*
* Instance fields. Beware that there is a single instance per application, not per user.
* Users run as multiple threads in a single instance, so instance fields are common
* to all users.
*/

//################################################################################

/**
* This will display our information to the user at their display. It can read
* session variables using .getSessionxxx methods, and any URL parameters with
* getScreenFieldxxx methods.
*
* @param user The instance of our user, with session, cookies and the current display device.
* @param mode Our current mode. It may be "None" if this doesn't really matter
*/
public void display (User user, String mode)
{ // begin display section
String myName = NAME+".display";

avidUtil.debugln(debug,myName,"SCREEN="+NAME+" MODE="+mode);

long classID = getSessionLong(user,AVIDInventory.Session.CLASSID);

String sKU = getSessionString(user,AVIDInventory.Session.SKU);
String itemDesc = getSessionString(user,AVIDInventory.Session.ITEMDESC);
String deptDesc = getSessionString(user,AVIDInventory.Session.DEPTDESC);

float sales = 0f;

float receipts = 0f;
float avgSales = 0f;

NumberFormat dollarFormat = NumberFormat.getCurrencyInstance();

// Open the Grand Totals table

AVIDInventoryDB.grandtot grandtot = new AVIDInventoryDB.grandtot(avidDB);
AVIDInventoryDB.iteminfo iteminfo = new AVIDInventoryDB.iteminfo(avidDB,
grandtot.getDbConn());
AVIDInventoryDB.items items = new AVIDInventoryDB.items(avidDB, grandtot.getDbConn());

if ((!grandtot.getDbConnStatus()) || (!iteminfo.getDbConnStatus()) ||
(!items.getDbConnStatus())) // test if we have a valid connection
{ // we have don't have a valid database connection

Copyright © 2001 AVIDWireless / VoiceDataWare Inc. http://www.avidwireless.com Page 12 / 14

7750 N. MacArthur Blvd., #120-340, Irving, Texas 75063 Ph. 888-772-4570/214-853-4646
 Successful Wireless Projects in 8 Easy Steps

errorPageLog(user, "STD-01", "Database Problem",

"We had a problem opening the database.", attrNormal);
avidUtil.debugln(debug,myName,"Database problem opening the database");
grandtot.closeDB();
return;
} // end dont have a valid database connection

if (iteminfo.findBy(classID))
{ // find class info
sKU = iteminfo.getSku();
avidUtil.debugln(debug,myName,"Found sKU information for "+classID);
} // end find class info
else
{ // did not find info
avidUtil.debugln(debug,myName,
"Could not find iteminfo Information for class id"+classID);
user.display.addText("Could not find Information for "+classID);
} // end did not find info

if (items.findBy(sKU))
{ // find class info
itemDesc = items.getDesc();
avidUtil.debugln(debug,myName,"Found itemDesc information for "+sKU);
} // end find class info
else
{ // did not find info
avidUtil.debugln(debug,myName,"Could not find sKU Information for sKU "+sKU);
user.display.addText("Could not find Information for "+classID);
} // end did not find info

user.display.beginPage("YearToDate", "YearToDate", attrNormal);

user.display.addTitle("Year To Date", attrCenter);
user.display.addHorizontalLine(false); // add a line to HTML displays

if (grandtot.findSTD(classID))
{ // get the information from the Grand_totals table
avidUtil.debugln(debug,myName,"Found YTD information for "+classID);
sales = grandtot.getSales();
receipts = grandtot.getReceipts();
avgSales = grandtot.getPerWeekUnits();

if (mode.equals(AVIDInventory.Modes.SKU))
{ // add the Entry button for returning to the Style Inquiry screen
user.display.addText(user.display.underline(sKU+" "+itemDesc), attrLeft);
} // end add the entry button
else
{ // mode is dept
user.display.addText(user.display.underline(deptDesc),attrLeft);
} // mode is dept

user.display.addText("YTD Sales : "+dollarFormat.format(sales), attrNormal);

user.display.addText("YTD Receipts : "+dollarFormat.format(receipts));
user.display.addText("YTD Avg Sales/WK: "+dollarFormat.format(avgSales));
} // end get the information from the Grand_totals table
else
{ // did not find STD info
avidUtil.debugln(debug,myName,"Could not find YTD Information for "+classID);
user.display.addText("No YTD information found for "+classID);
} // end did not find STD info

grandtot.closeDB();

user.display.beginForm();

user.display.addSubmitButton("Reports", AVIDInventory.FieldNames.SUBMITBUTTON,
"Reports", Attribute.BUTTONTYPE_ACCEPT);
if (mode.equals(AVIDInventory.Modes.SKU))
{ // add the Entry button for returning to the Style Inquiry screen
user.display.addSubmitButton("SKU", AVIDInventory.FieldNames.SUBMITBUTTON,
"SKU", Attribute.BUTTONTYPE_ACCEPT);
} // end add the entry button
user.display.endForm();
user.display.endPage();

Copyright © 2001 AVIDWireless / VoiceDataWare Inc. http://www.avidwireless.com Page 13 / 14

7750 N. MacArthur Blvd., #120-340, Irving, Texas 75063 Ph. 888-772-4570/214-853-4646
 Successful Wireless Projects in 8 Easy Steps

} // end display section

/**
* This is called for a POST of data. It will retreive the field data using .getScreenField.
* It will contain the logic to process the input data.<p>
* It will return a the result String (the return from our submit) which will tell the
* next screen to process. If we display information on this method or if
* there is an error and we have displayed an error page then we return null.
*
* @param user The instance of our user, with session, cookies and the current display device.
* @param mode Our current mode. It may be "None" if this doesn't really matter
* @return The Result code string if successful or null if there was an error and
* we shouldn't be going on.
*/
public String submit (User user, String mode)
{ // begin submit
String myName = NAME+".submit"; // set our method's name for errors

avidUtil.debugln(debug,myName,"SCREEN="+NAME+" MODE="+mode);

String buttonPressed = getScreenFieldString(user, AVIDInventory.FieldNames.SUBMITBUTTON);

String result = AVIDInventory.Results.REPORTS;

if (buttonPressed.equals("SKU"))
result = AVIDInventory.Results.ENTRY;
return result;
} // end of submit
} // end of SeasonToDate

Copyright © 2001 AVIDWireless / VoiceDataWare Inc. http://www.avidwireless.com Page 14 / 14

7750 N. MacArthur Blvd., #120-340, Irving, Texas 75063 Ph. 888-772-4570/214-853-4646