Xref: utzoo comp.sys.mac:16790 comp.editors:178 Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!aramis.rutgers.edu!constance.rutgers.edu!gaynor From: gaynor@constance.rutgers.edu (Silver) Newsgroups: comp.sys.mac,comp.editors Subject: Re: Idea for new MacIntosh Editor Message-ID:Date: 5 Jun 88 06:10:08 GMT References: <5024@batcomputer.tn.cornell.edu> Distribution: comp Organization: Rutgers Univ., New Brunswick, N.J. Lines: 92 > The problem, I soon realized, was the lack of an internal logic, an > ideology of editing, or better yet, an entire ideology of the user > interface. The MacIntosh has addressed this need admirably, but no > one, as far as I can tell, has yet implemented an editor entirely in > conformity with the MacIntosh philosophy. Indeed, the MacIntosh-style interface (viz Xerox'x PARC interface, I believe) is noted for its organization and consistency. Point for Apple. > One of the more confusing aspects of using the MacIntosh for the > beginner is the complexity of the hierarchical file structure. > [Avoid confusion by] elminating all such computereese concepts. This particular example is a particularly bad choice of a `confusing computereese concept'. Tree-structured hierarchical directory structures are not very confusing. It even has a real-world correspondence in envelopes, manilla folders, desk drawers, etc. Just because an idea requires learning does not make the idea confusing or unsound. > ... old documents are simply left lying on the desktop at full size > so the user can tell which is which. Havoc surely ensues for any non-trivial number of documents. I rarely let a directory contain more than 20 or 30 files, because I have a lot of trouble dealing with more than two handfuls of objects at once. > Every keyboard is slightly different from every other, and it just > gets too confusing to remember. Too true. It's amazing that keyboard layouts have not been standardized. I someday hope to see reconfigurable keyboards to sidestep this problem, or even a means to make them portable between machines (they say you can't take it with you? :-). > Even the letter keys are in confusing places--who ever thought of > putting E next to W next to Q? This was done in the early days of manual typewriters to slow typists down to a rate that the machine could handle without jamming. Precious little success with that idea. See Devorak's work on keyboard layouts for a detailed discussion on more reasonable keyboard configurations. > [symbol menus easily accessable by the mouse] So far so good. Consider also a menu of transformations defined for each symbol or category of symbols. The PostScript language designed by Adobe is an interesting and orthogonal implementation of many of the standard concepts of graphic layout. See The PostScript Language Reference Manual by Adobe for more information. > [more than one mouse button vs. clicking patterns] I am an advocate of mice with multiple buttons simply because we are physically capable of dealing with them. It takes only a finger and an opposing thumb to grip a mouse, leaving three fingers available for other tasks. It is up to the designer of the interface to make sure that the buttons are treated consistently. An extension to this concept is `chording'. Unless handled very carefully, though, chording can become overly complicated (control-shift left-and-middle-button? Hmph.) > [one document per floppy disk, to avoid confusion about the disks > contents] You present one fairly weak argument in support, without addressing any other issues. - Floppy disks cost money. Not much, but it adds up. You're saying the remaining space on a disk be forgotten until used. - You are restricting your memory medium to floppy disks? What have you decided to do about mass storage media, like hard disks? This is a preposterous idiom to follow in this event, of course. - Some groups of documents belong together; you leave it up to the user make sure that the physical disks are always grouped together. This goes along with the concept of directory structure, above. - (Fill in your favorit argument in the space provided.) ___________ __________________________________________________________________ __________________________________________________________________ > ... (wysiwyg) ... A good idea in most cases. There are times when it's inconvenient, though. There are lots of programming concepts that can easily be lost if care isn't taken to preserve them, like functional abstraction, data hiding, etc. Regards, [Ag]