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.

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.

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

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.

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

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

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

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

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.

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.

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.

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.

->nobody

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/

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