Grab-and-Go Docking

Overview of grab-and-go docking.

In addition to the changes directly related to the tablet form factor, one design feature is the user's ability to pick up the device and take it from a docking station or port at any time. This means that devices other than the digitizer and the display may be unplugged with no prior warning.

One class of devices is input peripherals, such as a mouse, trackball, keyboard, or even additional external digitizer. Users must be able to continue to use their Tablet PC with only a tablet pen. For example, if you have a full-screen mode, ensure that users can easily discover a pen action to return to a window environment. At a minimum, the application should require a press-and-hold action to display a shortcut menu. Optimally, the application would require only a simple pen movement or tap to accomplish this.

Also, avoid explicit testing for input peripheral presence to minimize pen-only functionality. Users should be able to operate their Tablet PC by using nothing but a tablet pen, regardless of any other devices that are present.

Connectivity to mass storage devices, such as hard disks in docking stations, CD-R drives, 1394 hard disks, and so on, also presents a challenge for the software designer. Any device to which the user is currently writing data or from which the user is reading data can suddenly be disconnected. Design fallbacks for all these actions, preferably those that do not require user interaction and are self-healing when device connectivity is restored.

Some of these grab-and-go scenarios are common to laptop users, who are used to contemporary docking needs. However, the Tablet PC grab-and-go feature introduces new types of problems, such as unplugging from external keyboards. Applications are no longer be considered efficient if they fail in these common Tablet PC scenarios.

Disconnected Networks and Disks

Both wireless networking and grab-and-go docking mean that network connections and external hard disks can become disconnected without warning. Although this has always been a concern of desktop applications, these potential problems become much more common on Tablet PC.

Although each application has its own unique constraints on network behavior, you should consider several features:

• Implicit online/offline switching. If your application has two separate modes for online and offline behavior, take advantage of the network presence detection in Microsoft® Windows® XP and switch between them automatically, without requiring user action or approval.
• Background and cached file writing. Rather than locking the user interface when writing to a file, save immediately to a known local file and attempt to update the real file in the background.
• Delayed file writing. You add functional dexterity if you allow users to save and close a file without the storage available. Prompt users for actions only when necessary (for example, if the online and offline versions become unsynchronized).

In addition, cache copies of embedded or linked data. At a minimum, keep a static representation of all objects in your file—a bitmap, for example. That way, if the source disappears, users can at least perform basic rendering.

Continue to design your software to account for sudden disconnection from network resources—including the capability to automatically or manually store data on a local device—and use timeouts on all network actions. Some considerations in this regard include:

• Handling sudden removal and addition of network connections and peripherals.
• Implementing operations that can recover if problems arise, such as load or save operations to a USB, 1394 hard disk, or CD peripheral. Then, when such operations are interrupted with a docking or undocking action, they can be restarted later.
• Using best practices for network connectivity. Your application should operate seamlessly in situations in which networks are temporarily unavailable or set or reset themselves. For example, your application should:
  • Handle connectivity transitions.
  • Provide auto reconnection that does not require restarting the application.
  • Give clear feedback of network availability so that the user is aware of this state.
  • Have the ability to be used offline. It is not unusual for a wireless network connection to be intermittent or for users to be offline for a short time without realizing it. Your application should behave seamlessly in these situations. The application should not stop responding while the network is unavailable.
  • Implement automatic synchronization capability when a connection is reestablished, if your application needs to synchronize offline and online data. It is tedious for users to have to remember the explicit steps for synchronizing. This is unnecessary if your application can detect a reconnection to the network and can run automatic data synchronization.