ray@philmtl.philips.ca (Raymond Dunn) (02/23/90)
I've just recently been trying elm, and although the package has a lot of
good features, I am a little disappointed with the user interface.
Please accept the following as constructive criticisms coming from (too)
many years experience, not just cheap shots.
The version in use is 2.2 PL16.
1) When saving (s), the messages are flagged with a "D". This is the same as
when they are deleted (d).
There are two things wrong here:
a) The "s" and "d" keys are adjacent on the keyboard and are commonly
transposed when typing. It is a classic user interface design error
to use two such keys for such different functions, one benign, one
destructive, ("D" would be a reasonable alternative for "d"), and
particularly because:
b) at the end of a mail housekeeping session it is not possible to
easily determine which messages have been saved and which have been
deleted without saving - they are both flagged 'D'.
I would strongly suggest that saved messages be flagged differently from
deleted ones. I consider this a serious bug.
2) The user should be able to configure personal preferences as to how elm
should dispose of messages when you quit, so that, for example you don't
have to go through the delete/save/leave-alone dialogue for each
category. Again, saved and deleted messages should be clearly
differentiated.
I don't see any need for elm to ask you what you want to do with
messages you haven't touched - it should leave them alone in the
mailbox.
3) "<" for "sent", and ">" for "received", are non intuitive. The opposite
is intuitive ('tis, 'tisn't....though obviously there is no point in
arguing this point of personal preference, consider whether keys like
arrow keys are dangerous to choose in a case like this because they may
have strong opposite connotations to some users.)
4) Saving to Mail/sent and Mail/received should be a single keystroke
command, why not make it *directly* the "<" and ">" keys, rather than
"s" + "<" + <return>. The overloading of "<" (or is it ">") for use
with calendars serves little useful purpose.
5) Inconsistent use of full screen update mode and scrolling mode under
different circumstances, particularly but not confined to when the
folders help scrolls up onto the screen.
Text is often displayed then immediately erased or the screen redrawn.
I *think* that the messages I have seen doing this are innocuous, but
that's not the point. Do I have confidence that I will not miss a
message that I should see?
Screen redraws seem to take place arbitrarily. The interface doesn't
have a tight consistent feel.
6) Mail header generation and editing during mailing and replying.
There is no doubt in my mind that the best way to handle this is as in
Rnmail, where the headers are treated as part of the message and you can
freely edit them.
I often have to copy the To address out of the body of the message.
Using elm, I have to work with a paper and pencil to remember what to
edit into the headers. Why add a whole new section to the user interface
(the header input and editing), when the users is already using a
perfectly good editor of his choice.
If elm is designed this way to force validity of the headers, then it
has been done at the expense of user convenience. Elm can check
validity after the user has finished editing (Rnmail seems to have no
problems in this area).
On the same note, elm ignores References lines in the message being
replied to. A paper and pencil must again be laboriously used if I want
to quote them (or the message copied separately to another file then
yanked back into the reply).
If any of this has already been discussed already then I apologize in
advance. Could someone relay the old articles to me?
Are there any features in elm that I have missed that would enable me to
correct the problems that I'm concerned about.
Comments anyone?
--
Ray Dunn. | UUCP: ray@philmtl.philips.ca
Philips Electronics Ltd. | ..!{uunet|philapd|philabs}!philmtl!ray
600 Dr Frederik Philips Blvd | TEL : (514) 744-8200 Ext : 2347 (Phonemail)
St Laurent. Quebec. H4M 2S9 | FAX : (514) 744-6455 TLX : 05-824090tombre@crin.fr (Karl Tombre) (02/26/90)
In article <1066@philmtl.philips.ca> ray@philmtl.philips.ca (Raymond Dunn) writes:
1) When saving (s), the messages are flagged with a "D". This is the same as
when they are deleted (d).
I would strongly suggest that saved messages be flagged differently from
deleted ones. I consider this a serious bug.
I agree.
2) The user should be able to configure personal preferences as to how elm
should dispose of messages when you quit, so that, for example you don't
have to go through the delete/save/leave-alone dialogue for each
category.
There are options for that in .elm/elmrc. Among others, ask = OFF
6) Mail header generation and editing during mailing and replying.
I strongly agree. This is very important ; I should be able to edit
the From: and Reply-To: headers as I want. The system only has to add
a Sender: field automatically. I think this is also what is said by
the RFC-whatever-number-it-is. A secretary should be able to send a
mail with the From: header referring to his/her boss, and we should
also be able to ask for replies to go to another person... And I agree
that the best is to include all these headers in the texte being
edited. In emacs mail, you have a line saying "--text follows this
line-- which can be easily removed by the mailer when the user quits
editing..
--
Karl Tombre - INRIA Lorraine / CRIN
EMAIL : tombre@loria.crin.fr - POST : BP 239, 54506 VANDOEUVRE CEDEX, Franceeric@ists.ists.ca (Eric M. Carroll) (03/02/90)
>6) Mail header generation and editing during mailing and replying. > > There is no doubt in my mind that the best way to handle this is as in > Rnmail, where the headers are treated as part of the message and you can > freely edit them. Well, there is alot of doubt in mine. I am a charter member of the Larry Wall Appreciation Society(TM), but IMHO Rnmail is definately not Larry's best piece of work. My Elm users are novices, and want to dispatch mail, not worry and fiddle with confusing, bizzare and arcane lines that mean nothing and can blow the whole process by accidently touching them. If you must have it, make it a elmrc option so I can turn the damn thing off. > I often have to copy the To address out of the body of the message. > Using elm, I have to work with a paper and pencil to remember what to > edit into the headers. Why add a whole new section to the user interface > (the header input and editing), when the users is already using a > perfectly good editor of his choice. I cannot recall a single instance of needing this. You must have some seriously warped transport agents along the way. Transport agents should not, ever, ever ever ever touch the header, except to add tracing information. No. Not. Negative. Get it right the first time and leave it alone. The reason I want a seperate "header" section is that it seperates the tasks of dealing with headers and dealing with MAIL. Users care about CONTENT not PROCESS. They give not one whit about HOW it happened, just that it did. Leave header handling alone, please. (By the way, Elm is a standard mail user agent within ISTS for novice users. Lotta people using it...)
peter@ficc.uu.net (Peter da Silva) (03/02/90)
I'd like to second the call for a way to edit headers using a standard editor.
I don't care if you have to set the "Yes I'm a Mail Guru and I promise NOT to
blame you if I screw up" flag. I don't much care if the header editing is done
with the message or separately. In fact if you do it separately you can make
the *regular* header editor a separate program and cut some of the bloat out
of the main program.
Use the saved space to add a TCL interface.
--
_--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/ \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
v "Have you hugged your wolf today?" `-_-'peake@inria.inria.fr (Philip Peake) (03/03/90)
In article <TOMBRE.90Feb26121044@loria.crin.fr> tombre@crin.fr (Karl Tombre) writes: *In article <1066@philmtl.philips.ca> ray@philmtl.philips.ca (Raymond Dunn) writes: * * 6) Mail header generation and editing during mailing and replying. * *I strongly agree. This is very important ; I should be able to edit *the From: and Reply-To: headers as I want. The system only has to add *a Sender: field automatically. I think this is also what is said by *the RFC-whatever-number-it-is. A secretary should be able to send a *mail with the From: header referring to his/her boss, and we should *also be able to ask for replies to go to another person... And I agree *that the best is to include all these headers in the texte being *edited. In emacs mail, you have a line saying "--text follows this *line-- which can be easily removed by the mailer when the user quits *editing.. If you have a reasonably up-to-date elm, by typing 'h' you can edit certain headers. Amongst these is the Reply-To: header. I think that RFC822 (if I remember correctly) says that the From: header should *always* be correct (ie you should always know who actually sent the mail) - this seems reasonable. For the case of a secretary sending mail, this is also addressed in RFC822, and gives a standard solution to this problem. Philip
jeff@quark.WV.TEK.COM (Jeff Beadles) (03/03/90)
[someone wrote:] >> I often have to copy the To address out of the body of the message. >> Using elm, I have to work with a paper and pencil to remember what to >> edit into the headers. Why add a whole new section to the user interface >> (the header input and editing), when the users is already using a >> perfectly good editor of his choice. And, eric@ists.ists.ca (Eric M. Carroll) responded: >I cannot recall a single instance of needing this. You must have some >seriously warped transport agents along the way. Transport agents should >not, ever, ever ever ever touch the header, except to add tracing information. >No. Not. Negative. Get it right the first time and leave it alone. ACK! Have you NEVER seen a site with broken news software? The "Reply-To:" field is often set to "user@host.uucp" when it's often "user@do.ma.in", which is in the .signature of the message. I would like to get rid of the headers section also. It would solve several shortcommings of Elm. However, at least for now it does need a bit more discussion. :-) -Jeff -- Jeff Beadles jeff@quark.WV.TEK.COM Utek Engineering, Tektronix Inc. +1 503 685 2568 "Credo quia absurdum"
scs@lokkur.dexter.mi.us (Steve Simmons) (03/03/90)
jeff@quark.WV.TEK.COM (Jeff Beadles) writes: >ACK! Have you NEVER seen a site with broken news software? The "Reply-To:" >field is often set to "user@host.uucp" when it's often "user@do.ma.in", which >is in the .signature of the message. I would like to get rid of the headers >section also. It would solve several shortcommings of Elm. However, at least >for now it does need a bit more discussion. :-) ACK-ACK! Oooooo, look ma, anti-aircraft guns!! But seriously -- I disagree with this most strongly. Elm is quite popular at my site (and others) precisely because it insulates the users from (most) of the stupidity of headers. The very few times that headers are needed, they *like* having them in a separate menu. Agreed that there's a lot of dain-bramaged news software out there, but that's no excuse to force users to deal with headers they usually don't need, want, or understand. If someone's news software is broke, bitch at him -- don't needlessly complicate life for users who (mostly). couldn't care less. -- Steve Simmons ...sharkey!lokkur!scs scs@lokkur.dexter.mi.us "My occupational hazard's that my occupation's just not around." -- Jimmy Buffet
syd@DSI.COM (Syd Weinstein) (03/03/90)
I've kept out of this discussion so far, but I've gotta put my $.02
in....
Remember that Elm has two missions in life:
1. Be easy to use for beginners and non computer users (well
somewhat easy to use :-))
2. Not be so rediculous that experts won't touch it.
It is not its destiny (my vision, and as coordinator, I guess I
count for something) for it to be the all encompassing mailer to all
people. In fact, requests for 'expert' features get less weight
than for stuff for novices.
After all, there is MH and MUSH out there for all you experts. :-)
Please... keep in mind the novices when considering all the bells
and whistles for Elm....
Oh, and one more thing, be willing to write what you suggest, we're
all volunteers here...
--
=====================================================================
Sydney S. Weinstein, CDP, CCP Elm Coordinator
Datacomp Systems, Inc. Voice: (215) 947-9900
syd@DSI.COM or {bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235tanner@ki4pv.UUCP (Dr. T. Andrews) (03/03/90)
Two considerations seem to bother people.
(1) we don't use elm as news reply agent because it can't cope
with headers in a file as is normally desired.
(2) everyone hates the header-edit screen, which does not show
the headers to be added from "elmheaders
Solution to consider: have "elm" dump its headers into a file.
Include the "elmheaders" data. When/if the headers are to be edited,
just call up the local editor, as is done for the body. At message
transmit time, read the headers from the file to extract "To:",
"CC:", "BCC:". Use that information.
The out-going message should contain a cleaned copy of the header
file, followed by a blank line and the body file. Cleaning would
be the removal of obvious errors like blank lines and lines which
are neither continuations nor of the form "..*: ..*". (Note that
this rule will eliminate blank header lines such as "CC:" to no one.)
Of course, once Elm uses a file and optionally the local editor for
its messages, it becomes nearly trivial to add a "-r" switch to tell
it that it's in send-only mode, and that it may immediately read
headers from a file whose name is the next argument.
--
...!{bikini.cis.ufl.edu allegra bpa uunet!cdin-1}!ki4pv!tannereric@ists.ists.ca (Eric M. Carroll) (03/04/90)
>ACK! Have you NEVER seen a site with broken news software? The "Reply-To:" >field is often set to "user@host.uucp" when it's often "user@do.ma.in", which >is in the .signature of the message. As a fundamental principle of software engineering, I believe in fixing the broken software instead of breaking everything else to accomodate the bug. It may come as a surprise, but user@host.uucp is broken, illegal and generally wrong. And for expressing this truth I expect to be promptly flamed by many people who know nothing about mail. [As an aside, I ran one of the first few uucp-only domainized mailers in the Toronto area. It all worked and wasn't very difficult. .uucp, like .arpa was, is an excuse for those who simply cannot be bothered to put the effort into running their mail system well.] Lets users deal with what they know best - content. Give the experts a way to fiddle with the process if they need it (edit headers seperately). Never inflict expert level content and process on a novice, because you will pay for your sin by spending all those working hours you are supposed to be writing code answering questions from users who don't understand WHY they have to deal with all that detail, and don't care either. > I would like to get rid of the headers >section also. It would solve several shortcommings of Elm. Like what? I have no difficulty with it, and I consider myself a mail expert.
jpederse@encad.Wichita.NCR.COM (John.Pedersen) (03/04/90)
ray@philmtl.philips.ca (Raymond Dunn) writes: >The version in use is 2.2 PL16. >2) The user should be able to configure personal preferences as to how elm > should dispose of messages when you quit, so that, for example you don't > have to go through the delete/save/leave-alone dialogue for each > category. I found the personal preference section to have plenty of choice, have you edited your .elmrc file correctly? > I don't see any need for elm to ask you what you want to do with > messages you haven't touched - it should leave them alone in the > mailbox. Personally, I'm glad it doesn't. I like having my received, read but not acted upon messages waiting for me in received. Since I have a system that continiously watches my mail directory and signals me (across a network on another system) when mail arrives in my directory, I don't want anything that I've already seen sitting in there. >3) "<" for "sent", and ">" for "received", are non intuitive. It is if you think of > meaning incoming and < meaning outgoing. I think it was an excellent choice. >6) Mail header generation and editing during mailing and replying. > There is no doubt in my mind that the best way to handle this is as in > Rnmail, where the headers are treated as part of the message and you can > freely edit them. And I really appreciate it like it is as I can use system id's as addresses and it pulls the full name out of /etc/passwd and does all sorts of little things that would be impossible if the headers were directly editable in the header. I would think there would be a lot more mis-addressed mail if my users tried to use vi or gnu to get the syntax of the RFC compliant headers correct. Like you said, it's all a matter of personal preference. Personally, I like it. -- John Pedersen N5DKQ NCR Peripheral Products Division Engineering Computer Systems Support 3718 N. Rock Road John.Pedersen@wichita.NCR.Com Wichita KS 67226-1397 316-636-8837 VPlus 654-8837 FAX 316-636-8889
peter@ficc.uu.net (Peter da Silva) (03/05/90)
In article <5727@ists.ists.ca> eric@ists.ists.ca (Eric M. Carroll) writes: > Lets users deal with what they know best - content. Give the experts a > way to fiddle with the process if they need it (edit headers > seperately). Never inflict expert level content and process on a novice, And never inflict novice-level content and process on an expert. The header editor screen is strictly novice-level. Instead, dump the headers into a file and call the expert's favorite editor on them. It'd cut down the size of elm at the same time. -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
ray@philmtl.philips.ca (Ray Dunn) (03/06/90)
In referenced article, peter@ficc.uu.net (Peter da Silva) writes: >In article <5727@ists.ists.ca> eric@ists.ists.ca (Eric M. Carroll) writes: >> Lets users deal with what they know best - content. Give the experts a >> way to fiddle with the process if they need it (edit headers >> seperately). Never inflict expert level content and process on a novice, > >And never inflict novice-level content and process on an expert. Amen. > The header >editor screen is strictly novice-level. Instead, dump the headers into a >file and call the expert's favorite editor on them. Why to a separate file? An option which gives the headers as part of the text of the reply being edited gives the best flexibility. If separated, there is still the problem of copying information between them. Certainly retain the current invisibility of the headers for the novices, but why constrain the expert? >>As a fundamental principle of software engineering, I believe in fixing >>the broken software instead of breaking everything else to accomodate >>the bug. All vey motherhood and apple-pie, but what is the relevance to the discussion? Doesn't elm already allow you to edit the headers? The suggestion is only that it be done in a more consistent, useful way. In what way does this "break everything else"? It's ironic that the very first time I used elm to 'r'eply to mail, the mail bounced because the address needed fixed up. Until all the mail software out there that has a distorted view on life is fixed, I need the tools to easily repair their broken attempts at paths: and from: lines. Even uunet adds "uunet!" to every address it sees in the header, often totally inappropriately. >>Users care about CONTENT >>not PROCESS. They give not one whit about HOW it happened, just that it did. Until things start going wrong..... -- Ray Dunn. | UUCP: ray@philmtl.philips.ca Philips Electronics Ltd. | ..!{uunet|philapd|philabs}!philmtl!ray 600 Dr Frederik Philips Blvd | TEL : (514) 744-8200 Ext : 2347 (Phonemail) St Laurent. Quebec. H4M 2S9 | FAX : (514) 744-6455 TLX : 05-824090
eric@ists.ists.ca (Eric M. Carroll) (03/06/90)
>All vey motherhood and apple-pie, but what is the relevance to the >discussion? Because the broken software in question is the program that put the broken header in that line in the first place. Don't change all of elm's user interface just to satisfy some broken software that certain sites run. My novice user's like elm. If you want a more powerful user agent, use gnu or mh or mush. Lets keep elm's objectives in focus - the novice user has precedent. > Doesn't elm already allow you to edit the headers? The >suggestion is only that it be done in a more consistent, useful way. In >what way does this "break everything else"? The explicit suggestion was to put header info in with the reply, thereby allowing novice users to nuke messages with simple editing errors and confusing them even more with archaic and meaningless lines. Right now, it is somewhat hidden. Please follow the discussion - I have stated this already. >>Users care about CONTENT >>not PROCESS. They give not one whit about HOW it happened, just that it did. > >Until things start going wrong..... Then they hassle the local system admin. Do you really believe they solve the problem for themselves? If you do, you work with programmers, or very computer literate non-programmers. I work with scientists and administrators, who are not stupid, just uninterested in details that don't directly contribute to doing their job as they perceive it. And are certainly uninterested in mailer details.
peter@ficc.uu.net (Peter da Silva) (03/07/90)
> The explicit suggestion was to put header info in with the reply, > thereby allowing novice users to nuke messages with simple editing > errors and confusing them even more with archaic and meaningless lines. That's fine, but the suggestion was also made to make header editing, either within or without the main message, an expert-only option. This basically removes any objection based on what novice users might want to or need to do. And, of course, the external editor used for editing the headers could default to one that emulates the current behaviour. This means novice users would never even see a change. > Then they hassle the local system admin. Do you really believe they > solve the problem for themselves? If you do, you work with programmers, I work with programmers. I want a mail user agent that supports the people I work with. That helps me get *my* job done. ALL our users are accustomed to using vnews, readnews, and rnews... all of which expose them to these nasty headers. Even the administrative and other non-programmers. I haven't seen any of the dire consequences you're predicting. But even granting you that someohow things will get worse with Elm allowing header editing, it can be made as invisible as you like for novices without getting in our way. And it'll make the main part of Elm that much smaller, to boot! -- _--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ 'U` \_.--._/ "I've about decided that the net is not the place to do the right v thing. It might violate a charter somewhere ..." -- Spenser Aden
tom@surf.osf.org (Tom Jordahl) (03/08/90)
I'd like to put my thoughts on the subject of being able to edit the
headers in the edit buffer:
ICK! ICK! ICK!
I agree with Syd 100%: Elm was designed to be easy for the novice to use
but not so stupid that an expert wouldn't touch it.
I consider this annoying "Feature" of Rnmail to be as good example
as any why the "common person" has/will stay as far away from Un*x as
they can. It presents you with information that is usefull only to
an expert *in some instances*. I don't want to see it, keep it out
of my way.
As for adding it in, but turning it off, I think this would be an
example of "creeping featurism" which elm may (or may not) suffer
from already to some extent.
And the final argument is: Is anyone volunteering to impliment it?
In such a way that I'll never see it?
Tom Jordahl Internet: tom@osf.org
Open Software Foundation UUCP: ..!uunet!osf!tom
"A silly quote is only worth what you put into it." -- mepeter@ficc.uu.net (Peter da Silva) (03/08/90)
In article <4739@paperboy.OSF.ORG> tom@osf.org (Tom Jordahl) writes: > As for adding it in, but turning it off, I think this would be an > example of "creeping featurism" which elm may (or may not) suffer > from already to some extent. Correctly implemented, it will get *rid* of a major feeping creature in elm... the "edit headers" screen. Just extract that screen to an external program, and us soi-disant experts can screw outrselves up however we like, the header editing screen will become easier to modify, and elm itself will become smaller. Everyone wins... I'd implement it, except that under this old System III based Xenix/286 I'm running as fast as I can already just to stay in one place. -- _--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ 'U` \_.--._/ v
ray@philmtl.philips.ca (Ray Dunn) (03/14/90)
In referenced article, eric@ists.ists.ca.ists.ca (Eric M. Carroll) writes: > My novice user's like elm. If you want a more powerful user agent, use >gnu or mh or mush. Lets keep elm's objectives in focus - the novice user >has precedent. I've read the elm documentation from cover to cover vainly searching for any reference to the servicing of novice users as the prime reason d'etre of elm. But obviously, if that is *really* the case, elm isn't for me, unless I make the changes I feel necessary myself - as has been pointedly and very rightly suggested by Syd Weinstein. The hostility my seemingly reasonable wish-list seems to have created in certain quarters is unfortunate, but I did get a very reasonable response in others. I thought perhaps I could contribute a little from my experience, but relax, I will now crawl back into the hole I emerged from and fumble around for another mailer that may suit my needs better. > Please follow the discussion - >I have stated this already. Very sorry Eric, I'll try not to do this again, honest. I didn't realize who I was speaking to, and that following implies agreeing. Am I forgiven? (:-) -- Ray Dunn. | UUCP: ray@philmtl.philips.ca Philips Electronics Ltd. | ..!{uunet|philapd|philabs}!philmtl!ray 600 Dr Frederik Philips Blvd | TEL : (514) 744-8200 Ext : 2347 (Phonemail) St Laurent. Quebec. H4M 2S9 | FAX : (514) 744-6455 TLX : 05-824090