The target of a LEAP is a single character. Should the cursor land to the right or to the left of this character? Placing the cursor to the left of the character is correct only if you intend to insert at that character location. Placing the cursor to the right of the character is correct only if you intend to delete that character. The computer, it would seem, has to know your intentions before it can position the cursor properly.
For insertion, consider instead the old-fashioned cursor that forms a rectangle about or an underline beneath the letter. When you LEAP to a letter, the cursor should land on the letter itself. (The cursor does not interfere with the readability of the letter; see Figure 5.9.) Now you can insert or delete at that location without ambiguity. The block cursor allows you to more accurately indicate where insertion and deletion will occur than does the standard, between-character cursor.
Figure 5.9. (a) The cursor has been placed by a GID move or a LEAP to the letter l in slat. (b) If you backspace, you get sat. (c) But if you had typed a p, you'd get splat. Note that in (a), the insert and delete portions of the cursor are both on the l, indicating that you can either insert or delete there. After deleting (b) or inserting (c), the insert and delete portions of the cursor have separated, still indicating where insertion and deletion will take place. Using a cursor-moving (arrow) key also causes the cursor to separate.
This solution engenders another problem: Suppose you had the word tongs, with the cursor on the o, and you type the letter h. You get thongs. But where should the cursor go? Again, you seem to need to know the intent of the user: If the cursor is on the h, does it indicate whether that letter will be the insertion point or the deletion point? Deletion should be the inverse of insertion, so that a tap of the Backspace key should delete the h, returning the word to tongs, but if you type another letter, say r, it should displace the o to the right of the h to make the word throngs. It would seem that an on-character cursor also has to have precognition to be in the right place.
The solution to the problem is this: When you move the cursor, it lands on a single character. As soon as you type or delete, the cursor splits into two parts that are associated with two consecutive characters, as shown in Figure 5.9: The first character has the delete cursor on it, the second has the insertion pointer wrapped partially under it. One part of the trick is to have a two-part cursor designed so that when the parts coalesce as they must, after a LEAP or other cursor movement it is graphically clear that they both reside on the same character independently. This may all seem complicated when written out in detail, but the LEAP cursor is easier for a newcomer to learn than is the conventional cursor of Figure 5.7. All that you have to tell a learner is what the selection and insertion markers look like, that the Delete key deletes the selection, and that what you type appears at the insertion marker.
The characters are consecutive rather than adjacent, for although two consecutive characters are usually adjacent, they are not when the first of the two is at the end of a line. For left-to-right languages, the delete cursor is typically to the right of the insert character; for right-to-left languages, it is the other way around. For vertically oriented languages, the insert cursor would be below the delete cursor, and they would alternate directions on each line for boustrophedonic scripts.
Target acquisition is easier when using a GID with the two-part cursor, because the targets, or characters, are larger than the spaces between them, and the hot region is easier to visualize. (The hot region for the PARC cursor extends about halfway into each character, on both sides of the space between them, but nothing visually delineates the boundary, making the target seem smaller. In practice, many users try to place the cursor between characters, incurring the Fitts' law penalty that goes along with small targets.)
As we have discussed, naive users sometimes have trouble understanding how the standard, between-character, cursor works: a transient phenomenon involving an interface detail that is so familiar that it is rarely, if ever, questioned. With the two-part cursor that condenses on a single character after a cursor move, the initial confusion about which character a cursor points to disappears, solving the original problem.
At times, it may be advantageous to limit the range of a LEAP. A limited search can be made by (1) selecting the region to be searched; (2) selecting a command or current selection, as discussed in Section 5-2-1, that limits the next LEAP to that region, which becomes the old selection; (3) and then using a LEAP. What must not be done is to create a mode that restricts LEAP. When the user is not aware of that mode, using LEAP will be very frustrating, and he will not be able to find things he has always otherwise been able to find. Canon introduced a concept called "Local Leap" on the Canon Cat, and it caused precisely the problems that a student of this book would predict.
Another function needed when LEAP is implemented is LEAP AGAIN, which simply performs a LEAP in the same direction as the most recent LEAP, to the next instance of the same pattern. In SwyftWare and the Canon Cat, searches usually took the form of LEAPing to a pattern and then using LEAP AGAIN repeatedly until the desired instance was found.
LEAP unifies searching and cursor motion in text, recalling that text includes spreadsheets, labels in graphics, and any other use of alphanumeric characters. After a short while using LEAP, the user becomes unaware of LEAPing, just as a touch typist concentrating on creating content is unaware of the mechanical motions of typing. When you want to put a target on your display, you LEAP to it; you do not stop to ask where in the system's universe of content the target is. You do not track down any hierarchies or open folders; you LEAP directly to what you want. But when people accustomed to standard file structures first encounter a system with LEAP, they often try to think in terms of where the desired item is hierarchically, searching for it by trying to find the general location and then working their way in to the specific instance they seek. If the universe over which you are searching has been properly indexed, it makes no difference to the user whether the item searched for is in memory, on local or networked mass storage, or on a local or global network.
When considering searching methods, the observations of Landauer and his colleagues are pertinent. They have shown that the most common forms of advanced text search, where the Search key is specified in terms of Boolean combinations of strings or by means of regular expressions, are inferior to a full-text search mechanism. The latter is both faster and easier, and users find a higher proportion of the relevant items for which they are searching (Landauer 1995). LEAP, on the basis of both GOMS and efficiency measures, is superior to the search-launching methods used by Landauer and should therefore show an even greater advantage.