It is immensely ingenious, immensely complicated, and extremely effective, but somehow at the same time crude, wasteful, and inelegant, and one feels that there must be a better way of doing things. ?span>C. Strachey (speaking not of Windows but of the IBM Stretch computer in 1962) In trying to create a general-purpose interface that takes into account the requirements that we have delineated in the previous four chapters, we find that basic changes from present practice are necessary. Many directions are possible; one tack is to see what we can do within the limitations of the Internet and with the hundreds of millions of computers and information appliances that exist and that are being manufactured today. The most common personal computer hardware configuration is nearly universal at present. By taking a point of view that emphasizes the commonality of physical actions across almost all applications, using the common hardware elements, rather than looking at the vast disparity of tasks, we can develop a general yet simple interface. The list of actions a user can take to influence content be that content textual, graphical, or multimedia can be arranged into a simple taxonomy, which allows us to describe any application's interface in a uniform way. This organization can help guide us in simplifying interface designs. Implementing a universal undo/redo facility also helps to develop a unified interface, eliminating much of the need for individual programs to handle error recovery. Different applications have different commands, and a user cannot in general use the commands from application A while working in application B and vice versa. By liberating commands from applications, we eliminate the inherent modality of applications. The total number of commands a user must master drops dramatically with this kind of unification, primarily because unification rids us of the immense duplication of commands. For example, on the Canon Cat, a total of 20 commands handled word processing; spreadsheet operations; database setup, retrieval, and sorting; calculations; and more. Contemporaneous systems of comparable power required more than 100 commands to accommodate the same set of tasks. In today's environment, the thousands of commands now provided would be reduced to the hundreds. Because not all commands apply to all data types, we would need to apply data-type transformers to objects to create new objects that, whenever possible, can be acted on by the chosen command. Another division that can be erased is between facilities provided, at present, by commercial software and by the user. For example, menus are, at present, operating system objects that are set up by each application. However, they are just text. Is there any reason that a user cannot type up a list of regularly used commands, lock them so that they do not get changed accidentally, stick them up at the top of the display, and treat them like a system-provided menu? To make such menu creation easy, an interface could allow the user to lock and unlock text and to make the text either flow with other content or stay fixed with respect to the display. These are various states of text. Eudora and Microsoft Word are programs that allow you to change the content menus, but you must use a facility that the program provides specifically for that purpose. Here we are discussing the ability to create menus with the same mechanisms you use for creating and editing any text. Menus become content in this view. The next step in the simplification of the interface is to eliminate difficult-to-remember and annoying-to-create file names and system-provided file structures. If given suitable search mechanisms, a user will find both the file names and the provided file structures unnecessary. | 
