Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!uflorida!codas!pdn!usfvax2!jc3b21!fgd3 From: fgd3@jc3b21.UUCP (Fabbian G. Dufoe) Newsgroups: comp.sys.amiga Subject: Re: Ban the Cloud! (plus sugg. for Workbench) Message-ID: <329@jc3b21.UUCP> Date: 7 Mar 88 05:43:31 GMT References: <318@jc3b21.UUCP> <1030@silver.bacs.indiana.edu> <43704@sun.uucp> Distribution: na Organization: St. Petersburg Jr. College, FL Lines: 187 This thread is really about making Workbench useful to experienced users. The Workbench approach offers several advantages over the CLI. Icons are more fun than filenames. The graphic display they offer is more interesting than one made up of pure text. Identifying an object by pointing to its icon is faster and easier than typing its name. We want to "point and click" too. OK, what CLI features are missing from Workbench? (1) Workbench doesn't show all the files on a disk. I think this is (2) Workbench lacks many of the commands available under the CLI. (3) You can't extend Workbench by adding a new program to the C: directory. (4) Workbench doesn't have the CLI's provisions for I/O redirection. (5) Workbench doesn't have a default console window for standard input, standard output, and standard error. (6) Workbench doesn't handle wildcards in filenames. (7) It isn't easy to run a program against a file in a different directory. (8) Workbench takes longer to display the contents of a directory. (9) You can't terminate Workbench when you are through with it. You have to reboot. Does Workbench offer anything that isn't available in the CLI (besides the "point and click" mode of operation)? I can think of two things. You can scroll around in a Workbench window to see more files than will fit in the window. In the CLI text that scrolls off the screen is lost. Workbench also gives you the ability to start a new process before its predecessor is complete. To do that under the CLI you must either have PopCLI or execute a "NewCLI" or "Run" command. Although Workbench is generally considered to be more intuitive for naive users it uses a more complex approach. Instead of just one way to describe operations it has three. Under the CLI you type commands which take the form verb [redirection] [object(s)] [option(s)]. Under Workbench you specify the object(s) by pointing and clicking. You specify the action one of three ways: (1) clicking again, (2) moving the object, or (3) making a menu selection. Now lets look at each of Workbench's deficiencies. (1) Workbench doesn't show all the files on a disk. I think this is Workbench's most serious defect. What would it take to fix this? Obviously we need some way to have Workbench display something for files that don't have a .info file. We could use a default image and build an icon or we could just use the filename. It has to appear on the screen anyway. I am in favor of using the filename. If it is a directory it should be followed by "(dir)". It takes less space to display the filename without an icon. We want to be able to do everything to this icon we can do with a regular one. We can't, though, because the .info file is where we save the type (project, tool, drawer, disk, etc.), default tool, and tool types. Only projects have default tools, so that isn't much of a loss. We already know it isn't a disk because they already have default icons. We can identify directories without a .info file, so we can tell if it is a drawer. We really don't lose much by being unable to distinguish between a tool and a project. If necessary we can create a .info file. Remember, the CLI doesn't distinguish between projects and tools until you try to execute a data file. If you double-click on a data file for which there is no default tool defined Workbench can display the error message "Unable to load [file]: file is not an object module" in the screen's title bar. Of course, if you double-click on a program it will start to run. One thing we want to think about is whether we should mix real icons and default icons. If we use filenames as the default icons, maybe we want this menu option to suppress all icons and display filenames. That would allow us to manipulate the .info files separate from their main files. One application for that would be to duplicate a .info file and rename the copy to create an icon for a file that didn't have one. (2) Workbench lacks many of the commands available under the CLI. If we provide default icons for the files in the C: directory we automatically bring all the CLI commands to Workbench. Of course, some of those commands weren't designed to work with Workbench. They need a console window for I/O. We don't want Workbench to automatically open a console window everytime we run a program, though. Also, we need some way to pass parameters to the commands. It's not too hard to pass file names as parameters. Just drag them to the program and drop them. Extended selection would allow passing more than one file to a program. The problem is with passing options or other parameters. Three solutions come to mind. (1) Forget options. If you want something other than the defaults use the CLI. This one's simple but you lose the advantage of being able to point to the files you want. (2) Put an alphabet of letter icons on the screen. Let the user include them in his extended selection. I don't like this because it's a kludge. Besides, options aren't always letters. (3) Have a "Set options" item on the menu. When you select it a string requester appears and you type your option list. The string stays there until you change it (perhaps to a null string) with the "Set options" item. I like this better. It's still pretty simple to implement. It's not perfect, but I can't think of anything better right now. (3) You can't extend Workbench by adding a new program to the C: directory. The solution to (2) solves this problem as well. If you can execute any program by dropping a file on it you eliminate this problem. (4) Workbench doesn't have the CLI's provisions for I/O redirection. How about two special icons on the Workbench screen: "<" and ">". The names under them are "Stdin" and "Stdout" (or "Standard Input" and "Standard Output" if you think that would be more user friendly). Drop a file on one and I/O is redirected to or from that file. The name under the icon would change from "Standard Input" (or "Standard Output") to the name of the file. If you want to reset them just double-click on "<" (or ">"). If you don't like the idea of special icons how about menu items that say "Set Standard Input" and "Set Standard Output". They would work like the "Set Options" item described above. Menu items make for a cleaner Workbench screen but the special icons would remind you of the redirection. (5) Workbench doesn't have a default console window for standard input, standard output, and standard error. If we adopt the menu Item solution described above for redirecting I/O we can allow the user to specify a special sub-option "Console". If that option is set Workbench will open a console window and execute the program from there. The user has to know whether a program he wants to run requires I/O. I don't think that's a problem, because we're talking about making Workbench useful for experienced users. (6) Workbench doesn't handle wildcards in filenames. I don't think there is any way to handle wildcards with a graphic user interface. So our choices are to open a CLI window and enter the command or provide a menu item for entering parameters that the graphic interface can't handle. Call it "Set parameters". (7) It isn't easy to run a program against a file in a different directory. The scheme I described earlier of running a program by dropping a file on it solves this problem. The current directory would be the one in which the file resides. That's the way Workbench works now. When you click on a file that becomes our current directory. But you can now drag the file to a program anywhere in the file system and start it running. (8) Workbench takes longer to display the contents of a directory. I think we have to live with this. By putting all the icons in a single file you save a little time on file opens. But you still have to read the image data for each icon for which a .info file (or entry) exists. One of the nice features of the Amiga is that I can design my own images for icons instead of having to use a standard one. And it does seem a lot simpler to me to have a separate .info file for each icon. Putting everything in one file amounts to creating a separate mini-file system just for .info files. You have to duplicate all the file management stuff that the regular file system is already doing for you. That looks like a lot of work, disk space, and memory for very little increase in speed. (9) You can't terminate Workbench when you are through with it. You have to reboot. This is easy to fix. Put an option on the menu that says "Exit Workbench". What does this do to the naive user? We have two ways to leave him undisturbed. One is to have a menu option that turns the advanced features on or off. The other is to have a separate "Advanced Workbench". Put "LoadAWB" in your Startup-Sequence file instead of "LoadWB". The Advanced Workbench shouldn't be any harder to write than a shell, should it? --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...gatech!codas!usfvax2!jc3b21!fgd3