Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac.programmer Subject: Re: Comm.Toolbox: A solution for multiple FT configuration? Message-ID: <9280@hoptoad.uucp> Date: 13 Dec 89 20:45:35 GMT References: <9125@hoptoad.uucp> <36869@apple.Apple.COM> <37000@apple.Apple.COM> <6576@drilex.UUCP> <1277@smurf.ira.uka.de> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 87 In article <1277@smurf.ira.uka.de> urlichs@smurf.ira.uka.de (Matthias Urlichs) writes: >Some DTP apps had the same problem with colors. If you want to assign a color >to something, it would not make sense to put upo the color wheel every time; >instead the user can create a menu (via some kind of dialog) with all the >colors which (s)he needs for everyday use, plus an "Other..." item. > >Same with file transfer methods. You let the user create a menu (the List ^^^ That should be "make", not "let". Any operation which reconfigures the user interface of a program in this way is inherently an expert feature; many neophytes will neither understand the feature, nor trust themselves to use it responsibly. It is self-contradictory to try to create user-friendliness by adding a feature that will be used almost exclusively by experts. The wonder of the Mac is that neophytes, if they have used a Mac program before, can pick up a new program and start using it right away. No need for a bizarre setup process, no need for reading a manual, no need to bend the mind into weird shapes to understand what needs to be done. This is somewhat less so of terminal emulators -- the person must understand how to use the other computer(s) -- but this just makes it more important that the user's time not be wasted figuring things out on the Mac end. It should not be necessary to learn a scripting language before using the program, for instance, and the program should not be unfriendly before the person figures out how to configure the interface in a friendly way. >Manager comes in handy here) with all the file transfer settings necessary for >a particular application. Then, when sending or receiving a file, you either >use a hierarchical menu under "Send File..." or a pop-up menu in >SFGet/PutFile. Likewise, the scripting language does not use "receive file > with " but >"receive file with . A few problems here. First, "Send File" can be given a keyboard shortcut. If you have three items in the hierarchical menu, you're going to run out of shortcuts pretty fast, and you also have to have some interface for specifying shortcuts. (Not as easy as it may sound; the user will probably [at some point] pick some weird option-shift-dead key that requires trap patching to catch, and you have to display it -- not only in the dialog, but in the menu; so you need trap patches, weird font symbols, and your own MDEF.) If a script refers to the local menu configuration, then that is a script that can't be passed from person to person. >This has some additional advantages, like the fact that no one would need to >translate those setup strings to different languages any more because the user >won't see them anyway. I don't agree. While agreeing with my colleagues' desire to leave their current scripting syntax intact, I also feel that a scripting language must give some way of controlling the low-level tool configuration strings, perhaps through a new command. Otherwise, you are not giving power users full access to the Comm. Toolbox. (And any scripting language user is by nature a power user.) >Also, when you need to change the FT settings you >can now change them once in the menu-creation dialog and you don't have to >hunt through your scripts... Assuming you give the same name to the new configuration as you did to the old. This is likely to create confusion, not dispel it. >And if you want to change a specific parameter, and the FT tool doesn't >understand it (Kermit frame length, for instance, when you really want to use >XModem :-), the user's selection might still work. Huh? Another problem with this idea is that you are assuming a single group of settings is going to be good enough for all systems you call. Some users are going to call a lot of machines, and would prefer to partition the configuration set by session document or account description. So, here's my conclusion. This would probably be a worthwhile feature to add in some form for power users. However, it should not interact with the script language, because it makes scripts dependent on the local configuration, and it should not be a precondition to user friendliness for non-power-users who may still want to change modes. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Please help support the moratorium on meaningless quotes in .signatures." -- Doug Asherman on rec.music.cd