On 6/10/2014 7:27 AM, Barry Leiba wrote:
> The premise of your proposal is that users will notice that there's
> extra information, know what to do with it, and do the right thing,
> with reasonable consistency.
...
> Each of those conditionals will not actually be satisfied. User's
> tend not to notice such things. The tend not to understand what
> they mean. Even when they understand, they tend to evaluate
> choices poorly. They tend to apply choices inconsistently.
Yes, yes, yes, and yes (all modulo "are we letting 'perfect' be the
enemy of 'better'?" -- you have a *really* dim view of the average
users' capabilities!)
I think Dave's dim view is pretty much accurate, though I can't show
that in any concrete way.
There are a set of "User Expectations" and the backend has a strong
influence on satisfying the "user expectations." The three that the
US EPCA molded in 1986 are:
- Don't make private mail, public
- Don't censor the mail,
- Don't tamper the mail.
This has been relaxed over the years to a, I kid you not, to the "Good
Samaritan" provision which gives the backend more legal indemnifying
controls and it make it fit better the existing 150+ year old
exceptions provided to the newspaper industry which allows the
newspaper editor to alter the "letter to the editor" for "fit to
print" reasons.
But the more important point is that you're
presupposing that the changes are "better", and my contention is that
we don't know enough about UI design and user experience to say that.
We do. But we are adding so much doubt to it, the promotion is to just
pass everything to the user or do all the work at the client side.
Thats is the OLD WAY when thats all the mail routers/receivers did,
transport, send and receive and did no filtering whatsoever.
So what we are battling with is what work and where is the client or
server work done?
To people like you and me, it's clear that giving more information --
and especially such important information as this! -- is better.
Not always. System level considerations are a high consideration.
Just reject and forget about it. All empirical data tells you that
this is very feasible, reliable with an extremely low false positive
rate, and for the exceptions, its going to be a hard pain to shallow.
The LSP can no longer exist in a wild wild west world of
"unrestricted" mail processing.
The LSP needs to adjust.
Note, I am not trying to change the subject away from the MUA UI. But
this will always be a position that end-users, administrators will
like to impose that have no control over the system level operations,
the MSA, MTA, MDAs, etc. There are MUA considerations for sure, but
we need to focus on the DMARC policy issues, or lack of them, that is
causing such a high conflict between operations. We can't solve it
with MUA stuff.
But
that's not really true, and even information that we think is
essential... is actually confusing to non-technical users.
+1.
Here I can cite studies; I have one that looked at browser cues such
as the lock symbol, and found that users so misunderstand the lock
symbol that they (1) think a lock symbol on the web page itself is
*better* than one in the browser frame (that's quite backward), (2)
don't know what the lock symbol is telling them *at all*, and have
various cockamamie ideas about what it means, and so on.
We have to be very careful about such changes, and not assume that we
know what's better.
and to add to this, how about satisfying visual impaired requirements?
Too much? My first 1980's MUA (Silver Xpress Offline Mail System)
was the first to support what I called "Speech Friendly Interface" or
SFI that dealt with the MAIL-READY navigation for speech. It
supported special on-board cards such as "Vocal Eyes" and "Windows
Eyes" (https://www.gwmicro.com/Catalog/Window-Eyes/) Visual cues
needs to be translated to speech signals too. Today, there are
current W3C proposed standards/methods (web-base, CSS, etc) to satisfy
"SFI" requirements. Quick reference before I have to leave for now....
http://www.w3.org/standards/webdesign/accessibility
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
