Re: 2.1.3 Discussion Points

["mike flyn org" <mike flyn org>]

[...]

>> I have some comments about balsa 2.1.3 that I would like to  
>> discuss with you folks.  I deploy balsa for several novice  
>> users for use in their homes as their primary email interface.

> Your feedback is greatly welcomed!
 
>> 1.  Handling of attachments is awkward for novice users.
 
> That's something we've struggling with.  As Albrecht notes, a  
> mime message can have a complicated structure, and sometimes you  
> need to see it--a forwarded message comes with an attachment: was  
> it attached to the forwarded message, or separately by the  
> forwarder?  However, a simpler way to present just the parts that  
> can be saved as separate files would be useful.

I agree fully with Albrecht.  However, I also assert that the current
situation does not work for novices (for example, people I wish to get off
AOL).  What about something like this:

-------------------------------------------
| Content | Attachments v | Message Parts |
-------------------------------------------

"Attachments" is a combo-box that would contain, for example, "View email as
HTML [ envelope icon ]", "View email as text [ envelope icon ]" and "View
biketran.txt [ text icon]."  Selecting an item in the combo-box would either
1) immediately display the selection in the "Content" window or 2) if this is
not possible, prompt the user to view the file using a helper
application/save the file somewhere.

> [ snip ]

>> 2.  Many of the menus seem unnecessarily complicated.  For  
>> example, the following options had me confused:
>> 
>> Mailbox->Empty Trash
 
> Hmmm--I guess it's the only item on the Mailbox menu that doesn't  
> refer to the current mailbox--perhaps it belongs on the File  
> menu?

I would agree that this could go under the file menu.
 
>> Mailbox->Commit Current
>> Mailbox->Commit All

> Yes, those need changing--see  the recent thread  
> http://mail.gnome.org/archives/balsa-list/2004-June/msg00008.html

I would argue that the commit menu items should be removed entirely.  Either
IMAP mailboxes should be commited automatically or the "Empty Trash" option
should perform commits on all IMAP mailboxes (perhaps "Empty Trash" could be
renamed).

I feel that users should not neeed to use different operations for different
types of mailboxes (POP, IMAP, local).  Balsa should present a small, well
thought out set of operations that seem to do the same things regardless of
the mailbox type. 

>> Message->Move to Trash
 
> I'm not sure what's confusing here.

Too many operations when you look at the aggregate (see above).
 
>> When using IMAP, "Move to Trash" does not move a message, it  
>> marks it to be deleted.
 
> With my IMAP mailboxes, it moves the message to my designated  
> trashbox, which is in my local folder tree--perhaps that's what  
> it's doing for you.  If you have a Trash mailbox in your IMAP  
> folder tree, you can designate it as your trashbox, and then  
> `Move to Trash' will indeed move a message there.

>> "Empty Trash" does not have any affect on IMAP mailboxes,  
>> "Commit .*" must be used.  Can't we come up with some type of  
>> policy requires only a "Move to Trash" action or otherwise  
>> simplifies things?
 
> Perhaps `Empty Trash' isn't the best label.  This action removes  
> all messages from your designated trashbox--it doesn't affect  
> messages elsewhere marked as deleted.  I believe `expunge' is the  
> most common term for removing messages marked as deleted-- 
> elsewhere, I've suggested replacing the `commit' items with  
> corresponding `expunge' items.
> [ snip ]

Again, "Empty Trash" and "Expunge" are two operations that do the same thing
from a user's point of view.  It is only to those that understand the
difference between IMAP, POP and local folders and their associated protocols
that there is a difference.  For example, the interface mutt uses provides
one consistent method of deleting mail from local and IMAP folders.
 
>> 3.  The address book interface could use some improvements.
 
> Agreed!

Any ideas out there in balsa-list-land?
 
>> 4.  The remote content within HTML emails is not displayed.   
>> This includes <IMG src=...>, etc.  I could imagine security and  
>> privacy reasons for this, but the bottom line is that it breaks  
>> a lot of users' ability to read email that they receive from  
>> legitimate sources.  I think this policy needs to be discussed.
> 
> As Albrecht noted, there are sound reasons for not loading remote  
> content by default.  Otoh, We could add 'load remote content' as  
> an option on the right-click popup menu for html parts...

Okay, I think this type of HTML email is crap.  So we agree.  And I
understand that it may be used to alert spammers that an email was opened
(see my privacy/security reference).  But here is the problem: my
mother-in-law can't use balsa to conduct business with certain vendors
because they use this type of email to coorespond.  So, what will balsa's
policy be?

1.  No remote content displayed, users think their computer is broken.

2.  A warning is displayed that users will ignore and click through.

3.  Perhaps assert that to users that if you know foo bar org then it is
probably safe to open the email.  Prompt user to open.

4.  Allow the user to save the message elsewhere and open it with an external
browser.  This has been discussed and I think it is an ugly solution.

etc.

I think we need to come up with a policy to deal with this issue.
 
[...]

--
Mike