Re: 2.1.3 Discussion Points

[Peter Bloomfield <PeterBloomfield bellsouth net>]

On 06/04/2004 11:36:20 AM, mike flyn org wrote:
[ snip ]
> 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).

OK--we certainly want Balsa to be simple enough to use for  
precisely those users.

> What about something like this:
>
> -------------------------------------------
> | Content | Attachments v | Message Parts |
> -------------------------------------------
>
> "Attachments" is a combo-box

I'm not sure what widgets we could use to implement that.   
`Content' and `Message Parts' (which might need to be renamed  
something like `Message Structure', to avoid confusion with  
`Attachments') are notebook tabs, and I don't believe we can mix  
notebook tabs and comboboxes in the same patch of screen.   
Perhaps a third notebook tab that reveals a flat list of the  
attachments?

> 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.

So the items in this list are basically the leaves of the  
`Message Parts' tree, but labeled as actions instead of objects?
[ snip ]

> 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 agree that there should be nothing labeled `commit', which is  
too vague.  But emptying the trashbox and expunging deleted  
messages in another mailbox are quite different actions, and some  
users like to have control over both.

I believe that a novice would be best served by making `hide  
deleted', `expunge on close', and `empty trash on exit' the  
default new-user settings.  That way, a message would vanish from  
the mailbox index when the user deletes it (or moves it to  
another mailbox), all deleted messages would be expunged later  
with no further action on the user's part, and messages wouldn't  
accumulate indefinitely in the trashbox, also with no further  
input required.

> 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.

Just to make sure we're on the same page: the only inconsistency  
I'm aware of is expunge-on-close, implemented in local mailboxes  
and not in IMAP.
[ snip ]

> Again, "Empty Trash" and "Expunge" are two operations that do  
> the same thing from a user's point of view.

OK, that's clearly a labeling problem, because the operations  
really are different.  Perhaps `Empty trashbox' would make it  
clearer that the action refers to the marked trashbox.  I believe  
some mailers use terms like `clean up mailbox' or `compact  
mailbox' to describe expunging.

> 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.

I must have misstated something.  Emptying the trashbox is  
nothing but removing messages from it, and neither the format or  
location of the trashbox, not of any other mailbox, have any  
relevance.  Likewise, any Balsa mailbox can contain messages  
flagged as deleted, which would be removed by expunging, all  
quite independently of format or location.
[ snip ]

> 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.

1. & 4. are the current situation, and you make a good case that  
more flexibility is needed.  3. seems like it would rapidly get  
tiresome, unless Balsa built a database of trusted senders.  So  
2. looks best to me:

-----------------------------------------------------
| Warning! This message refers to content at          |
| http://some.spam.com/some/image.jpg.  Balsa can     |
| retrieve it, but doing so may alert the sender that |
| you are viewing this material.                      |
|       --------------         --------------         |
|      |   Retrieve   |       |Don't retrieve|        |
|       --------------         --------------         |
|              [X] Don't ask me again.                |
-----------------------------------------------------

(just my $.02 worth...)

Peter