Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!NOTE.NSF.GOV!mmorse From: mmorse@NOTE.NSF.GOV (Michael Morse) Newsgroups: comp.mail.mh Subject: Re: MH drawbacks for computer-unexperienced users Message-ID: <8804271458.aa07135@note.nsf.gov> Date: 27 Apr 88 18:58:26 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 193 I manage an MH-based mail system with about 900 users, many who are not considered computer-literate. Our experience has been overwhelmingly positive, but MH is like any good UNIX program--it is useless to novices as it comes out of the box. However, it is flexible enough that it can be configured to be extremely easy to use, and then the power is there to satisfy users when they become more experienced. One problem you will have is the full screen editor, which will probably be the hardest thing for your users to master. In my experience this applies to almost all screen editors accessed from terminals. People have been spoiled by the ease-of-use standard set by the PC's. Another problem is the documentation which you will have to re-write for people not accustomed to the UNIX-style of documentation (which is almost everybody, unfortunately). > * They are puzzled about the fact that all commands should be > given from the shell. Solution: msh!? Oh no, we tried it but it > seems to be poorly tested and not intended for use more than > once. So, we wrote an own simpler MH-shell program. The solution I took was to set up new logins with a very restricted UNIX path. The main problem we had was people trying to abbreviate commands which is common on other systems. If you don't change their path, many will enter "sh" instead of "show", and you'll be answering phone calls for help for the rest of your life. Many UNIX purists gave me a lot of grief over this decision, but it has been very successful. Our naive users start with a path containing just /usr/local and another directory in which we put site-specific commands. We thought of writing a shell, but it tends to be either overly restrictive (people can't pipe commands into other commands), or it gets so complicated that you've ended up writing and maintaining something as complicated as the C-shell. Msh seems to be customized for bulletin boards. I don't think it can be used for regular mail. Another thing we did is probably not applicable to other sites, but has been very successful here. We were lucky in that all of our users have PC's and use the same terminal emulator (Reflection 1). This program allows us to download function key labels and meaning. When they first log on, we download 8 of the most common MH commands. As they use commands, we update the labels as appropriate. This has been enormously complicated to maintain, but it gives the users a sort of menu, which MH does not have. This has been extremely popular with both naive and experienced users. For example, F2 on the PC is defined as "rmm;next", perfect for moving through your mail. The function key labels also allowed us to provide a screen editor that can be used without any training. We use JOVE, but when we enter JOVE we set up the labels with 8 of the most common editing functions. This provides a surprisingly powerful editor that requires no user training. Originally we did the whole thing with shell scripts, but have since re-written a lot in C to avoid the performance penalty. > * The way you read new mail is strange: you must first do "inc", > then "show" for the first letter, and "next" for the rest of > the letters. Its easy to loose track of which letter you should > read next, if you read an old letter amongst the new ones. Yes, > there is an "unseen" feature but then you must read ALL unseen > letters in a row. The other systems are easier (you just press > return for the next letter). This hasn't really been a problem here, but then the function keys help us here, since "show" and "next" are up on F1 and F3. I guess our users just use "scan" a lot. The concept of the "current" message is pretty important, so you'll want your users to grasp why "show" and "next" are different. > * There is no way to include a file in a letter without the use of > an editor. All the other systems have explicit commands to use > a certain file as a draft or to insert a file. We use a good number of commands that we've written to be invoked from the "what now?" prompt. They are easy to write, and again, many of them are trivial shell scripts. For example, our users can invoke the following at "what now?": edit includefile - append a UNIX file to the draft edit spelling - invoke ispell on the text of the message edit include - append the letter being replied to, with the text offset with "> " edit attach - append a PC file (text or binary) to the message edit header - use a menu to modify the header, and lookup names edit encrypt - encrypt the text of the message Some of these may be stretching the idea of an "editor", but people seem to have grown accustomed to it. We publish a "quick reference" card that includes all these, which I recommend that all sites do. It's been very popular and I keep an ever disappearing pile of them on my desk. >Have I missed some feature that could solve some of the above >problems? Send me a email and tell! (I'll sum up later.) Some other things we have done: * We've put a front end on "reply" that checks to see if there are multiple recipients and then prompts for who the reply should go to (all recipients or just the sender). This avoids teaching a lot of options. * We've written a bunch of commands for manipulating messages. For example, "printonpc" prints the specified messages on a users PC printer. Again lots of times these are just trivial shell scripts. * We have a couple of different commands for downloading messages to PC files. * We have a variant of reply (repli) that includes the message being replied to in the draft. We try to keep the MH flavor with most of the commands we write. It is very easy to do this with MH, since you can just invoke the real MH commands to do the real work. This makes it easy to handle all the variations of message specifications, so things like "printonpc +sent last:20" will work. The most ambitious undertaking we did to make the system easy for inexperienced users was writing a command called "profile." Originally I would give people assistance by telling them things like "put the following in your .mh_profile file." However for non-technical people, such a task may not be easy. So we picked out the MH (and UNIX) options that people would be most interested in and wrote a program that knows how to turn them on. Users of the profile program think that there is some "profile" kept somewhere that describes how the system should behave for them, but it's really a charade. The profile program simply reads and updates the appropriate initialization file for the feature, whether it is .mh_profile or .login or .joverc, or whatever. Here is a list of the various options that can be accessed in profile (this is about what I see when I execute the command): note> profile One moment please ... Profile entries: *** bboards *** 1 bboards-of-interest : note-info mh-workers info-unix unix-wizards liaison 2 check-bbs-at-login : no *** mail *** 3 signature : Michael Morse 4 formatted-show : yes 5 skip-existing-text : yes 6 mail-forwarding-address : (none) 7 draft-folder : yes (+drafts) 8 file-copy-comp : +sent 9 file-copy-repl : +sent 10 file-copy-forw : +sent 11 bcc-prompt : no 12 verbose-send : yes *** editing *** 13 scroll-step : 12 14 right-margin : 72 15 initial-mail-editor : prompter 16 next-mail-editor : vi *** system *** 17 unix-commands-subset : no Enter command (Explain, Update, List, or to exit): As an example of how this works: if a user thinks item 8 (file-copy comp) might be interesting, they would choose the "explain" option that would tell them that this item allows them to keep a copy of every message generated with the "comp" command in a folder which is the thing to the right of the colon. If they choose "update", the program will prompt them for the folder name, do some edit checks, and then either create a components file or add the line "Fcc: folder" to the header of the existing one. All the options work the same way, except they may access different files. Of course the program must be smart enough to determine the existing condition of each item, which is why it says "just a moment" at the beginning. >Are there plans to solve these problems? I doubt it. Since Marshall Rose went on to better things, MH has been without a developer or even maintainer. This sounds bad, but it does have some advantages. You are pretty much free to hack the heck out of the source code without worrying that you'll have to put all those changes into the next release! :-) --Mike Michael Morse Internet: mmorse@note.nsf.gov National Science Foundation BITNET: mmorse@NSF Telephone: (202) 357-7659