urlichs@smurf.ira.uka.de (Matthias Urlichs) (12/09/89)
In comp.sys.mac.programmer, dricejb@drilex.UUCP (Craig Jackson drilex1) writes: <In article <37000@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: <>In article <TIME.89Dec1180135@oxtrap.oxtrap.UUCP> time@oxtrap.UUCP writes: <> <>All that you need to know about a tool is the format and content of the <>configuration string, which is pretty simple -- parameter and value, separated <>by a space [...] < Which still leaves the problem of having to know about the configuration < string syntax of all possible tools which may be selected. I think there's < an obligation on Apple's part here to at least suggest some stronger < guidelines than 'parameter-value pairs'. Why? This seems to be an interface issue, and there already is an interface. 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 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 <file name> with <insert long and incomprehensible setup string here>" but "receive file <filename> with <user's own menu item>. 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. 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... 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. Comments? -- Matthias Urlichs
tim@hoptoad.uucp (Tim Maroney) (12/14/89)
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 ><file name> with <insert long and incomprehensible setup string here>" but >"receive file <filename> with <user's own menu item>. 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