91551 - Remove folder radio boxes in "Copies and Folders" pane again

Status: NEW

(SeaMonkey :: MailNews: Account Configuration, enhancement)

Description

[Ben Bucksch (:BenB)]

Change made for bug 23625: The Copies and Folders pane of the Account Manager
now has a radio box with hardcoded values for "Sent", "Draft" and "Templates".

Why to we have the default folder names hardcoded in the UI with a radiobox? I
think, this is completely unnecessary - the app and the user can do the same
without these radioboxes.

For the case that we want to create the default folder and they don't exist yet
(bug 23625), just set the backend-pref to that folder (e.g. imap://server/Sent)
and let the backend code create it when needed.
If the user wants to change it to another folder, he can do that even faster
than with the current UI, because he doesn't have to change the radiobox.

So, I see no advantage in the current UI with the radio boxes. But the current
approach has the several disadvantages:
- It clutters up the UI.
  We have 6 dropdown and 3 option groups, while we could do the same with
  3 dropdowns and no option groups.
- The dialog is so tall that it is unusable on 640*480.
- It is slighly slower to interact with (see above).
So, I ask to back out the change to the Copies and Folders pane.

Comment 1

[David :Bienvenu]

Ben, how do you propose to allow the user to pick a folder that doesn't exist
from the folder picker? We can't just set the backend pref. What if the user
comes to this dialog before they've sent mail? What do we show them as to where
their sent mail is going to go? This current UI is much easier for 99% of users
- they don't need to scroll through the folder picker looking for something
named Sent.

Comment 2

[Ben Bucksch (:BenB)]

> Ben, how do you propose to allow the user to pick a folder that doesn't exist
> from the folder picker?

Why would a user need to do that?

If we create a new account, we will set the pref. If the user wants to alter it,
then most likely to a folder that already exists (for me: "Draft" instead of
"Drafts").

If the user wants to pick a foldler that doesn't exist yet and doesn't happen to
match your default names, he still has the same problem.

Anyways, if there exists a case where the user wants to pick a yet non-existing
folder, he can always go back to the folder pane, create the folder and then go
back to Account Manager to set that folder as special folder. Unconvient, but
obvious.

> What if the user comes to this dialog before they've sent mail?

I assume that you display the folder as "ghost folder" then, i.e. if the perf is
sat to a non-existing folder, an entry for that folder is created in the dropdown.

> This current UI is much easier for 99% of users - they don't need to scroll
> through the folder picker looking for something named Sent.

huh? These 99% who like the default names won't have to touch the drop-down at
all, will they?

Comment 3

[David :Bienvenu]

You can't argue that the new ui requires more steps, and then suggest an
approach where 99% of the users have to go create a folder called Drafts, come
back to the prefs dialog, and find the Drafts folder way down in the list of
folders. Or you can argue that, but it's not a convincing argument.

When we create a new account, and the user goes to the prefs, what are we going
to show them as the folder their drafts are going to? If the online Drafts
folder doesn't exist, we can't show them that folder. I believe your case of
wanting a folder other than Drafts, for example, is the < 1% case.

Now, you could argue that we could change the dropdown to have as the first item
a folder that doesn't exist called "Drafts on foo.com" and default to that.
That's probably tricky to do since we're using a default folder picker and we'd
need to customize it, and it might be a bit confusing for users. I think the UI
as is is pretty easy to understand. The main drawback is that it does take more
space, as you point out.

Comment 4

[Ben Bucksch (:BenB)]

> You can't [...] suggest an approach where 99% of the users have to go create
> a folder called Drafts, come back to the prefs dialog, and find the Drafts
> folder way down in the list of folders.


No, 99% of the user would have to do nothing at all.

I assume, you mean that 99% want to have a folder "Sent" on the server
associated with the same Account.

If the user sets up a new account with the Account Wizard, we set the Sent
folder to exactly that folder (<imap://<server>/Sent>), regardless if it exists
or not.

If the user then sends an email without opening the Copies and Folders pane,
Mozilla will try to save the email there. If the folder doesn't exist, it will
be created automatically. If the user goes to Copies and Folders afterwards, it
the right, existing folder gets shown.

If the user goes to the Copies and Folders pane of the Account Manager without
sending a mail first, we will have to display the "ghost folder" entry. That
ghost folder is a folder that is sat but not yet created. It could be displayed
in another color or font style. Considering that the folder in fact does no
exist, regardless of the UI, I do think that this UI would be *less* confusing
than the current one.

In neither case does the user have to go back to the Folder Pane to create the
folder.

If the user wants to alter the folder to an existing or non-existing folder,
both UI approaches are no different.

Yes, given, we would need to do a little trick to create the ghost folder. I
don't know the technical details, but doesn't the folder picker base on RDF? DO
you have access to that hierarchy from the Account Manager? If so, you could
just (conditionally) insert that node from the Account Manager, not touching the
folder picker code at all.

Comment 5

[scottputterman]

Marking Wontfix.  You need a new bug with a better suggestion than backing out
code which is just fine.

Comment 6

[Ben Bucksch (:BenB)]

putterman,

I described how the new code is not at all "just fine". Not only that it
violates the minimalism paradigma, it also makes the dialog unusable for users
on 640*480 screens.

I think, I did make a very concrete proposal how the dialog would behave in the
various situations. Please tell me what you have in mind with "better proposal".

Comment 7

[Ben Bucksch (:BenB)]

Maybe my formulation was just unfortunate. This bug is not only about plainly
backing out the the change, but also about the changes required to make the
dialog work with the new feature in bug 23625. (I think, the only change needed
is the implementation of the "ghost folder", which I guess is not too much work.)

Comment 8

[scottputterman]

ok, I'll admit, the back out part is what made me mark this wont fix.  I'm going
to reopen and mark this future. I'll explain why when I mark it future.

Comment 9

[scottputterman]

Moving to the future milestone.

I agree with you that the previous solution was the ideal solution if we had had
the ability to put a ghost folder.  But it was a lot of work to put the ghost
folder which is why after a few years of having IMAP users complain that their
special folders were defaulting to local folders we came up with this solution.
Actually, this solution has been around since 4.x (except in 4.x a separate
dialog came up).

So, I'm marking future, because I believe this solution is acceptable given that
the problem it solves was an important one to solve.  If someone came up with a
way to have a Sent/Draft/Template folder in the drop down when it didn't really
exist, then I think most of us would be happy to go back to the old way.

Comment 10

[(not reading, please use [e-mail] instead)]

putterman's comments 07-20 sum up why we did what we did in 4.x and in 6.x

http://www.mozilla.org/mailnews/specs/accounts/#AccountSettings
marking wontfix since we're following the spec.

Comment 11

[Ben Bucksch (:BenB)]

Seth, putterman said
> I agree with you that the previous solution was the ideal solution if we had had
> the ability to put a ghost folder.  But it was a lot of work to put the ghost
> folder


Unless I misunderstood something, he agrees that my proposal is the ideal
solution but he doesn't want to assign the resources to implement it. This is a
typical example for nobody/future, not WONTFIX (which means should not be fixed).

> marking wontfix since we're following the spec.

I haven't seen that this part of the spec were discussed anywhere. I disagree
with it, and such a bug is perfectly legal.

Reopening.

Comment 12

[Ben Bucksch (:BenB)]

->nobody

Comment 13

[Arun Prasannan (polar)]

This bug is being marked EXPIRED as it has seen no activity in a very long time.

If you think that the issue reported might still be relevant, please test with a recent release of SeaMonkey and if the problem persists feel free to re-open the report. Thank you.

http://www.seamonkey-project.org/

Comment 14

[Mark Banner (:standard8)]

Bulk reopening incorrectly expired bugs - no activity does not constitute no bug - these need proper checking.