Best Practices And Considerations For Ca50 Development; Data Collection; Access To Communication Options And The Web Application - Motorola CA50 Developer & User Manual

10 - 12 CA50/UCA Client & Server Developer & User Guide

Best Practices and Considerations for CA50 Development

There are special considerations to take into account when designing Web pages for the CA50 that might not occur
when developing Web pages for desktops or other Motorola mobile devices.
This section addresses CA50 Web page design for data collection and access to the phone and Web based
business applications.

Data Collection

Because of the CA50 display size and the number of keys on the device, the following is recommended:
•
Collect one piece of user input data per Web page.
•
Collect scanner data in a hidden input tag with one scanner input tag per Web page.
•
The spin box input element should be the only input element on a form when it is desired to use the spin box
input element.
•
The select element for a form element can be used and the Select (S) key allows the user to submit the
current selection. The business application developer can define a soft Cancel key so the user can cancel
the selected element.

Access to Communication Options and the Web Application

The <MenuStates> area of the XML profile and the Web application together define the key definitions for the user
experience. The XML profile definitions typically provide access to the communications options (change
walkie-talkie channel, access phone book, hang up phone call ... etc.) and links to Web applications. The Web
application defines keys for use during a Web based business application.
Design Considerations
Design Considerations
Table 10-3
Design Option
Whether users should have access to
the phone and walkie-talkie settings
while they are running Web based
business applications.
Whether users should have access to
Web based business applications
during a phone call.
There are two soft keys available. The business application and communication
functionality must share these keys so ensure the business application does not
define both soft keys or access to the communication options is unavailable. If a
business application screen is a simple Yes or No question presented to the
user, you can define both soft keys for that screen. If the business application is
very simple and does not define any keys, spread the communication options
across both keys for easy access to certain communication functionality.
Be consistent. Through the run of the application, always define the same soft
key (right or left) for the application and the other for the communication
options. The <MenuStates> to look at are those related to an application
running: "AppNoCall" and "AppCallActive". There are two other application
related menu states, AppQuietMode and AppCallOnHold, but it is not
recommended that the soft key functionality be changed for these states. Pick
one key for access to the communications options in the XML profile and leave
the other for the business application to use.
If the business application is very simple (does not need to define either of the
soft keys) define the <MenuState> key definitions as you wish, maybe optimized
for easy access to the phone book. If you want the users to have access to
more complex Web based business applications during a phone call, then look
at the "DesktopCallActive" and "AppCallActive" <MenuStates>. Again pick one
soft key for access to the communications options in the XML profile and leave
the other soft key for the business application to use
Functionality