Re: 2.1.3 Discussion Points

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

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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]