psv@nada.kth.se (Peter Svanberg) (04/21/88)
I'm writing a user manual for email to be used by anyone who
have access to a computer terminal - i. e. some have very little
experience of computer use.
When documenting different mail systems (TOPS-MM, VMS-MAIL, UNIX-mail
and UNIX-MH) I realized that MH have some beginner drawbacks:
* 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 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).
Solution: We made our shell run "inc" when started, and invented
an own command "unseen" which runs "show" on the first letter in
the sequence "unseen".
* 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.
The closest I could get was "comp -file filename", but besides
that this switch isn't parsed correctly (in MH 6.5; the filename
is treated as if it was a message list), the file must be a
"draft message", i. e. contain header lines, or else the
prompter program doesn't like it. Then you must copy the file
you want to include to a new file, and edit it to put the header
lines (and an empty line) in. Not easy-to-use!
The best, I think, would be to add an "insert" command to the
whatnow program.
Have I missed some feature that could solve some of the above
problems? Send me a email and tell! (I'll sum up later.)
Are there plans to solve these problems? Have you experienced other
problems with MH and computer beginners? Post a comment to the net!
---
psv@nada.kth.se (should work!) Peter Svanberg
psv%nada.kth.se@uunet.uu.net (for lazy nodes...) Dept of Num An & CS
Royal Institute of Tech
Stockholm, SWEDENralf@B.GP.CS.CMU.EDU (Ralf Brown) (04/24/88)
In article <336@draken.nada.kth.se> psv@nada.kth.se (Peter Svanberg) writes: } * 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 I use the following self-modifying alias: alias inc "alias n 'show ; alias n next' ; 'inc'" Then I can just type 'n' each time I want to see the next message (including the first). }--- }psv@nada.kth.se (should work!) Peter Svanberg }psv%nada.kth.se@uunet.uu.net (for lazy nodes...) Dept of Num An & CS -- {harvard,uunet,ucbvax}!b.gp.cs.cmu.edu!ralf -=-=- AT&T: (412)268-3053 (school) ARPA: RALF@B.GP.CS.CMU.EDU |"Tolerance means excusing the mistakes others make. FIDO: Ralf Brown at 129/31 | Tact means not noticing them." --Arthur Schnitzler BITnet: RALF%B.GP.CS.CMU.EDU@CMUCCVMA -=-=- DISCLAIMER? I claimed something?
deford%linus%mitre-bedford.arpa@ICS.UCI.EDU (04/24/88)
It seems to me that you need to read the MH user's manual. MH provides alot of great features, one of which is the fact that you do not have to get into a mail program to look at messages - they are all accessable to unix commands. Though this may seem strange at first to those used to using mail, I feel that it is one of the better features of mh. As far as inc - why not take a look at the man page for mhook. It explains a way to have sendmail use an mh program (slocal) to deliver mail automatically. for including a message in a composition use "comp -form formfile". Also, if there is more that you want to include try looking at the files replcomp, distcomp, components, and forwcomp. All these are explained in the manual. Good luck, ------- Kevin ( Eat, Drink, and be Merry - for tommorrow you may be in Utah )
mesard@bbn.com (Wayne Mesard) (04/26/88)
From article <336@draken.nada.kth.se>, by psv@nada.kth.se (Peter Svanberg): > > * They are puzzled about the fact that all commands should be > given from the shell. No argument from me. This is puzzling to new users. Especially, those who've used another mail system like MM. But rather than succumb to the temptation to protect novices from this interface, why not explain the rationale behind it. Specifically: o They need not bounce in and out of a mailer every time they want to read a message. o By using the shell, we have access to the full power of the shell. This needn't be a lengthy, complicated discussion, just a few examples of how easy it is to customize the mail reading environment and create new "commands" that are as cryptic or helpful as the individual user desires. For example, alias rmn "rmm; next" alias new-mail "inc; show" A simple discussion, loaded with examples can be an advertisement for UNIX as well as MH. But... o There are a lot of features in MH which the casual user shouldn't be bothered with, since most people "just want to read their mail".* The solution: a brief synopsis of the few commands they need and maybe a few aliases in a default .cshrc file (to protect them from the UNIXness of MH) AND a pointer to finding out more if they're interested (e.g. "<cmd> -help" and "man mh"). > * There is no way to include a file in a letter without the use of > an editor. "forw -file <fn>" works for me. ---- * The words of more than one recalcitrant user after hearing my 5 minute sermon on why MH is the greatest thing since toast. -- unsigned *Wayne_Mesard(); MESARD@BBN.COM BBN Labs, Cambridge, MA "All systems of useful complexity contain software errors." -The Eastport Report, p.14
psv%nada.kth.se@ICS.UCI.EDU (Peter Svanberg) (04/26/88)
First of all: Did you send to psv%nada.kth.se@uunet.uu.net and something somewhere changed it to psv@uunet.uu.net? I really don't see how this last address could reach me! Try "psv@nada.kth.se" also, next time. > It seems to me that you need to read the MH user's manual. I have! > MH provides > alot of great features, one of which is the fact that you do not have to > get into a mail program to look at messages - they are all accessable to > unix commands. Though this may seem strange at first to those used to > using mail, I feel that it is one of the better features of mh. I think MH is very nice to use, and I have no problem with the no special- program-feature. My and others experience, though, are that people who are not computer-experienced find that unusual and strange. They want a special "mail room" to enter, reducing the number of possible commands. It is also more difficult to teach them how to get specific help if you don't have a special program with a help command in it (and perhaps recognition). (And don't tell me that the manual information is usable for those people!) > As far as inc - why not take a look at the man page for mhook. It > explains a way to have sendmail use an mh program (slocal) to deliver > mail automatically. As I explained, I compared with some other systems. In none of those I had the mentioned problems. Why should you have to make special arrangements with strange ".forward"-files etc in MH? The user manual I'm writing should be possible to use without too much special arrangements on top of standard MH. (Besides this, aren't you losing "You have mail"-messages when you use slocal?) > for including a message in a composition use "comp -form formfile". Yes, but I want a FILE of any sort, for example a source code. (NOT containing mail headers!) > Also, if there is more that you want to include try looking at the > files replcomp, distcomp, components, and forwcomp. All these are > explained in the manual. I know of them, too, be sure. Well, I suppose one can say that MH is more for hackers than for novice users. --- psv@nada.kth.se (should work!) Peter Svanberg uunet!nada.kth.se!psv (for lazy nodes...) Dept of Num An & CS psv%nada.kth.se@uunet.uu.net (ARPA nodes) Royal Institute of Tech Stockholm, SWEDEN
deford%linus%mitre-bedford.arpa@ICS.UCI.EDU (04/26/88)
It seems to me that when you say "not computer-experienced" then why would they expect to end up in a mail "shell"? If it is true that they are just beginning, I would believe that is a good time to teach someone MH. I can see the problem with people that are "computer experienced" as in have used a previous mailer that was a "shell". But then they should have only a small problem learning MH since they are used to mailers in general. But I can see your point. As far as slocal related things, the .forward file and a default .maildelivery file could always be put in a new person's account. Then use the program rcvtty to notify them when new mail arrives (sort of like biff). This would at least eliminate the person having to figure all of that out by themselves. I don't mean to sound condescending, I guess I never found other mailers any more friendly then MH. True, the basic commands of reply, compose, and show where pretty straight forward - but then again, so are MH's. The real problem is just getting someone to try MH - since most people just do not want to have to learn something new. ------- Kevin ( Eat, Drink, and be Merry - for tommorrow you may be in Utah )
mmorse@NOTE.NSF.GOV (Michael Morse) (04/28/88)
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 <RETURN> 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
allbery@ncoast.UUCP (Brandon Allbery) (05/05/88)
As quoted from <23864@bbn.COM> by mesard@bbn.com (Wayne Mesard): +--------------- | From article <336@draken.nada.kth.se>, by psv@nada.kth.se (Peter Svanberg): | > * There is no way to include a file in a letter without the use of | > an editor. | | "forw -file <fn>" works for me. +--------------- "forw" in MH 6.5 #45[UCI] of Tue Jul 8 11:38:00 PDT 1986 doesn't grok a "-file" argument. Or at least, so it tells me in "forw -help".... A simple solution to this is to write a custom "whatnow" and add a new command: "incl [-prepend] {-file file|[+folder] message}" "Whatnow" is, of course, simply a "shell": while ${EDITOR} ${draftmsg}; do echo "What now? \c" read cmd case "$cmd" in # the various commands esac done (Of course, it's actually in C, and the default whatnow is built into many MH commands, but this is the basic idea.) A C program could be written to do this (at a slight speed penalty) and add an "incl" command rather easily; I may actually do this in the future. (Most often, when I want to include a file I'm really sending a form letter reply; in this case, the best way to handle it is to set up a reply template and send the reply with e.g. "repl -form arch-form-letter".) BTW, for those interested: Back when I first joined this group (it was still a mailing list then), someone asked how to "boxify" messages. I had it kluged then, now I have a "proper" technique. (~/Mail/mhl.reply) ----------------------------------- cut here ----------------------------------- :+--------------- body:component="| ",compwidth=0,formatfield="%<(null)| %|%(putstr)%>" :+--------------- : ----------------------------------- cut here ----------------------------------- The only problem is that it sometimes starts a "component" in a very strange place in the middle of a line, usually splitting a word squarely in half. I've no idea why it happens. -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!marque,cbosgd,sun!mandrill}!ncoast!allbery Delphi: ALLBERY MCI Mail: BALLBERY
mesard@bbn.com (Wayne Mesard) (05/09/88)
From article <7709@ncoast.UUCP>, by allbery@ncoast.UUCP (Brandon Allbery): > As quoted from <23864@bbn.COM> by mesard@bbn.com (Wayne Mesard): > +--------------- > | From article <336@draken.nada.kth.se>, by psv@nada.kth.se (Peter Svanberg): > | > * There is no way to include a file in a letter without the use of > | > an editor. > | > | "forw -file <fn>" works for me. > +--------------- > > "forw" in MH 6.5 #45[UCI] of Tue Jul 8 11:38:00 PDT 1986 doesn't grok a > "-file" argument. Or at least, so it tells me in "forw -help".... Indeed you are right. "forw -help" tells me the same thing. It's not in the man page either. Nonetheless, "forw -file <fn>" does work. There's an old wives tale that says it's aerodynamically impossible for bees to fly. What they don't know...eh? forw -help syntax: forw [+folder] [msgs] [switches] switches are: -[no]annotate -draftfolder +folder -draftmessage msg -nodraftfolder -editor editor -noedit -filter filterfile -form formfile -([no]forma)t -[no]inplace -digest list -issue number -volume number -whatnowproc program -nowhatnowproc -(help) version: MH 6.5 #63[UCI] (lf-server-2) of Thu Dec 10 12:17:18 EST 1987 options: [BSD42] [TTYD] [DUMB] [SUN] [OVERHEAD] [MHRC] [MHE] [MMDFMTS] [MMDFII] -- unsigned *Wayne_Mesard(); MESARD@BBN.COM BBN Labs, Cambridge, MA "Who needs clover leaves when we've got rotories? Who needs rotories when we've got cyanide?"
schmitz@hpscdc.HP.COM (John Schmitz) (05/10/88)
> "forw" in MH 6.5 #45[UCI] of Tue Jul 8 11:38:00 PDT 1986 doesn't grok a > "-file" argument. Or at least, so it tells me in "forw -help".... MH 6.5 has it; it just doesn't tell you with -help because you don't normally use it. "-file" is usually only used by msh.
bd@HPLABS.HP.COM (bob desinger) (05/10/88)
>> * There is no way to include a file in a letter without the use of >> an editor. > A simple solution to this is to write a custom "whatnow" and add a new > command ... Yes, or you could use this enclosed shar. Yes, you have to run an "editor," but it's not like you get bopped into an interactive session; it's more an editor in the style of `sed.' To use it: 1. Unpack it into some directory in everyone's $PATH. 2. At the What Now prompt, type: e attach file where "file" is the name of the file you want to include. The `attach' command name could be changed easily (via `mv') to `include' or whatever you prefer. 3. Now you'll see another What Now prompt. Type `p' or whatever you normally type to send the letter off. If you want to edit the file with your usual screen editor at this point, type: e vi or e emacs or else put an entry in your .mh_profile to the effect of: attach-next: vi No, it's not intuitive. However, it gets the job done quickly. -- bd #! /bin/sh # This is a shell archive. Remove anything before this line, # then unwrap it by saving it in a file and typing "sh file". # # Wrapped by bd at hpsemc on Mon May 9 23:33:58 1988 # Contents: # attach PATH=/bin:/usr/bin:/usr/ucb:/usr/local/bin:$PATH; export PATH echo 'At the end, you should see the message "End of shell archive."' echo Extracting attach cat >attach <<'@//E*O*F attach//' : append editor for mh -- /jlr and bd case $# in 1) msg=$1; echo -n 'Append file(s): ' 1>&2; read appendix;; 2) msg=$2; appendix=$1;; *) echo 1>&2 "Usage: `basename $0` [file]"; exit 1;; esac for arg in $appendix do if [ -f $arg -a -r $arg ] # exists; non-directory; readable then echo 1>&2 \"$arg\" # yell the file name out cat </dev/null $arg >>$msg else echo 1>&2 "`basename $0` $arg: Sorry." fi done @//E*O*F attach// set `wc -lwc <attach` if test $1 -ne 18 -o $2 -ne 75 -o $3 -ne 420 then echo ! attach should have 18 lines, 75 words, and 420 characters echo ! but has $1 lines, $2 words, and $3 characters fi chmod 755 attach echo "End of shell archive." exit 0
ted%braggvax.arpa@ICS.UCI.EDU (05/10/88)
>Date: 5 May 88 01:13:40 GMT >From: Brandon Allbery <mandrill!hal!ncoast!allbery%decvax.dec.com@ICS.UCI.EDU> >"forw" in MH 6.5 #45[UCI] of Tue Jul 8 11:38:00 PDT 1986 doesn't grok a >"-file" argument. Or at least, so it tells me in "forw -help".... Give it a try anyway. It's not documented in the -help for our forw either (6.5 #46), but it works anyway. Ted Nolan ted@braggvax.arpa
schmitz@hpscdc.HP.COM (John Schmitz) (05/11/88)
> The only problem is that it sometimes starts a "component" in a very strange > place in the middle of a line, usually splitting a word squarely in half. > I've no idea why it happens. I have some idea. I believe that uip/mhlsbr calls sbr/m_getfld when it is working on the body of the message. m_getfld does not always return a buffer that ends on a newline. Before each call to m_getfld, mhlsbr puts out the "component" before getting a new buffer from m_getfld. That's where the extraneous component comes in. The following diff to sbr/mhlsbr.c may fix your problem. No guarantees, of course. 204a205 > static int body_entered; 726a728 > body_entered = 0; 1102c1104,1106 < putstr (c1 -> c_text ? c1 -> c_text : c1 -> c_name); --- > if (flag != BODYCOMP || body_entered == 0) > putstr (c1 -> c_text ? c1 -> c_text : c1 -> c_name); > if (flag == BODYCOMP) body_entered = 1;