Old-Subject: Re: E-mail survey
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: bit.listserv.cw-email
Date:         Fri, 18 Dec 1992 02:16:36 EST
              <CW-EMAIL@TECMTYVM.BITNET>
From:         Scott Ophof <ophof@SERVER.UWINDSOR.CA>
Subject:      Re Pine
              "Peter Scott U Sask Library Systems Dept" at Dec 16, 92 12:14 pm

On 16 Dec 1992 12:14:45 GMT scottp@JESTER.USASK.CA (Peter Scott U Sask Library
 Systems Dept) said:
>On Wed, 16 Dec 1992, Edward Vielmetti wrote:
>> Given a choice I'd also look at support for 'pine' as a campus wide
>> e-mail reader under Unix - it has a very short learning curve,
>> good support, and good on-line help.

>I agree with Ed. I've just been training some English faculty in e-mail,
>and we chose to have them use Pine. Many of them had already used Elm and
>VAX Mail, and were completely frustrated! For your information there is a
>Pine demonstration on the Internet which anyone can try. Here are the details:

Here are my comments on Pine.  Note that I use "Elm" as least
irritating/frustrating MUA on Unix that I have access to.  IMHO
"Elm" is definitely *not* the best MUA around (and I'm not
restricting myself to Unix platforms...).

A session of an hour or so with Pine raised the following points
and questions.  I'll get to the good parts at the end, but would
like to stress the negative points because they so important to the
to the user community (and IMHO to the welfare of Pine).

I'd like the author(s) of Pine to not take the following personally,
but reflect on the fact that very often one is (subconsciously)
trained to see only ones own envir, to not *really* look forward
or wider than the current envir.  The Campus-Wide discussion groups
are an exception to this rule, at least try *hard* to look wider
and further ahead.

As it stands, my opinion is that seen from an opsys-independant
point of view, one might as well have taken "Elm", given it a
different editor/aliasing & more help, and called it "Pine".  ;-)

OK, here are the points:

No *friendly* navigation commands.
 - How do I go to a specific page mentioned in the index of a
   help section?
 - How do I tell Pine to page forwards/backwards "n" pages or
   lines in *any* of the modes?  Just CURSOR there while letting
   the data SCROLL by at the low speeds common to Unix envirs?
 - What are the commands to skip to the bottom resp. top of the
   active file/mode?  GOTO-top-of-help by exiting help and
   re-entering it again is IMHO not friendly...

BTW, with data lines being as slow as they are, it's IMHO next to
criminal that after hitting the forward-page key rapidly a few times
in succession, one *still* needs to sit & wait till all those
screens have been laboriously redrawn...  When the program might as
well have intercepted the extra commands and updated the action to
take to include those new commands.  This seems to be a typical
thing of (at least) Unix and DOS.  I wonder if programmers *can*
work their way around this type of behaviour.

The editor (and many of the commands) remind me of WordStar,
not one of the friendliest word processors...
This point in itself detracts enormously from what Pine could have
been.  *IF* it's necessary to develop yet another MUA (Mail User
Agent), then it would IMHO be logical to include the best facilities
known at the time of implementation.  And not to fall back on old
stuff that belongs in the attic...  ;-)
   Note that the word "mailer" does *not* relate to the software
   the user accesses when building/reading/storing his mail.
   A "mailer" (like sendmail) is in reality the piece of software
   that takes the items offered by the user and sends them off to
   their destination.

What makes me sigh in despair is that Pine carries with it all the
ailments common to the Unix envir, without real attempts to at least
hide them from the users.
 - One-key "commands" which are generally not easy to remember.
   The "commands" visible at the bottom of each screen are no real
   help (nor can they be turned off by experienced users, right?).
 - No command line where one can type full-word commands (plus parms,
   options, etc).
 - What about a "home" key, or some function to put the cursor on
   that command line that's missing?

A lot of work seems to have been put into the help sections.  Which
is as it should be!  Good!
 - Now what about a menu listing the commands, where one can tab or
   cursor to any one of them, hit return, and view the relevant help
   section?  And returning to that menu where the cursor is still in
   the exact same spot, as a reminder of which command one just got
   help for?

 - Pine seems to think it has the right to do justification and
   text-flow for me.  And I can't seem to turn it OFF!
 - No way to define left margin, nor right margin, nor indentation
   for the first line of a paragraph.
 - Nor a switch to turn on/off auto-indentation.
 - How do I turn auto-wrap OFF?
 - How do I define tabs at columns *I* want?

The above six points are actually relevant to a word processor.
And a MUA does NOT need to re-invent the wheel by once again
building another word processor.  There are enough of them, and some
even allow user-defined macros that survive editing sessions.
IMHO one should let Pine have a *very* bare-bones editing facility,
and allow use of whatever editor the user feels comfortable with.

Most important though, is that a user-selected editor should be able
to interface transparently with Pine's MUA functions, like TOGGLING
from compose-mode to read-mode to nickname-mode to index-mode, etc.
It should all be possible withOUT having to close the current mode
and backtrack...

*AND* Pine's MUA-functions should be invokable from any mode Pine is
in at any moment.  In other words, let's say Jane prefers "vi" as
editor.  Then issuing the equiv. of "showme nickname John" should
be accepted by this editor, and the requisite actions taken.

There should be no restriction to how many items one can read and/or
write simultaneously.  Or to how many folders one can access at any
single moment.

 - To start a new paragraph, it seems one needs to hit RETURN (which
   unhappily enough triggers text-flow, thus destroying the spacing
   and indentation I had so carefully set-up) and then CURSOR DOWN.
 - But only ONE line seems to be allowed between paragraphs...
 - Nor does it seem possible to INSERT text/paras within the already
   existing text.  At least not without destroying the indentation
   and spacing...

The number of bytes in an item doesn't tell me anything about the
item-size.  Would it be possible to show the item-size as either
LINES or rounded up to the nearest KILObyte?
Maybe implement an option to let the user specify whichever (s)he
wants?  Maybe even allow dropping it from the screen alltogether?

Didn't check whether there were any sorting possibilities for the
index screen.  Anyway, I'd like to see a multiple-sort, like
ascending in "from:", and within that descending in "Date:"...
Sorting on "Subject:" should understand that:
   "Subject: Something"
should be followed directly by:
   "Subject: Re: Something"

Also, what about allowing inclusion of say the "Sender" tag in the
index display?  Many discussion lists use "Sender" to display the
name of the list.  So display of the list-name would be helpful.

   As a side note, let me explain that I use mail for personal
   items and postings from lists with medium-to-low volume but
   with high average interest level.  I only use netnews for high-
   volume groups.  Thus what *I* feel is "junk-mail" for *me* is
   kept at a minimum.

Did I see that a list of all folders is one of the items on the
main menu?  And can the user select one of them by cursoring/
tabbing to it and hitting RETURN?
   The (BACK)TAB key seems to me ideal as pointer, especially
   if the cursor's home position is the middle of the screen,
   ready to go in any direction.  There would also be an area
   there for users to type foldernames (or (external) commands).

Good points:

 - That the headers section is NOT a separate screen, but part of
   the item being composed is IMHO *good*!  And it's consistent
   with read-mode.
   Betcha there are people who would rather see the headers as a
   separate screen.  Fine!  So what about options to select integral/
   separated mode for header sections?  Not only for compose mode,
   but also for read mode?

 - The inclusion of aliases/nicknames is great!
   Now what about a nice menu on which to view the nicknames data
   per entry?  And allow user-definable fields (like phone number,
   surface address, comments, etc.)?  So one could use it as a
   Rolodex?  There's an opsys where nicknames/aliases are not per
   definition linked to mail software, but can be accessed, used,
   modified by any application wishing to do so.  And where field-
   length is not limited, nor the number of entries, nor the number
   of fields per entry...

 - The inclusion of an index of items in a folder is very helpful,
   and that's putting it quite mildly!  Paging through a 200-item
   folder is a form of masochism I'm not really fond of...  ;-)
   If not already so, may I suggest SAVING the index file relevant
   to each folder so it need not be rebuilt each time that folder
   is accessed?  And only rebuilt when the folder has been changed
   for some reason?  My "to-read-&-answer" folder in "Elm" is 200
   items or so, and rebuilding the index is becoming a waste of
   time and resources.  Um.. Maybe forget about saving the index if
   there are less than say 10-20 items in the folder?

 - Introducing the concept of "postponing" an item is a good idea!
   One *can* do it in "Elm" too, but it's a kludge, where one does
   an explicit save of the item to some filename one choses, and
   then tells "Elm" to forget about sending it off...
   Is there any convincing reason to restrict the number of post-
   ponable items (to one)?  If not, then what about using the alias/
   nickname (or user-portion of the recipient's addr) as filename?
   Like if the item goes to <John.Doe@somewhere>, it would by default
   be postponed in file "john.doe.postponed", or if an alias exists
   (and is "jd"), to "jd.postponed", or to "whatever.postponed" one
   types when not giving the default response of RETURN to the
   "Filename?" question.  Of course users should not need to type in
   ".postponed"...  ;-)

 - Pine's help sections make "Elm" seem absolutely dated and even
   more unfriendly than it already is.
   Now for a menu with the commands plus a 2-5 word explanation,
   with a way to display more help on any selected command.


Regards.
$$/     (F. Scott Ophof  <ophof@server.uwindsor.ca>)
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU