Mankind are more disposed to suffer, while evils are sufferable, than to right themselves by abolishing the forms to which they are accustomed. ?span>Thomas Jefferson, Declaration of Independence of the United States of America Because the restriction of file name length to 8 characters in earlier systems was truly dreadful, the 31-character maximum length offered by the Macintosh looked like heaven to many users. But this modification was just a different-size straitjacket. Aside from the real limits of the hardware, an interface should have few, if any, fixed-length limits. An interface should use dynamic memory allocation, linked lists, hashing, or whatever techniques seem best but should never present a user with software implementation limitations, such as "you can have up to 255 categories" or "paragraphs can be up to 32,000 characters."[2] [2] A word processor I once used quite a while ago had this paragraph size limit. I exceeded it as soon as I inserted a photograph into a paragraph; when I spoke to the designers, they admitted they had never thought of that. The moral: Never put in a fixed limit because it makes the software easier to write; it will always be too small.
What is a file name? From the user's perspective, it is a handle with which to grab a file. As we know from long experience, file names do not work as one would expect; they are an impediment when you want to save, futile when you want to find. Let me be more specific: File names are bothersome when you are about to save work, because you have to stop in the middle of your activity, which is trying to store your work away, and invent a file name.[3] Creating names is an onerous task: You are required to invent, on the spot and in a few moments, a name that is unique, memorable, and within the naming conventions of the system you are using. Furthermore, at that moment, the question of a file name is not your locus of attention; preserving your work is. File names are also a nuisance when you have to retrieve a file. The name you thought up was probably not particularly memorable, and you probably forgot it after a few weeks (or less). I, for one, can rarely remember a file name unless it is quite recent; even looking through lists of file names is frustrating. Just what is in that file that is labeled "notes ybn 32"? The name seemed so clever and memorable when I created it. Then, too, many files are nearly the same. How many different, creative, readily remembered names can you think up for letters to your accountant about last year's taxes? Filing them by date may be useful, but how many of us remember that the letter about the deduction for the company truck was written on August 14? [3] This is in the context of present systems. You should never have to explicitly perform a save in future, humane systems.
Having to name files increases the mental burden on the user. Giving a file a name does nothing more than add a few characters to the file, and you are required to remember the file by that one tiny portion and by nothing else. I count this as one of the major horrors visited upon us by conventional computer systems. Many information appliances have also adopted this inhumane methodology. There should be no distinction between a file name and a file. A human mind can more effectively use a fast, whole-text search engine, so that any word or phrase from the file can serve as a key to it. (Eventually, we'd want more: A request for "a letter about dragonflies" would cause a search that looked for something that had the form of a letter and looked not only for the word dragonfly but also for related terms or expressions, such as Odonata in case dragonflies had been referred to by their scientific name and if no instances of such letters were found, the search would look for nonletter documents with that content, and so forth, extending out to networked computers and to the Internet.) You do not remember the content of "Letter 12/21/92 to Jim" when you see that title, but you do remember that you once wrote to Jim about the blue Edsel that ran across your eyeglasses. A search on Edsel is likely to find only one or two entries on your whole system unless you are an Edsel fancier, in which case you would probably choose another pattern on which to search. An unlimited-length file name is a file. The content of a text file is its own best name. Graphics and sound files often require names; Section 6-2 discusses an approach that avoids the memory burden that traditional file structures impose for nontext files. Aside from nontext files, given a fast whole-text search, file names one whole species of unnecessary entities can be eliminated. With the removal of file names go all the mechanisms for dealing with file names, such as directories of file names, rules for editing file names, and syntactic restrictions on file names. When file names are eliminated, a significant mental burden and much internal machinery machinery that is currently part of what you have to learn and what programmers have to implement vanishes. The best interface to a whole-text search is interactive, where you see each found instance in context as it is found. In this interface, as soon as you see what you want, you are there. Some systems present copies of the found instances in the line that contains them (Drori 1998). However, this method is not as efficient as the first kind of search, because you must then perform a second operation to reach the instance itself; for example, you must click on the copy of the desired instance. For users who insist on a system that looks like conventional file structures, there can be a command that creates an "information document" or an extra page at the end of each document when the document is selected and the command applied. The information document or page would contain such information as the date and time the document was created or modified, a revision history, the length of the first document, or whatever information seems of value. The software to implement such a command would have to acquire and store the necessary information invisibly to the user. Various vendors might provide different facilities, depending on user needs. For users who wish to hold on to their old ways, a vendor could even go so far as to create utilities that create documents that look and act just like the annoying directories we now have. Another source of organization, one that is easier to learn and to use than traditional file systems, comes from the inherent hierarchical structure of many natural languages: Words are separated by spaces. Sentences, or sequences of words, are separated by one of a small number of delimiters, followed by a space. (In English, these delimiters include periods, question marks, and exclamation points.) Paragraphs, or sequences of sentences, are separated by at least one explicit Return. Explicit page characters, or page breaks, separate chapters or whatever you wish to call the next level of organization. In a consistent system, page breaks should be characters and, unlike most present systems, they should behave in terms of insertion, deletion, and searching just as any other characters do. As with Return, there may be implicit page breaks to accommodate the fixed length of physical pages, but these are not part of the content.[4] [4] Dr. James Winter, at Information Appliance, further unified the structure by pointing out that English already has the same kind of hierarchical, character-delimited structure proposed for the higher levels of organization.
There is good reason not to stop here in the hierarchy as many present systems do. Documents are sequences of pages separated by document characters, each typable, searchable, and deletable, just as is any other character. There can be higher delimiters, such as folder and volume characters, even section and library delimiters, but the number of levels depends on the size of the data. A set of two consecutive document characters makes a fine delimiter for sets of documents. If more levels of organization are needed, three or four consecutive document characters could be used as delimiters. It can be easier to repeatedly tap the Document key, even four times, than to type such rarely used keys as Folder, Volume, and Library. This convention also prevents an explosion of new keys on the keyboard. It is important for all delimiter characters to have dedicated keys, for otherwise, they would not behave as do all other typable characters. That is, we should not use a keystroke for, say, Return, and then use an Insert Page Break command; we must have a page character. Because the various separator characters would behave exactly as did all other characters, there would be no need to teach users how to do searches for them. An individual who insists on having explicit document names can adopt the personal convention of placing the desired names immediately following document characters. To find a document with the name "Dogs of Asia," you would search for a string that began with a document character followed by Dogs of Asia. Such a search would ignore all instances of Dogs of Asia except those used as document names. If you wanted a directory, there could be a command that would assemble a document comprising all instances of strings consisting of a document character, followed by any other characters, up to and including the first Return or higher delimiter. Eliminating hierarchical file structures does not mean that you have to give up structuring your stored information. Nothing prevents you from creating tables of contents and indexes or putting all of your letters to Uncle Albert and Aunt Agatha on consecutive pages. Nothing prevents you from even putting a heading page (just another document) labeled "Letters to Uncle Albert and Aunt Agatha" in front of them. If that is done, you have created, in effect, a file name but without having added a special mechanism in the software. You can create, if you wish, a hierarchical file structure of your own so that, if you really love file names and hierarchies, you can have them. Structure, as you choose to create it, is part of your content, not part of the interface.[5] Instead of a file-finding facility, you simply use the general search mechanism to find the file names you have squirreled away. You can place a folder name as a document in front of a number of collected files; you can place a volume name in front of a bunch of collected folders. (Your pattern would be a volume character, followed by the name of the volume; such a pattern would eliminate matches to other occurrences of the name that happen not to be labels of volumes.) The absence of a built-in file organization does not prevent you from creating a file that fits your needs and one that, because you created it, you understand. But also, because the system has not been changed in any way, a guest can find things in your structure and, in fact, can ignore your structure and treat it as a flat, unstructured, file. [5] The same is true of file names and menus proposed in this book.
One advantage of filing information as you wish is that the structures were not dictated by the system designers, who may have ideas different from yours. Therefore, you do not have to develop a mental model of what the designers were trying to do. Many users do develop inaccurate models of how systems work; these mental models persist and cause continuing difficulties for those users (Norman 1988). This discussion is not theoretical: On the SwyftWare and Canon Cat products, the elimination of file names, directories, and the various mechanisms usually provided for manipulating them proved one of their most successful features. Users experienced at conventional computer systems sometimes found it difficult to make the transition to content-based organization, but once they had made the transition, the conventional methods soon began to seem cumbersome. Users who started on the Cat were not amused at having to learn the more complex and difficult methods of conventional file systems when they moved to a PC or a Macintosh. To users accustomed to standard GUI practices, the methods outlined here may seem complex by comparison. But the apparent complexity is due to the new paradigm's lack of familiarity and to our having become habituated to the many steps we must take and to the problems we have with the current system. The learning curve has been long surmounted. But when you compare the progress of beginners with the two systems or compare the performance of experienced users, the advantages of the simpler system become apparent. Consider that you have n documents that you want to copy to an external medium, such as a hard drive. With, for example, the Macintosh operating system (OS), you drag the icon of each document to the icon of the drive, and it is copied. In the new paradigm, it seems at first more complicated: You have to find the beginning and the end of each document, select the document, move the cursor to a place on the drive, and then move each document. Recall that in the GUI, you start in the generating application. Your first step is to get to the desktop. You must also know which icons correspond to the desired documents, and you or someone else had to have gone through the steps of naming those documents. You also will have to know in which folder they are stored. So the apparent simplicity is arrived at only after considerable work has been done and the user has shouldered a number of mental burdens. A more efficient method involves an interface invention called LEAP. Assume, as we did for the GUI, that the cursor is in one of the documents you wish to move. With LEAP, the user can select the document with six keystrokes, and without having to look at the screen or recall the document's name. To type six keystrokes takes less time than to drag an icon. LEAP works like this: There are two LEAP keys which lie under the thumbs. LEAP-Down searches forward and LEAP-Up searches backward from the cursor position. Pressing and holding a LEAP key puts you into a quasimode during which whatever you type is used as a search pattern. To select the document you'd LEAP-Up to a document character (LEAP-Up Doc  ). This puts the cursor at the beginning of the document. Then youd LEAP-Down to a document character (the search will find the document character at the end of the document). A tap of both LEAP keys together selects the text. (This is probably most easily done when the LEAP keys are operated by the thumbs, which are otherwise underutilized in typing. See Figure 2.1 for a typical keyboard designed for this use of LEAP. A dedicated Select key is another alternative.) In order that the function be visible, a legend adjacent to the LEAP keys is needed. The legend could, for example, read "Press both LEAP keys together to make a selection." Note that you do not have to watch the display while you select the document. Once a document is selected, the cursor is LEAPed to wherever you want to place the document. When the drive was plugged into the computer, its contents became part of the contents of the system, so no special mechanism is required to find it. A Copy command completes the operation. When selected this way, the document includes its separators. Thus, if the document is moved, it retains its character as a document because the document separators move with it. The same technique used to copy a document or a selection of any length from a character to a set of documents or the entire contents of the system! from here to there is used to move a selection; the only difference is that a Move command rather than a Copy command is given. The process is functionally no more complex than that needed in the GUI. It is often faster, and the number of methods, concepts, and structures that an individual must understand is lower. Consider how you would use the LEAP-based paradigm to put a few selections from different documents together onto a drive, and then consider how you would perform the same task using a GUI. With LEAP, the method is the same as that just described for moving documents to the drive: The selections are found and once found, do not have to be opened, because the concept of opening a document is superfluous?span>selected, as described previously, except using the text rather than document characters at the beginning and end of the selection; and copied into place. In a GUI, the user must first open a new destination document, possibly by using the New command in the File menu of the application; find a document that contains a selection the user needs; open the document; find the selection within the document; select it; use the Copy command; activate the destination document; paste the selection in; activate the desktop; find the next document that has a desired selection; and repeat until all of the selections have been pasted into the destination document. Then you must save the result to the drive by using a dialog box. Even if the complexity of doing any task was the same in either paradigm, the conceptual simplicity of the methods outlined here would be preferable. In most cases, the work required is also far less. |
