This chapter is from the book
This chapter is from the book
This chapter is from the book
What to Do Without a Keyboard
Although iPad and iPhone have onscreen keyboards and the ability to use a wireless keyboard, as the designer of a mobile database solution, you should recognize that particularly for speedy touch-typists, the onscreen keyboard slows them down. For that reason (as well as the fact that not everyone carries a wireless keyboard with them), you can improve your mobile database solutions by constantly looking for what you can do without a keyboard.
When you don't have a keyboard, you can present tappable objects, such as radio buttons and checkboxes, wherever possible. These work very well in a touch environment, and, in fact, most people can handle them as quickly or even faster than a skilled touch-typist can enter data with a keyboard.
But there is one point to remember: In a desktop environment where a typist has a keyboard available as well as a mouse, the physical transition from hands on the keyboard to a hand on the mouse can slow people down. What this means to you is that you might have to think about having two interfaces for heavy dataentry portions of a database. You use one version for a desktop environment with a keyboard and mouse, and you use the other for a touchscreen environment.
Remember that this really becomes an issue only for intense data entry and for speedy typists. But even if it is an issue, FileMaker helps you out a good deal: Because the interface (layouts in FileMaker terms) is relatively independent of the data that it handles, you can switch layouts quickly and easily (and even automatically).
So the point remains for a mobile database designer: Look for every opportunity to convert data entry into touch.
And while you are looking for new opportunities to include a touch interface, there are two other points to consider. The first is worth mentioning, but it rarely causes issues for users. When you add touch to your interface for a database that is also shown in FileMaker Pro, you wind up with two ways of accomplishing the same task: a mouse-driven way and a touch-driven way. The experiences are so different (and people are now so used to them) that this just is not an issue.
What can be an issue is that because people are usually holding a mobile device in their hand, they can easily tap the screen inadvertently. Just as a stray mouse click on a desktop-based interface usually does not pose a problem, a stray tap also does not hurt in most cases. On the desktop, a stray mouse click that just happens to click on a Submit or OK button can do damage. On a mobile device, you close the mobile equivalents or dialogs or alerts by tapping somewhere outside the alert; there is normally no Cancel button. People soon learn this, but you might incorporate it into your design by remembering that dismissed dialogs might have been inadvertently dismissed, so you might want to re-confirm any action that is dramatic.