Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!cmcl2!harvard!seismo!rochester!ritcv!cci632!ccird1!rb From: rb@ccird1.UUCP (Rex Ballard) Newsgroups: net.micro.mac Subject: Re: Ten Challenges (long) Message-ID: <420@ccird1.UUCP> Date: Tue, 13-May-86 11:57:06 EDT Article-I.D.: ccird1.420 Posted: Tue May 13 11:57:06 1986 Date-Received: Thu, 15-May-86 06:19:01 EDT References: <21100039@orstcs.UUCP> Reply-To: rb@ccird1.UUCP (Rex Ballard) Organization: CCI Rochester Development, Rochester NY Lines: 150 In article <21100039@orstcs.UUCP> nathan@orstcs.UUCP writes: >Ten Challenges: > > What is short now is not coding, but design. "What can we do to >multiply the effects of all our efforts?" In this spirit I offer ten >Challenges to the Macintosh software community. > >Myers Challenge #1: > A serious weakness found in every Mac editor I know of is the >search/replace function. > >Myers Challenge #2: > On Unix, we get tremendous mileage out of the "pipeline" concept. >Every little program is part of a (more-or-less) integrated system. > What we need is support for a building-block approach that >allows dozens of little filters, on various volumes, to interact. > >Myers Challenge #3: > Every RAMdisk I've seen on a Mac has been terribly primitive. > The person who builds a smart Ramdisk will own the business. RAMdisks, memory resident programs, and other "tricks" seem like a poor substitute for real multitasking. It might be nice to have a little Cache for the disks, but rather than try to "band-aid" around the "one task" limitations, multitasking should be considered #1 on Apple's priority list. Demand paging, virtual memory, and Cached read-ahead would be nice, but the current Macs don't have the hardware to support these. It is possible to get some degree of multitasking even with the limitations of the Mac. It might not be "full blown UNIX with Graphics", but at least you wouldn't be waiting 20 minutes for "MacDraw" to "print" to your Imagewriter. >Myers Challenge #4: > Not to leave the bit-bangers among us unchallenged, I propose >that a two-button mouse is possible and desirable. I would suggest that the second button have the "double click" functionality, since this seems to be the most frustrating part of the mouse. Every tried to click-drag a selected application only to find yourself going into McDraw instead? This can be real bad when people "take turns" at the Mac and set preferences to very slow. >Myers Challenge #5: > The only Finder function I haven't seen duplicated in a desk >accessory is this: copying files. I would like to see both a true "copy" and a true "move" to move and copy files in and out of folders and across drives. >Myers Challenge #6: > Anyone who's used an Atari knows that GEM's menu-bar approach, in >which you don't have to hold the mouse button down while you make a >menu selection, is less fatiguing than Apple's. Actually, this is a mixed blessing, unfortunately if you accidentally "bump" the menu bar, you need to to some heavy maneuvering to get that menu to go away. If you really want it, great, try it first. >Myers Challenge #7: > Apple's resource editor is huge, cumbersome, non-expandable, >and unreliable. The only thing to say in its favor is that it's >indispensable. > I propose a core program which itself is little more than a >resource mover. It would load an edit module for each resource >type, as needed, from a separate file identified by the resource >name. I'm not sure if this would be better than having separate editors, rather than one core program with different edit modules. Unfortunately, Mac has a lot of "Magic cookies" that are difficult to comprehend, let alone edit. >Myers Challenge #8: > Another thing that makes Unix powerful is that almost everything >is accessible through the file system. > With this scheme we could eliminate the proliferation of trap >calls, and make our programs more flexible too. This is one place >where I expect we'll need cooperation from Apple. You're sounding more and more like an OS-9 for Mac supporter :-). You are right, "transparent drivers" would be a useful way of improving the "modularity" of Mac software. I don't know how much co-operation we can expect from Apple, but it should be possible to get OS-9 with VDI before the end of 1986. >Myers Challenge #9: >The corporate market is starting to demand compatibility among word >processors. Unfortunately, what they're specifying is IBM's >DisplayWriter format: an abomination. >It need not be terribly compact; but it must be >capable of representing all constructs found in Microsoft Word, Troff, >TeX, Word Perfect, and Interleaf files. To do this, it must of course >be an extensible, hierarchical language. Get an ANSI or NBS >committee to rubber-stamp it, and make a fortune. Actually, there are several usefull alternative standards including the PostScript used by the AppleTalk/Laserwriter. The main obsticle here is that the Mac can go from "Pict&Text" to "PostScript" but not the other direction. Actually, if Mac could accept any of the available "document description formats" as INPUT, the issue would be settled quite easily. Anybody got a PostScript to ScrapBook interpreter? Also, definitions of "objects" should be sufficiently complete to allow transfer in/out of ANY editor, including say, McProject, McDraw, and McDraft. >Myers Challenge #10: >Come up with a better set of challenges, and put your own name on >them. Ballard Challeng #1: Data Transfer Capability. Come up with the necessesary interpreter so that one can create a file on ANY computer (UNIX, PC, or other), bring it into Mac, edit on ANY editor, transfer back to UNIX, run through filters, then print on ANY graphics capable printer. I should also be able to edit on any OTHER graphics capable computer. Just as you are capable to manipulate UNIX "text" files with several different "tools", you should be able to manipulate Mac "picture" files in the same way. Ideally, it should also be possible to use a "text only" editor to intelligently manipulate the files as well. Macro, Search, and "Define" capabilities. It should be possible to write "Macros" which can extend the capabilities of existing tools, much the same way as Aliases, Shell scripts, and user defined functions extend the capabilities of otherwise "trivial" UNIX commands. Ideally, such a process should be as interactive and intuitive as the current desktop and Mac editors. It should also be possible to Search for object such as "a rectangle containing the text 'rex ballard'" if such a box exists. Considering the Object Oriented organization of the Mac, it should be possible to view N dimentional matrices of commands or available functions. For example, you might touch an Item on the menu bar which gives two columns. Click one from each column, and it will resolve into a single command. Have a way of determining which fonts, accessories,... must be loaded to view a document. I have a couple of documents I can't read because MacWrite can't find all the right fonts. I should be able to put the Mac in a "status mode" where selecting an item will tell me which application should be run, what fonts and resources are needed, and what can be done with it. There should be a "more" or "preview" format in which the document can be examined, but not modified. It shouldn't be necessary to load an entire application just to "peek" at a one or two page "picture", especially considering the 2 minute waiting period for going in and out of some of those applications.