|[ directory ]|
A gauge is a visual display of a value. A gauge can be editable (an interactive gauge) or not editable (a noninteractive gauge). A typical use for an interactive gauge is enabling the user to set a volume level; a typical use for a noninteractive gauge is to give the user feedback on the application's progress through a long task. Figure 8.13 shows an interactive gauge on a mobile phone.
There are three types of noninteractive gauges: a progress bar, an incremental gauge, and a continuous gauge. A typical use of a progress bar is to show the user the device's progress through a file transfer when the file's size is known. It can show how far the task is from completing.
A typical use of an incremental gauge is to show the user the device's progress through a file transfer when the file's size is not known. The device can tell it is receiving data, so the gauge can provide feedback to indicate that the task is progressing, but it cannot tell the user how far it is from the end of the task.
A typical use of a continuous gauge is to let the user know the device is using the network to request information. The device cannot tell whether the server is making progress toward getting the requested information, nor can it tell when the requested information will arrive. It merely provides feedback that the application is still running and the device is not broken.
An interactive gauge enables the user to set a value. For example, an application could use an interactive gauge to enable the user to enter a value that controls the pace of a game. An interactive gauge has a range of values from zero to an application-defined maximum value.
For example, consider an API that controls a volume level by accepting a parameter expressed as a percentage (0 to 100) of maximum. Most devices don't have 100 distinct volume levels. It would be reasonable to use a gauge to represent a smaller range that is then mapped onto the 0 to 100 range expected by the API. To do this, the application would create a gauge with a maximum value of, for example, 20. It would then map this into the 0 to 100 range by computing (gauge-value * 5).
There are two reasons to keep the range of values small. First, it will help to keep the range of values closer to the number of distinct visual states possible on most devices. The closer these values are, the fewer values share the same visual representation. This will make your gauge appear to be more responsive.
Second, it will improve application usability. In many cases, the only means for the user to modify the value of an interactive gauge will be to press a button to increase or decrease the gauge's value by one. Keeping the range of values relatively small means that the user will probably have less work to do to change the value of the gauge.
A progress gauge is a noninteractive gauge with a definite range. The application must supply a maximum value. The device maps the value of the gauge onto the display so that the user can see how close the current value is to the maximum value. Figure 8.16 shows a progress bar.
The recommendations for progress bars are similar to the recommendations for interactive gauges. The difference is that MIDP implementors do not give users a way to change the value of a progress bar. Instead, the MIDP implementation updates the display of the progress bar as the application changes the gauge value.
8.8.3 Incremental Gauges
An application should use an incremental gauge when it can detect that it is making progress but does not know when the task will end. For example, if your application is receiving an unknown amount of pushed data, you can provide feedback that data is coming in, but not on how much longer it will be until the data transfer is done. In this case, an incremental gauge is appropriate. Incremental gauges do not have a defined range, so the application supplies the constant INDEFINITE as its maximum value.
INCREMENTAL_UPDATING and INCREMENTAL_IDLE are the two states of an incremental gauge. The MIDP Reference Implementation uses the images shown in Figure 8.17 for these states.
Continuing with the example of receiving pushed data while the application receives data, you should use the incremental gauge's INCREMENTAL_UPDATING state. You would then update the gauge after each time your application receives a certain amount of data. You should change to the incremental-idle state when you have finished receiving the message and are closing connections, or preparing the message for display to the user.
Like a progress bar, the state of an incremental gauge changes in response to the application. Unlike a progress bar, however, the incremental gauge will not supply a value in a definite range. Instead, the application merely indicates that progress has been made.
8.8.4 Continuous Gauges
An application should use a continuous gauge when it cannot detect that it is making progress but needs to let the user know that the application is running and the device is not broken. For example, the MIDP Reference Implementation uses a continuous gauge when the user installs a MIDlet suite. When the installer contacts the server to download the JAR or JAD file, there is no way to know whether the server is making progress toward sending the requested file or how long the interaction will take. Continuous gauges do not have a defined range, so the application supplies the constant INDEFINITE as its maximum value.
CONTINUOUS_RUNNING and CONTINUOUS_IDLE are the two states of a continuous gauge. The MIDP Reference Implementation uses the images shown in Figure 8.18 for these states.
Continuing with the example of getting a MIDlet suite's JAR or JAD file, while the installer contacts the server and waits for a reply, it uses the continuous gauge's CONTINUOUS_RUNNING state. After the file is downloaded, the installer uses the continuous gauge's CONTINUOUS_IDLE state while finishing the installation.
For example, in Figure 8.18, notice that Duke is waving his head for the CONTINUOUS_RUNNING state. The animation shows that activity is occurring, but it doesn't imply any particular progress toward the goal. The figure also shows Duke in the CONTINUOUS_IDLE state.
Any time an application uses a noninteractive gauge, it should provide additional information to help the user understand the activity the gauge is tracking. If the activity is interruptible, the user should have the opportunity to stop it.
|[ directory ]|