MAS.632 Conversational Computer Systems - MIT OpenCourseWare
MAS.632 Conversational Computer Systems - MIT OpenCourseWare
MAS.632 Conversational Computer Systems - MIT OpenCourseWare
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
114 VOICE COMMUNICATION WITH COMPUTERS<br />
when telephone exchanges were referred to by a name instead of number.6 This<br />
alphabetic labeling tends to get carried over into other public keypad style<br />
devices such as automated bank teller machines. But there are two problems<br />
with this arrangement: each key maps into three letters (see Figure 6.3), and the<br />
letters "Q" and "Z" do not appear on any key of the telephone.<br />
For the two missing letters several options are in use. Both letters may be<br />
mapped to the otherwise vacant 1 key; this seems the most common alternative.<br />
They are also sometimes mapped to the 0key. For the implicit key-to-letter decoding,<br />
described below, they can be assumed to occupy the keys on which they would<br />
appear if they had been left in the alphabet. In this scheme, Q appears invisibly<br />
on the 7 (PRS) key and similarly Z appears on the 9 key.<br />
Alphabetic input techniques may decode the three-to-one letter-to-key mapping<br />
either explicitly or implicitly. Explicit mapping requires the user to type two keys<br />
for each letter; the first key chooses a group ofthree letters and the second selects<br />
one from this set. The second key may be constrained to one ofthe set 1,2, or 3 or<br />
better could be any key with the column position of the key selecting the first,<br />
second, or third letter. For example, the letter H might be selected by entering 4<br />
5; 4 selects the GHI set, and 5 from the middle column selects the middle letter<br />
from the triplet.<br />
The implicit letter mapping technique accepts the confusability of the user's<br />
input and attempts to decode the input by matching it against the set of valid<br />
inputs. For example, while selecting a name from a menu (see Figure 6.4), the<br />
user is really picking one of a set of names, each of which may have a distinct<br />
touch tone "spelling" uniquely specifying that each letter is not necessary. In fact,<br />
in the illustrated example, four of the names would be uniquely specified after the<br />
first touch tone. (One might, however, wish to gather all five digits to confirm that<br />
the user was not trying to select a name not on the list.)<br />
Explicit spelling requires twice as many keystrokes but is required for some<br />
tasks, e.g., if a new subscriber to a service is asked to spell his or her last name to<br />
create a new account. In the case of spelling to make a selection from a list,<br />
implicit character mapping may be quite adequate, faster, and easier to explain<br />
to the user; examples include looking up a last name in an electronic database,<br />
spelling a street name, or logging in to a computer account.<br />
A problem with implicit spelling is the degree of overlap between the items<br />
being selected and their keypad equivalent. For example, the login names "Leo"<br />
and "Ken" are both spelled "536."In such a case, the collision must be detected by<br />
the system and an alternate selection mechanism invoked, e.g., "Ifyou mean Leo,<br />
press one; if you mean Ken, press two." (Note that this is a menu and could be<br />
either enumerated or temporal).<br />
Clearly the degree of overlap between the items is a function of the particular<br />
set of items, and therefore the confusability of implicit spelling will vary from<br />
6 Where I grew up in Chicago we were in the EDgewater exchange, although this con<br />
vention is no longer followed.