Writing Mobile Code Essential Software Engineering for Building Mobile Applications [Electronic resources] نسخه متنی

Defining Performance Objectives

It is hard to reach objectives you do not specifically set because you will never know when you have crossed the finish line. Paradoxically, it can also be said that it is easy to meet ambiguous objectives because almost anything can be rationalized as being "good enough." Depending on your disposition, you can easily fall into one of these traps and either end up over-optimizing areas that do not really matter or ignoring areas that matter critically. Most likely you will land in both of these camps occasionally, choosing to optimize the easy things or areas that present intriguing problems to explore while deferring unpleasant decisions that do not promise easy resolution or seem to be full of nothing but grunt work.

If you are working in a team, matters can get further complicated by the fact that different people will have different beliefs as to what constitutes "acceptable performance." Often these beliefs will be influenced by perceptions about what additional work will be required to fix the problems, who will need to do the work, and whose fault it is that things went wrong. It is comforting to think that we make cold, well-measured, and impartial judgments based on objective facts, but a great deal of evidence in human nature says otherwise. We are all influenced not just by our senses but also by our thoughts about how difficult, fun, challenging, or tedious fixing the problems facing us may be.

The best way to deal with performance objectives is to write them down in your design document. List them explicitly and attach numbers to them. Update them based on what you learn as necessary, but keep track of the changes you make. Having specific stated goals and being explicitly aware of how, when, and why they change through the development cycle is the best way to keep yourself and your team true to these goals.

All Performance Is Subjective

Performance is whatever the end user experiences. If the experience seems sluggish, it is sluggish. If it seems snappy, it is snappy. Because we are building mobile applications for people and not for machines with stopwatches, the art of measuring performance is in coming up with the right metrics to accurately measure the user experience. When in doubt, the final determination as to whether the performance of a mobile application is good enough can be achieved by testing it on real end users and getting their feedback. It does no good to try to explain to an end user why your mobile application really does perform well despite what they think. All performance is subjective.

Instant User Responsiveness

A car with great performance feels responsive; every action provides some immediate feedback to the driver that tells him that the right things are happening. On mobile devices this feedback is most often visual. Sometimes feedback can be provided through auditory or tactile means, as in the case of audibly confirming a button that has been pressed or vibrating a phone to signal an event's occurrence. Regardless of the method of responsiveness, it is critical to give end users rapid acknowledgement that their command has been received and that work is underway to do their bidding.

Have stated goals for always acknowledging a user's commands even if they cannot be processed immediately. Usually any latency of more than 0.5 seconds in acknowledging an end user's command will cause frustration. When there is response latency, it will often cause the user to try the command again, which may create more frustration if the second command toggles the application into an undesired state or is otherwise processed in an unintended way.

A good human analogy is your experience when waiting in line. When you get to the front of a line, you want to be acknowledged by the person serving you. If you are ignored for any length of time, your anxiety goes up quickly. Even if you are asked to wait for a few moments, being acknowledged is far superior to not getting any response from the person serving you. Do not let your application ignore the user even for a short time.

An Example Showing Different Levels of User Responsiveness

Below is a code example showing three different levels of user responsiveness corresponding to clicking three buttons. Each button performs an equivalent four seconds of simulated work. In each case, the user interface is unresponsive for the duration of the work, but the user experience varies greatly between the different cases. This example shows that small things can make a big difference with regard to user perceptions of performance and responsiveness. The following are the three experiences offered by the three different buttons on the sample application:

Bad experience
In this case, the user interface simply locks up for the duration of the work. The user is not told why, is not given any indication for how long the user interface will stay unresponsive, and is not told when the application has become responsive again. This is very frustrating for end users because they have to guess when they can click again. Clicks made while the application is unresponsive are queued up and processed when the application becomes responsive again. This may cause undesirable actions if the user starts poking at the application to see whether it has returned to responsiveness. This example shows thoughtlessly bad design.

Better experience
In this case, the user interface displays a "wait cursor" for the duration of the unresponsiveness. This gives users an indication that the application is presently not responsive and also lets them know when the application becomes responsive again by the disappearance of the wait cursor. With only minimal effort, the user experience has been improved significantly.

Even better experience
In this case, users not only get a wait cursor to tell them when the application is unresponsive, but also get text displayed that explains what is going on. This is more satisfactory for users because they become an informed participant in the process and are given text to read while the work is being done. If there are updates along the way during the work, the user can be kept informed. Keeping users informed goes a long way toward keeping them satisfied. This takes a bit more work than the second example, but if we can give users incremental updates and make them participants in the process it is worth the effort.

Listing 7.3 is intended to be placed into a Pocket PC Form class. Perform the following steps to create and run the sample:

Listing 7.3. Three Different Levels of User Responsiveness

//Place captions on the buttons
private void Form1_Load(object sender, System.EventArgs e)
{
button1.Text = "Bad experience";
button2.Text = "Better experience";
button3.Text = "Even Better";
}
//----------------------------------------
//Example of a bad experience:
//   - No visual indication is given when work is started
//   - No visual indication is given when work is ended
//   - User interface is unresponsive during work
//   - End user is left to guess when the task completes
//----------------------------------------
private void button1_Click(object sender, System.EventArgs e)
{
//Simulate work by pausing for 4 seconds
System.Threading.Thread.Sleep(4000);
}
//----------------------------------------
//Example of a better experience:
//   + A visual indication is given when work is started
//     (wait cursor appears)
//   + A visual indication is given when work is ended
//     (wait cursor disappears)
//   - User interface is unresponsive during work
//   + End user knows when task is completed and UI is responsive
//     again
//----------------------------------------
private void button2_Click(object sender, System.EventArgs e)
{
System.Windows.Forms.Cursor.Current =
System.Windows.Forms.Cursors.WaitCursor;
//Simulate work by pausing for 4 seconds
System.Threading.Thread.Sleep(4000);
System.Windows.Forms.Cursor.Current =
System.Windows.Forms.Cursors.Default;
}
//----------------------------------------
//Example of an even better experience:
//   + A visual indication is given when work is started
//     (wait cursor appears)
//   + Additional text is displayed telling the user what is
//     going on
//   + A visual indication is given when work is ended
//     (wait cursor disappears)
//   - User interface is unresponsive during work
//   + End user knows when task is completed and UI is responsive
//     again
//   + Text tells user what happened
//----------------------------------------
private void button3_Click(object sender, System.EventArgs e)
{
//Give user text that explains what is going on
label1.Text = "Wait! Doing work!";
//Force the UI to update the text
//(otherwise it will wait until it processes the repaint
//message, this may be after we exit this function)
label1.Update();
//Show wait cursor
System.Windows.Forms.Cursor.Current =
System.Windows.Forms.Cursors.WaitCursor;
//Simulate work by pausing for 2.8 seconds
System.Threading.Thread.Sleep(2800);
//Optional Incremental status update
label1.Text = "Wait! Almost done!";
label1.Update();
//Simulate work by pausing for 1.2 seconds
System.Threading.Thread.Sleep(1200);
//Give text indication that we are done
//(Update whenever UI normally updates)
label1.Text = "Success!";
//Get rid of the wait cursor
System.Windows.Forms.Cursor.Current =
System.Windows.Forms.Cursors.Default;
}

It would, of course, be best if the user interface never became unresponsive, but for relatively short delays or cases where work has to be done synchronously there are a great many simple cosmetic things that can be done to keep the user's satisfaction high and anxiety low.

Maximum Wait Cursor Times

There are limits to how long a user can be kept waiting when the user interface is unresponsive. Having a wait cursor display and giving periodic updates to the user can extend this time, but there is still a fundamental point after which users will become annoyed and frustrated by the fact that their application is unresponsive. This time is probably around five seconds in all cases and about a second or two for frequently accessed functionality.

You should specify in your design document not only how you will go about reducing the end user's frustration with wait states but also what the maximum delay tolerances are. Longer delays than these thresholds mean that redesign has to be considered. Stating these goals explicitly ensures that end users gets a consistent experience throughout their use of your mobile application.

Maximum Data Load/Save Times, Startup Times, and Shutdown Times

Often when long-duration tasks are required, they can be pushed to a background thread and can happen without the user being aware of their duration. Background operations are said to occur "asynchronously." However, in some situations specific work is required to be completed before the application can proceed. Common situations where this can occur include the following:

Loading of documents
If the purpose of the application is to work on a document, it may need to be loaded fully before the application can continue.

Exiting the application and saving loaded data
If the user needs to know that the data was successfully saved, this must happen synchronously with the application shutting down.

Startup of the application and initialization of data
As with loading a document, there may be startup information that needs to be loaded and processed before the application can meaningfully proceed.

Delays, even for unavoidable tasks, can be frustrating to the user. In some cases, splash screens, wait cursors, or progress bars can mitigate the user's frustration, but they can only go so far. A 30-second startup time is still a 30-second startup time, and that's going to annoy users of mobile devices who only have 20 seconds of work they want to perform before they put the device back in their pocket. As described in the section above, you should explicitly specify what the maximum delays are that the user can incur in these cases. If your application exceeds these tolerances, you need to make design changes. Are you really loading the minimum amount of data needed to start up? Can the startup data be cached or stored in a format that is quicker to load? If there is network data you require on startup, can this be cached locally? There are all kinds of creative solutions that can be explored for speeding up application performance at these key points, and sometimes you need to rethink previous design assumptions to get the performance your users will expect from an instant-access mobile device.