[messaging] Mail UIs

[Jeff Burdges]

Trevor mentioned the difficulty of building a nice user-interface for a
mail reader at RWC yesterday.  

In the past, I've wondered if one should separate the mail receiving
functionality from the mail archival functionality.  In other words,
there would be two linked applications, one that reads incoming mail
and one that accesses archived mail. 

I'm assuming an end-to-end encrypted mail system that's resistant to
traffic analysis, and that does not retain messages by default, like
Pond.

I'd think message senders should specify if messages should be archived
by default, or maybe even sent straight to archive, or a separate
mailing list tool, by passing the inbox.  Asking that a message be
archived asks the sender for metadata like either keywords, like
ephemeral mailing list names, or a title.  If a recipient overrides the
senders non-request for archival then they get to specify such
metadata.  This metadata is preserved by replies. 

The question is : Can/should the interfaces be streamlined differently
for the different activities of reading incoming mail and reviewing old
messages?  

Of course, these two applications would interact rather tightly, like
when you reply to an archived message, or send a private mail from a
mailing list message.  It might even be that simply keeping two mail
reader windows open with different configurations accomplishes the same
goals better.  

If however there appears to be a worthwhile advantage to keeping the
interfaces separate, then there might structural advantages in
development where more user-interfaced developers focused on the
archival reader did not need to worry much about security, and the more
security conscious developers dealing with the inbox tool could
port/copy the better user-interface decisions of the archival tool.

Just thinking out loud,
Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20160107/96edae4c/attachment.sig>