Bridge for Handhelds -- Design Notes
- Generally speaking, it is best to allow the user total flexibility, while at the same time minimizing the amount of input necessary to complete an arbitrary task. This is especially true in the case of textual input, which is clumsy and difficult to produce in most handheld designs. As methods to alleviate this, consider storing particular pieces of information semi-permanently so that they do not have to be re-entered unnecessarily. For example, the username of the username/password dialog box could be stored between sessions.
- Classes should be supplied to the handheld on demand from the BRIDGE server so as to minimize the initial install. Because memory is scarce, it is important that each particular device has a configuration that has no code that is not necessary to run the client.
- In the case of a whiteboard or any other large-format picture, it will be necessary to provide additional functionality of zooming in and out so that the entire picture can be accomodated on a small-screen display.
- One-touch buttons are present in most handheld devices - we should explore the possibilities of programming these buttons to interact with BRIDGE in ways that provide the user with very rapid access to commonly used items (i.e. buddy list).
- Personal information management tools should integrate with BRIDGE seamlessly. Contact/address book information stored on the handheld should be easily and readily accessible from within the BRIDGE software for sharing. In this manner, BRIDGE would be more or less an all-encompassing program for the device...
- At present, BRIDGE requires a persistent internet connection in order for users to stay logged in. Obviously this is not possible on a handheld for a number of reasons:
1. Battery life would wear down far too quickly.
2. Internet connection may not always be present.
3. Soft power-offs are common with handhelds, but should not stunt rapid availability of BRIDGE software.
These could be alleviated through the introduction of additional stay-alive software. Smarter software could distinguish between short periods of inactivity and long ones, and depending on context, sever or suspend the serrver connection.
- "Rollback" of unnecessary GUI components during work-intensive modes would be preferable to allow a greater amount of display for accomplishing tasks. They would be able to reappear instantly (like the panels in MS Windows, for instance).
- Users are likely to request updates on projects from their handhelds, as opposed to using the handheld to produce or manipulate large amounts of data. A full desktop is generally going to be preferred for all work requiring significant time and energy -- the handheld therefore should be designed to simply rapidly offer viewing of data, and make editing less of a priority.
- An especially useful feature would be voice recognition so as to make input faster and easier. The problem with this is that it is a major undertaking and rather difficult to produce simultaneously on multiple user displays.
- It is likely that with the preeminance of cell phones and face-to-face conversation, voice will still be the main method of communication while using handheld devices. As such, the handheld should not attempt to replace voice, but to augment it, and to serve as the missing portion of the picture. When certain pieces of knowledge are forgotten, the handheld is available to provide them. When a diagram or photo is more suitable for explaining, the handheld should provide it.
- Users are likely to regard the handheld as unsuitable and unwieldy for accomplishing "real work." More than likely, for a large task, a full-sized keyboard and mouse attached to the power of a desktop or laptop would be more usable. Where then, does the handheld fit in? The handheld serves as an assistant to the desktop by not attempting to replace its functionality, but by extracting the vital qualities of objects and making them accessible while away from the stationary computer.
|