Compose screen changes (was Re: [imp] Attachment interface confusing to users)

[Edward Glowacki]

Changing the subject line, as we really have wandered away from just the
attachments interface... =)

On Wed, 2002-06-26 at 13:19, Chuck Hagenbuch wrote:
> Quoting Edward Glowacki <glowack2@msu.edu>:
> 
> > Also, buttons for to/cc/bcc do appear in other email programs.  I'm not
> > saying they're perfect, or the right choice for IMP, just that they are
> > used in existing email programs, so users may have encountered them
> > before.
> 
> These are relatively common, and I wouldn't be opposed to using them 
> instead of the Address Book link.

I'll keep that on my little list of possible redesign features then. =)

> > Expanding all three fields is probably OK, but I don't think that's
> > really the issue.  Personally I feel there has to be a better way to
> > implement the whole recipient section of the screen than using the
> > current interaction between to/cc/bcc and address-book/expand-names,
> > there's just something about the existing interface that feels awkward
> > to me.
> 
> Any better idea, after a bit for it to settle in your mind, what that is?

I think so.  It goes something like this:

There are two levels (for lack of a better word) of interaction: basic
and address-book.  

1. Basic is for quick-and-dirty use where users can enter an email
address or an alias in any of the to/cc/bcc lines.  There is no "expand
names" command.  On the "send" command, the addresses are passed through
the alias expander.  Any improperly formatted addresses or un-expandable
aliases would generate a warning, otherwise the message would be sent
(after the aliases are silently expanded).  The action is roughly
equivalent to hitting "expand aliases" followed immediately by "send
message".  

An example use:

to: chuck,ed
cc: imp@lists.horde.org
subject: compose screen
body: <blah blah blah>
[Send message]
(chuck and ed aliases expand fine, message is sent, user is returned to
message index)

The premise here is that commonly used aliases don't need to be expanded
(they're simple and unlikely to be incorrectly entered), so we remove
the expand names functionality and catch any typos on the way out.  

2. If a user wishes to expand aliases prior to sending the message, they
hit the "address book" command (however it is implemented) which loads
the address book popup (or an intermediate address book page if the user
doesn't want popups) and simultaneously attempts to expand all aliases
(if there are any).  The advantage of this is that if the alias is bad
and doesn't expand (which is somewhat likely for rarely used addresses
that the user would want to check the validity of in the first place),
the user is already in their address book where they can fix the problem
by selecting the appropriate address from the list.  A second advantage
of this is that the address book screen can afford to provide a lot more
detail about the addresses (such as which ones expanded from where,
which ones didn't expand, etc.) as well as a much better view of all of
them compared to the short one-line fields on the compose screen.  Users
can also add more addresses from their address book if desired, which is
fairly common even after adding some via aliases.  If there are no
errors, the user can just select "OK" to close the window (or transition
back to the compose screen) and all the addresses in to/cc/bcc will be
fully expanded at that point.

An example use: 

to: chuck, ed, imp@lists.horde.org
[address book]
add "cc: Jan Schneider" from address book
[OK]
to (updated): Chuck Hagenbuch <chuck@horde.org>, Edward Glowacki
<glowack2@msu.edu>, imp@lists.horde.org
cc (updated): Jan Schneider <jan@horde.org>
subject: compose screen
body: <blah blah blah>
[send message]

Since we're loading the information from the address book anyways, the
address book screen makes an excellent opportunity to expand aliases
without any additional work.  Worst case is that all aliases expand
correctly and no additional addresses are needed, so the user has an
extra mouse click required to say "OK" to the alias expansion.


Integrating this with some of the other experimental changes I made
could result in removing all 5 command buttons from the "options" area
(leaving "save copy in" and "request return receipt"):

If we replace the to/cc/bcc labels with buttons that link to the address
book and use something like what I just described, we can get rid of
both the "Address book" and "expand names" commands from the "options"
section.  "attachments" has had problems anyways, and I already tried
removing it from my experiments, so that might be safe to get rid of. 
"Spell check" can probably be relocated adjacent to the text box for the
message body or maybe down with the send/save/cancel buttons?  That
leaves only "special characters", which isn't really an "option" IMHO,
and I would guess that anyone who needs special characters probably
knows how to enter them from the operating system level because they'll
likely use them regularly in other applications as well.  (I could be
entirely wrong on this last assumption, as I don't use any special
characters, so keep that in mind... ;) )

I'd love to code all this up into a functional demo, but I'm not sure I
know enough about the internal workings of IMP to try it... =(  

-- 
Edward Glowacki			glowack2@msu.edu
Michigan State University	
"...a partial solution to the right problem is better than a complete
solution to the wrong one." (http://uiweb.com/issues/issue14.htm)