In FileMaker Pro, the same action will delete a data record in Browse mode, or an entire data layout in Layout mode. I think that this is appropriate: In Browse mode the primary unit on which one operates is the record, while in Layout mode it is the layout. Nevertheless, it is possible to get confused and delete a layout when you are trying to delete a record. I have a possible solution to this problem, employing a user interface technique that I think is being underused.
I don't mean to imply that Claris overlooked this danger in designing FileMaker Pro. It employs all the common techniques by which an application program protects its users from their own mistakes. There are cues that tell you what mode you're in at any given time. There are warning messages that tell you what you are about to delete, and that let you reconsider. And if you do delete something accidentally, the application gives you visual feedback that you did so, and lets you undo the deletion.
None of these techniques quite solves the FileMaker Pro deletion problem.
Knowing what mode you are in is helpful, but modes can overlap, as in this case. There are actions more commonly used in Browse mode that are nevertheless also available in Layout mode. Execute a sequence of these actions while in Layout mode and your fingers will be telling you that you are in Browse mode, despite what the static visual cues tell you. If the next step in the sequence is to delete a record, you will be pulled toward that overloaded delete action with a force proportional to the inertia of the action sequence. You'll do it.
At that point, of course, you'll get a warning message. Unfortunately, you'll be expecting one. FileMaker Pro warns users before deleting records in Browse mode as well as before deleting layouts in Layout mode. So you won't read the message. The information conveyed by a warning message when a warning message is expected is the expected warning message. So that won't stop you.
Once you've deleted the layout, the screen will probably change radically and you will probably recognize your error and you will probably have the sense to select Undo before you do anything else, and if you come out on the right side of all those probabilities, you'll be saved. But having the Undo operation be the only functioning safeguard against a common error is not good.
Things could be improved by calling the user's attention to what is about to happen as forcefully as the actual deletion calls attention to itself. I think a system gesture would do that. What I mean by a system gesture is a visual movement or change that carries a message and also calls attention to that message. For example, when a window shrinks to an icon, animating that shrinking not only shows where the icon went, but it draws the eye to the point. Graphical user interfaces have a lot of user gestures, but not enough system gestures.
A good system gesture can communicate on several levels at once, like a gesture in the John Schlesinger movie Pacific Heights.
Melanie Griffith has tracked homicidal psychopath Michael Keaton to his hotel lobby, where he now approaches the desk near which she sits in a chair, her back to him, sipping a drink. It's a tense scene: She must stay long enough to overhear his room number, but get away before he gets his message, which will tell him she's there. We hear him say his room number, see him get his message, read it, and turn. Then we get the gesture.
In her glass, sitting on a table, the top ice cube slips off the bottom one with a clink.
Objectively all this gesture says is that she's no longer there to hold the glass. On another level, the falling ice cube in tight focus for less than a second says something about critical instants and events outside our control, and it also conveys a time sense and defines a time interval.
I have nothing this artful in mind, but a simple color or shading change might be an adequate gesture for deletion in FileMaker Pro. The point would be to replace the textual warning message with a gesture that shows the about-to-be-deleted object in a state viscerally recognizable as imperiled. Color it red, fade it to gray, burn a (visual) hole in it, tear off a corner: Some of these would be too expensive, but some such gesture ought to work, and it could be useful in any deletion operation. We already have conventions for showing if an object is selected or deselected, open or closed. Why not add an imperiled state?
Copyright © 1991, Dr. Dobb's Journal