Closed Bug 448716 Opened 14 years ago Closed 1 year ago
Preferences UI clean up, Wiki for mockups
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/2008071615 Fedora/3.0.1-1.fc9 Firefox/3.0.1 Build Identifier: This bug have 18 dependencies which all deals with a major UI clean up in the preferences menus. bug 448691 Move "Manage Identities" to Edit menu bug 448692 Move "Show only display name..." to Addressbook View menu bug 448693 Move "Wait X seconds before making a message..." to "Server Settings" bug 448694 Move "Remember the last selected message" to Display bug 448695 Move "Open messages in" to General bug 448697 Move "Disk Space" to "Disk Space" bug 448698 Move "Attachments" to "Copies & Folders" bug 448699 Move "Addressing" to "Composition & Addressing" bug 448700 Move "Forward messages..." to "Composition & Addressing" bug 448701 Move "HTML" to "Composition & Addressing" bug 448702 Move "For messages that contain 8-bit..." to "Composition & Addressing" bug 448703 Move "Auto Save every ... minutes" to "Server Settings" bug 448705 Move "Confirm when using keyboard..." to General bug 448706 Move "Wrap plain text messages at..." to Formatting bug 448708 Move "Plain Text Messages" to "Composition & Addressing" bug 448710 Move "Junk" to "Junk Settings" bug 448713 Move "When new messages arrives" to "Server Settings" Reproducible: Always
These are not significant enough bugs that we would hold a release for. Therefore blocking denied. Additionally marking as invalid as I don't think we need this bug to be a meta - the bugs are already tracked by the fact they are present here in bugzilla. I think it would also be worth in future, discussing suggestions such as these on news.mozilla.org / mozilla.dev.apps.thunderbird or the replicated mailing list https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Flags: blocking-thunderbird3? → blocking-thunderbird3-
I am reopening this bug, as I emailed with David Ascher about my ideas, and this is what he replied: "The best advice i can give is to file bugs with as specific descriptions of the problems you see, so that they end up being considered. As you know there are a lot of UI "bits" to Thunderbird, and I'm sure we won't be able to tackle all of them at once. Identifying the areas that are the most problematic or the little changes that will have the biggest impact would be really helpful."
Status: RESOLVED → UNCONFIRMED
Flags: blocking-thunderbird3- → blocking-thunderbird3?
Resolution: INVALID → ---
(In reply to comment #2) > I am reopening this bug, as I emailed with David Ascher about my ideas, and > this is what he replied: > > "The best advice i can give is to file bugs with as specific descriptions of > the problems you see, so that they end up being considered. As you know there > are a lot of UI "bits" to Thunderbird, and I'm sure we won't be able to tackle > all of them at once. Identifying the areas that are the most problematic or > the little changes that will have the biggest impact would be really helpful." > I still disagree for a meta bug for this, as the bugs themselves are perfectly adequate. I'm denying blocking TB 3 again because we wouldn't hold a release for any of the changes requested. Setting the wanted flag to ? until our user experience person (Bryan) has confirmed if we want to change these or not.
Summary: Major UI clean up → Preferences UI clean up
When I have to configure something in Thunderbird, I have no idea where to find it. There is only one way, clicking on all the tabs in both Preferences and Account Settings. That really gives a bad user experience, and I think that should be solved before TB3. I.e. moving all Account related settings out of the Preferences. Perhaps it would be a good idea to have a Global Account Settings entry? The entries in the Account Settings would then go something like this: Global Settings Server Settings Copies & Folders Composition & Addressing Offline & Disk Space Junk Settings Return Receipts Security Account 1 Server Settings Copies & Folders Composition & Addressing Offline & Disk Space Junk Settings Return Receipts Security Account 2 Server Settings Copies & Folders Composition & Addressing Offline & Disk Space Junk Settings Return Receipts Security and so forth...?
Martin, it seems like you want to move everything from the Options Window, to the Account Settings. You said you can't find anything without clicking on every tab. Options is more of a general overall, while account is more specific. Can you give more reasoning on this change?
(In reply to comment #1) > I think it would also be worth in future, discussing suggestions such as these > on news.mozilla.org / mozilla.dev.apps.thunderbird or the replicated mailing > list https://lists.mozilla.org/listinfo/dev-apps-thunderbird If a review and reorganization of the preference panes is considered, it may be worth to set up a page (or set of pages) on the Wiki for this purpose to collect ideas, as has been done for other areas (Account Manager and Folder Panes). Deriving targeted bugs from those is probably a better approach than having a rather uncoordinated collection of individual bugs.
To Comment #5 I don't want to move everything from the Preferences menu to the Account Settings, only the account related. As you can see in the comments on the already closed bugs, they are closed due to "I don't like" reasons from the developers. From a users point of view it is impossible to know on before hand where e.g. change the attachment type. And in some cases, the options are both in Preferences and Account Settings.
Comment #6 I have spend a lot of time making these mock ups, and writing the descriptions, so you can probably imagine that getting the Preferences and Account Settings cleaned up, is something I think is important. That being said, I want to do what is best, so if that is setting up a Wiki, that is what we do. But I want to be sure that there are some weight behind it first.
Martin, don't get me wrong, I certainly appreciate that you did a lot of thinking on this and spent quite some time drawing those mock-up images. Discussing a larger concept first for any major reorganization of the preference and account panes in a single context (and location = Wiki) I think would be helpful. There are similar cases where plenty of individual suggestions for a problem were made in various bugs, and it's easy to lose track then for the larger picture.
I can see the advantages of a Wiki for this, but as you say it is a major reorganization, so how does this become a milestone for TB3?
(In reply to comment #7) > To Comment #5 > > As you can see in the comments on the already closed bugs, they are closed due > to "I don't like" reasons from the developers. > > From a users point of view it is impossible to know on before hand where e.g. > change the attachment type. Actually, bug 448713 and Bug 448700 are duplicates, not closed because of "I don't like". And for the others, those are WONTFIX, "The problem described is a bug which will never be fixed. " This is because it is difficult to change, will create more confusion, or for other reasons. This is not an arbitrary decision by the devs.
Comment #11 I could make such a Wiki, but it would take many hours, so I would need to have some weight behind first, so it will be a goal for TB3 to clean up the Preferences. Can you make that happen?
Version: Trunk → unspecified
Correction. I ment to say Bug 448697 and Bug 448693, but I think the last one was closed for a good reason.
There is also meta bug 232486, "Some global options need to be moved into account settings". Re comment #13, I won't have time for setting up such a page, and it appears that the discussion has already spread out into the individual bugs, so let's see how this works out...
Just wanted to say that I think this is a great effort to examine all the preferences. Even if some of the changes aren't pushed forward I think that's more because the thinking behind the preference needs to be changed more than it should be moved from the global to account options. Bugs like bug 448702 show that some of these prefs haven't been examined in a while. In general my feeling has been that the preferences should be a place where people go to change the options that are common to all users and account options are more for mail configuration changes or ways to override global preferences. I'd like to keep this in mind as changes are made.
To Comment #17 I don't quite understand how you would like to have the account, users/identities, and program behaviour split/grouped. The way it is now, is that: * Account Settings +Identity Manager(users) is in Accounts. * Program behaviour + global account settings is in Preferences. What I would very much like to see is a clear split of all these, so it becomes: Preferences: program behaviour Account Settings: global and local Identity Manager: user manager (bug 448691) As an overall goal, I think it would be totally cool to have each account 100% split into a directory so migrating an account is just copying 1 directory, and then you have everything related to that account. I.e. cache, address book, junk, emails, and settings for that account. So ~/.thunderbird/*/Accounts/0001/ could e.g. look like Cache/ Junk/ Mail/ Addressbook.sqlite Settings.xml
Yes, I'd like to see the preferences be the most common program behavior tweaks. What would global account settings be? Beyond moving things from prefs to account settings I'd like to see something removed or changed such that we have less prefs in general. Here's an example of what I'd like to see, looking at bug 448710 about Junk settings. There is a behavior setting for handling Junk that belongs in the preferences. The details of what each account does with a Junk folder belongs in each account settings. So I would keep 1 setting for Junk behavior in the prefs and the exact behavior (or implementation) details in the account settings. Then take the other filter logging and reset training data and move it to advanced or somewhere below advanced. Also, I think it would be excellent if there was a plan towards getting out of all these tabs within tabs in the preferences. Each section shouldn't have more than one tab. If we need another section or a little bit bigger window we can think about that, however we have far too many prefs as it is right now.
In Preferences I think the following belongs in a Global Account Settings menu: * Forward Messages: [Inline/As Attachment] * Auto Save every [ ] Minutes * The whole Composition->General->HTML section * Configure text format behaviour [Send Options...] * The whole Composition->Addressing section * The whole Privacy section that being: * Junk * E-mail Scams * Anti-Virus * Passwords * The whole Attachments tab that being: * Attachments folder * Download actions * Determine how Thunderbird handles return receipts [Return Receipts...] * [v] Compact folders when it will save over [ ]KB I suggest those to be moved to a Global Account Settings menu, because each of these are direct email or folder related. If you look at Edit->Account Settings->Return Receipts Thunderbird have already introduced the Global Settings concept. What Thunderbird here means by "Global" is "what have been configured in the Preferences". I think if would be totally cool to get rid of the sub tabs like you suggested. Firefox have done that, except for the Advanced tab. I think there have come a lot of good ideas on how the configuration experience could be improved, but it is hard to see the big picture with all these bugs and comments spread over each of them. I would gladly write a wiki with all the suggestion and ascii mock ups of "before" and "after", so it is easy how the end result will look. But that will clearly take many hours, but I could have it done within 2 weeks, if "Improve configuration experience in Thunderbird" becomes a milestone for TB3.
Martin, can you create a wiki, and post a link to it from this bug. We will be evaluating the Options menu for TB3.
Status: UNCONFIRMED → NEW
Ever confirmed: true
To Comment #21 Excellent. I have created the user "d2xdt2", can you give me permissions to create such a page? Or alternatively, create an empty wiki page to me, and give me edit permissions for that?
Martin, I have created a new page on the Wiki for documenting any ideas coming out of this, http://wiki.mozilla.org/Thunderbird:Preference_Settings (it is empty as of now, but it's easier to document and adapt proposals there than in a bug report). (In reply to comment #19) > Also, I think it would be excellent if there was a plan towards getting out of > all these tabs within tabs in the preferences. Each section shouldn't have > more than one tab. If we need another section or a little bit bigger window we > can think about that, however we have far too many prefs as it is right now. I agree with the tab issue. Some panes are rather crowded, whereas others are almost empty. A somewhat more homogeneous distribution of preferences would be desirable, possibly splitting off current tabs to their own new panes. While I see the notion of reducing the overall number of preferences which are represented in the UI, this is always a delicate trade-off. If you have too many UI elements, it's hard to find a specific setting you are looking for. On the other hand, if you keep those too "lean", the user may not see that a specific feature is actually available when it is not represented in the dialogs. People are always surprised by the magic one can do in the Config Editor, frequently providing the solution they were looking for...
To Comment #23 Thank you for the wiki template. I have now made the first iteration of reducing the number of sub-tabs. Please see the wiki. The things I see that should be addressed are: * Deciding for tab lay out * Making mock ups of all tabs with options included * Deciding on options that can be deprecated * Deciding which options should be moved to other tabs * Deciding which options should be moved to a new Global Account Settings menu * Making mock up of Global Account Settings menu * Deciding which options should be moved to other tabs * Clean up current Account Settings * Submit bug reports Can someone with experience which these kind of things give feed back on how the procedure should be?
Having had a look at your proposed pane/tab layout, I think I'd like this. It appears to be more intuitive with the "important" functionalities in single-tab panes, and the advanced ones collected in several subtabs at the end. While it may catch people by surprise who are used to the current layout, it would follow the style introduced by Firefox more closely. > * Main = General + Attachments > The window size may not need to be increased. I'm a bit skeptical if not extending the dialog size can be ensured (and if it is a goal to start with). Following your example, combining the General and Attachments panes to a single Main pane, without removing any preferences or their arrangements, would increase the height of the box by about 40% from 450 to 640 pixels (measured on Windows with XP Classic theme), and also introduce five blocks where there were three before. So, there needs to be a balance between number of categories represented in each pane and the number of panes, which I don't think has to be limited to the current six panes.
Looks like a good start. Just a couple of points on what you have so far. * We have no shame in stealing what Firefox has done, so feel free to look at similar sections and areas to them and just take it wholesale when it applies to Thunderbird. :) * At the same time there are lot of things that have been take from Firefox a while back that don't make as much sense anymore. * I'm not sure tags should have it's own tab, while they are something we plan to promote in the interface I don't want to promote managing them as a list. I think they'd be better served as a button launching a small dialog. * What privacy is for, wouldn't something like security make more sense for the password area? * Don't forget to add Calendar (lightning) at the end, before advanced I'm interested to see your breakdown of what pieces go where. I would start by creating different sections below for each tab and creating the tab inside that section.
To Comment #25 > * Main = General + Attachments > The window size may not need to be increased. You are right, that this would increase the window size quite a bit, but I hope this would be resolved when we come to the phase: * Deciding which options should be moved to a new Global Account Settings menu In Comment #20 wrote I a list of options that I think belongs in a Global Account Settings menu, where the Attachment options are in. If it is approved to move Attachments options to a Global Account Settings menu, that would free a lot of space. So for now I would very much like to get a "Okay for a first iteration for tab lay out, and let's change it later, if the number options are not balanced across the tabs or the window size would need to be increased too much."-approval =) I have added the phase: * Re-evaluate the options in the Preference tabs to avoid having to increase the window size. to the mile stone map at the wiki. Would you be okay with that we leave the Main tab with too many options for now, and fix it later, when the options have been moved around?
> * We have no shame in stealing what Firefox has done, so feel free to look at > similar sections and areas to them and just take it wholesale when it applies > to Thunderbird. :) I'll keep that in mind, if there are something that can be Firefoxed =) > * I'm not sure tags should have it's own tab, while they are something we plan > to promote in the interface I don't want to promote managing them as a list. > I think they'd be better served as a button launching a small dialog. Okay. When we come to milestone 2, I'll do that. > * What privacy is for, wouldn't something like security make more sense for > the password area? Good point. Firefox does that also. The wiki have been updated. > * Don't forget to add Calendar (lightning) at the end, before advanced The wiki have been updated. > I'm interested to see your breakdown of what pieces go where. I would start > by creating different sections below for each tab and creating the tab inside > that section. Ok. I will do that when I get "okay for now on milestone 1". Other updates to the wiki are: * Added milestone map section * Added "Status" section * Added "Global Account Settings menu" section * Added "Proposed options for Global Account Settings menu" I know that Bug #448697 is closed, but it was closed the very same day I submitted it, and a lot might have changed since?
Added "Single window version mock up" of Global Account Settings menu to the wiki.
Added "Account Settings and Preferences definitions" to wiki.
(In reply to comment #28) > I know that Bug #448697 is closed, but it was closed the very same day I > submitted it, and a lot might have changed since? > That remains a global setting, so I think we should leave it as it is.
You are right. I thought that Bug #448697 was about to move it to a Global Accounts menu.
(In reply to comment #32) No, you proposed to move it to account settings, but that is fine. I was wondering, should we move some of this discussion to the Wiki Discussion page? I think that would prevent this page from getting too overcrowded with debates, when no patches are being discussed, just thoughts. The Wiki might be a better think tank.
Summary: Preferences UI clean up → Preferences UI clean up, Wiki for mockups
As for the "Depreciated/New Options" section that Tyler added to the Wiki page, please make sure that any suggestions are based on the current 3.0b1pre builds, not on the 2.0 release. As pointed out in bug 448693 comment #3, options have changed and may even have a different behavior now. (In reply to comment #33) > I was wondering, should we move some of this discussion to the Wiki Discussion > page? I think that would prevent this page from getting too overcrowded with > debates, when no patches are being discussed, just thoughts. The Wiki might be > a better think tank. This can be done and may be easier in terms of threading to discuss different issues in parallel. It's always a bit tricky though if multiple locations have to be watched for a topic, but that's the case here already anyway.
To Comment #34 I completely agree. I have therefore undone/removed the section. Tyler: Please don't make random changes to the wiki. Use the "Show Preview botton". And don't leave the wiki in a broken state! http://bayimg.com/NaKPKAAbD I have undone/removed your "Add new features" section, as there is no point in having empty sections. I think we should stay focused on the subject. If there are options that you would like to see in Thunderbird, then submit a new bug.
I am using the nightly build. Martin, i did not leave the Wiki broken. I added Tabs, as that is an option that is in Firefox, and is missing in your mockup.
Tyler: You may have a different opinion when something is broken, and if that's the case, please don't edit the wiki. Look at the screenshot in Comment #35 I made for you, and the wiki history where you made the changes. You are right, that the Tabs tab was missing, but with our latest edit, you broke the wiki again! And in addition, you broke my style by not aligning the tabs. 14:20, 16 August 2008 Tyler (Talk | contribs) (10,626 bytes) (Undo revision 104494 by D2xdt2 Tabs is in FF, so it should be in the mockup See screenshot. http://bayimg.com/HakAbAabe I don't want to spend my time on you breaking the wiki.
Rather than making uncoordinated changes to the main page, I'd suggest that any discussions should take place either here or on the Talk page. The main page should in my opinion reflect the current state of discussion with a certain consensus among the contributors.
I agree, and so will move to there to talk about this more.
Tyler, did you coordinate your changes between 14:20, 16 August 2008 and 21:33, 20 August 2008 with Martin? As emphasized in comment #38, it should be avoided that anybody makes arbitrary changes to the main page without proper discussion either in this bug report or on the Talk page. I see neither of this given for the change in the milestone criteria or references. Please let's maintain some discipline to avoid that things are getting more confusing than necessary. In general I think that one person should be in charge of the main page, and others add their comments and proposals to the talk/discussion page. I would see Martin in this role, given that he initiated this process to start with.
(In reply to comment #40) I did not receive a reply from Martin from my talk page section on the changes (I assume you are talking about the deprecated options section). That section is only to track options that have or are planned to be removed. It does not affect the milestone requirements (I am not sure what you mean by that, as the only change I made there as an internal link, nothing to the requirements themselves). I also made a fix to the Firefox mockup, adding Tabs, where it wasn't before (and I DID fix the alignment). The only thing I did with the milestone was start a talk discussion. I think that doing that was entirely in line with the procedure for Wikis, starting a discussion before major changes. I was not planning on doing that change, just starting a discussion.
I'm not going into further detail who edited what (please restore the reference for milestone #6 though), and it is certainly good that you corrected the optical issue with the alignment. Coincidentally, I had just added a comment on the Talk page about the Depreciated section, which I personally think is not useful as designed now. I could have just removed it (after you added it, Martin removed it, then you re-added it, etc.), but rather I'd like to figure out if and in which way relevant bugs need to be tracked, so that then whoever is primarily in charge (or somebody else to whom this was delegated) can make the respective correction. This is common practice with other such pages on the Wiki (e.g., I wouldn't modify Bryan's Account Wizard page without his approval).
I did not realize I had removed that reference (I have restored it). For now, I will move the rest of this to the Talk page.
This seems to be stalling a bit. Though there has been some work done on a Global Account Settings. I'm not particularly interesting in the Global Account settings, at least I don't want to work on something like that until the preferences are as clean as they can be. I've started a page under my user account for preferences: https://wiki.mozilla.org/User:Clarkbw/Preferences Feel free to copy all or parts of that. I've taken a slim perspective on the preferences by starting from scratch and only adding the items I could see were necessary. A few other items could remain to be added, but many of them simply require a change in how the Thunderbird works. To move forward I believe we need to finish with a preferences UI layout and have bugs filed for all the agreed changes made.
Looks like Martin and Bryan are approaching the problem from opposite ends, thus will hopefully meet at the optimum solution in the middle. ;-) It strikes me in the comment #44 proposal that a lot of "more", "customize", "advanced" buttons show up for the 2nd-tier preferences. This may be necessary to avoid that too many preferences are ending up in the depreciated section (see my comment #23, last paragraph). I think it's better than the equal-weight tab arrangement of the current preferences, as it provides some hierarchy of most important versus somewhat less important preferences. The disadvantage is that additional dialog windows are popping up for those (like the current Fonts settings in the Formatting tab of the Display pane, but saving the intermediate tab level and directly going from the pane to sub-dialog level would already be an advantage). Given that framework, each preferences would fall into one of these tiers: 1) Preference is located in a main preference pane; 2) it should go into a sub-dialog of a button in a pane; 3) move to a tab of the Advanced pane (no sub-dialogs?); 4) remove/depreciate UI element for a preference. Borderline cases could be 1.5, 2.5, 3.5, and each of the existing or somewhere proposed preference UIs (I'm currently aware of bug 445088 and bug 451599) should receive such a score to determine where it is supposed to end up. This would be similar to mile stones #2.-4. in Martin's proposal, but a bit more specific in terms of establishing a hierarchy. The latter part of mile stones #4 and #5 would be approached afterwards when following Bryan's scheme, even though potential candidates should be flagged during the scoring process already.
To get some idea which preferences are currently represented in the panes, I've written a little tool (not necessarily perfect, but seems to work) that collects those from the XUL and DTD sources. This gives 132 elements based on the August 23, 2008 code. Note that each button and checkbox has its own entry here, even if multiple elements are combined as a logical unit. Also, any changes (additions, removal) currently under discussion in other bugs are not considered in this inventory. Despite comment #44, I still think that we should start off with the current set of preferences rather than from scratch, following mile stones 2.-4. of Martin's list. Each current UI element has some history how it got there, thus should be reviewed if it is still adequate. When filling the panes up from empty, it is likely that preferences may be missed despite having valid use cases. To make this list more useful, it could be converted to a table per pane, UI elements forming tight logical units combined, suggestions pending in other bugs incorporated, and then those tables posted in one or more subpage(s) of the current Wiki page. Everybody could add their scores (in accordance with comment #45 or otherwise) in an own column then as desired.
Comment on attachment 335182 [details] Inventory of current UI elements for global preferences This tabular inventory is obsoleted by the version on the Wiki (and has some errors anyway). The current list can be found on my personal user page at https://wiki.mozilla.org/User:Rsx11m/Thunderbird:Preference_Scoring and also contains links to the sources for each existing preference. The score sheet has associated a score with each preference, where I figured that a score of "1" should indicate preferences which are either of immediate need for the initial setup, or accessed frequently enough to warrant a "prime" spot in a pane; scores of "2" are for preferences still needed to be accessible but of more advanced nature; "3" covers everything else that should go into one of the Advanced pane tabs; finally, "4" indicates candidates for removal, where I frankly didn't find any where I had the ad-hoc feeling that those are obsolete and should be removed. The "a,s,m" suffixes indicate candidates to be moved either into a different pane or which could be converted to per-account/server settings, and I've added some further thoughts on a couple of panes. If anybody wants to copy this for your own scoring, be my guest, or we can create a global copy and everybody adds their personal column. We should also link to those user-space pages from the main Wiki page then, replacing/incorporating the Depreciated Prefs section. The idea for the following mile stones is to break up the tables and rearrange the rows into the new panes and tabs. Also, I found the following bugs which should probably block this "pseudo-meta" one as they are dealing with either the preference or the account settings: > bug 86607, [RFE] UI option for disabling format=flowed > bug 373590, character encoding pref. menu should not be display | fonts > bug 433824, Signature is appended to bottom of message when told to reply above quote not clear > bug 445088, Implement UI for mail.reply_quote_inline and mail.content_disposition_type prefs > bug 451599, Add preferences UI for disk cache size and clearing the cache > bug 451620, remove the Advanced Preference for Connection timeout > bug 452711, use firefox default font chooser for display > bug 452890, move System Defaults from General to Advanced -> General > bug 452909, remove the shredder start page preference from the general tab
Attachment #335182 - Attachment is obsolete: true
WOW! What an amazing piece of work you have done there! It sure looks useful for a complete fresh Preferences and (Global) Account settings menus. A script to auto generate mock ups would be pretty cool =) With all the bugs concerning Preferences and such it is easy to loose track of where we are going. Bryan: Do you have an agenda, so we can adjust to it?
Yeah, really nice work! Here's my plan forward. We've looked at the preferences from 3 different angles right now. 1) Trimming down the current prefs and moving towards an Account Options system. 2) Starting from scratch and designing the preferences from the ground up 3) Analyzing the current prefs for usage type I'm aiming towards a designed preferences (2) while using the analysis of current preferences (3) to determine what else should fit in the main pref views. I find this approach best because debating where each individual preference goes is tedious and difficult; plus it often loses sight of the overall goal. However having some kind of data on how and what preferences are used allows us to enhance a fresh perspective on the preferences with others that are also necessary. We should probably use this as the main tracking bug for our new preference interface. I'm going to begin adding more bugs that steal preference UI from firefox and make them block this bug. Also I think we'll need to WONTFIX the other preference bugs already attached to this that we don't think we want to do.
Also wanted to make a note that I think having an Advanced -> Display preference section might help to clean up a lot of the current advanced preferences that are clogging up the Advanced -> General tab and blocking moving a number of main preferences over to that.
I am all for WONTFIX all my bugs for this meta bug, and doing a complete new Preferences. In Comment #47 rsx11m had found some more Preference related bugs. I just looked at your wiki, and you sure have done at lot of great mock ups. Here are some thoughts: * According to bug #218999 tabs is blocking TB3. Firefox have a Tabs tab. Are TB3 also going to have such, or will the tabs behaviour be very simple, so options are not needed? * Are you familiar with?: bug #311640 (new message alerts/sounds should be on a per account basis) In your mock up, have you the alert option. Can this alert bug make it for TB3?
(In reply to comment #51) > I am all for WONTFIX all my bugs for this meta bug, and doing a complete new > Preferences. Lets just look over the bugs attached to this. Some of them (like the attachments bug) just need to be pushed along. > In Comment #47 rsx11m had found some more Preference related bugs. Here's my quick review on these bugs, not the final word, just thoughts. > bug 86607, [RFE] UI option for disabling format=flowed I'm not really interested in this, the problem exists in the message viewing and should be handled there instead of in a preference where people are less likely to look. > bug 373590, character encoding pref. menu should not be display | fonts Some good points in here, however I think it needs a cleaner design than what is suggested. > bug 433824, Signature is appended to bottom of message when told to reply above quote not clear This one is a problem, but more of a per account problem and not really a preference dialog issue. > bug 445088, Implement UI for mail.reply_quote_inline and mail.content_disposition_type prefs I've been trying to avoid these preferences because I think this is an option people might want to choose at composition time instead of a preference which happens every time. > bug 451599, Add preferences UI for disk cache size and clearing the cache Because we're using the same firefox disk cache we'll need to add this so people can clear / remove that cache. > bug 451620, remove the Advanced Preference for Connection timeout I already made a patch and got this one reviewed. It's just awaiting a check-in; I expect it to make b2. > bug 452711, use firefox default font chooser for display This has a patch that probably needs some cleanup and review. I'd expect this to make b2. > bug 452890, move System Defaults from General to Advanced -> General > bug 452909, remove the shredder start page preference from the general tab When bug 456872 lands we'll have enough room in the general tab to make these happen. > * According to bug #218999 tabs is blocking TB3. > > Firefox have a Tabs tab. Are TB3 also going to have such, or will the tabs > behaviour be very simple, so options are not needed? I think our tabbing might require a preference, this is why I'm moving things out of the Main preference tab to make room. I don't think our tabs will require an entire section like Firefox does, however I've been planning for needing the Open in a Tab / New Window style pref somewhere. > * Are you familiar with?: bug #311640 (new message alerts/sounds should be on a > per account basis) I'm a bit unclear about what should be done here. I've been talking with people about changing message alert to be more like filters, such that they could be run on any number of situations. I think we need to step back and look at message alerts from a grander user perspective before making changes like switching things into strictly per-account options. > In your mock up, have you the alert option. Can this alert bug make it for TB3? All of this stuff can make it for TB3, however we're starting to run low on time. (another reason why I want to copy Firefox pref code)
I sure hope your patches get submitted for b2. They look great! About bug 373590, character encoding pref. menu should not be display | fonts Isn't that a legacy feature from the Netscape days? Wouldn't it be possible to pull this information from $LANG on Linux at least? In my /etc/sysconfig/i18n do I have: LANG="en_GB.UTF-8" SYSFONT="latarcyrheb-sun16" If it is not a legacy feature, then I think it should be moved to Advanced. About the alerts: That would just be so cool to have it as filters. Clearly a fresh idea, that would have a lot of potential.
(In reply to comment #52) > > bug 86607, [RFE] UI option for disabling format=flowed > I'm not really interested in this, the problem exists in the message viewing > and should be handled there instead of in a preference where people are less > likely to look. Agreed, especially after the discussion in bug 448706 on the wrap-length preference and its relation to flowed format, it appears to be most useful if flowed formatting could be disabled or enforced when the actual message is viewed or composed (that's an issue on both ends, not just display). > > bug 445088, Implement UI for mail.reply_quote_inline and mail.content_disposition_type prefs > I've been trying to avoid these preferences because I think this is an option > people might want to choose at composition time instead of a preference which > happens every time. That's certainly true for mail.content_disposition_type, which is why a composition-time mechanism is envisioned in bug 452092. That appears a bit more complex, thus not sure if this would come any time soon. In general, neither the "inline" nor "attachment" defaults are suitable for all cases... As for mail.reply_quote_inline, this would enable the inclusion of currently displayed attachments. Since their display can still be toggled with a menu option View > Display Attachments Inline on a per-message basis, I'd think that would be well suited as a global (enabling) preference. > > bug 452890, move System Defaults from General to Advanced -> General > > bug 452909, remove the shredder start page preference from the general tab Now that an Advanced > Display tab has been introduced by bug 456872, I could also imagine a corresponding Advanced > Composition tab to accommodate the more technical composition preferences (or have "Advanced" subdialogs for the main panes, as suggested before).
(In reply to comment #54) > > bug 452890, move System Defaults from General to Advanced -> General > > bug 452909, remove the shredder start page preference from the general tab > Now that an Advanced > Display tab has been introduced by bug 456872, I could > also imagine a corresponding Advanced > Composition tab to accommodate the more > technical composition preferences (or have "Advanced" subdialogs for the main > panes, as suggested before). Sounds interesting. What options do you think would fit in there? Are the enough options for such a tab?
Good question, I'm afraid that we just removed the best candidates for such an advanced composition tab with bug 448702 and bug 448706. :-) Anyway, potential candidates are probably all which have a "2" scoring in https://wiki.mozilla.org/User:Rsx11m/Thunderbird:Preference_Scoring#Composition_Pane that I could see in a separate dialog, or any composition-related preference introduced by the bugs I referred to in comment #47. The general issue remains how "full" we would like the individual panes to be, what are criteria for moving prefs into a separate dialog within that pane, and when to consider it advanced enough to move it into the Advanced pane...
I have just updated my score sheet for the current status, which should reflect what is coming with 3.0b1, for which the string freeze went into effect last week. Also, I've finally removed the "Depreciated" section from the initial Wiki page, which was quite obviously obsolete now. (In reply to comment #55, possible Advanced > Composition tab) > What options do you think would fit in there? Are the > enough options for such a tab? Well, I was also having UI elements proposed in bug 445088 and bug 460285 in mind, but since those have been won't-fixed, probably nothing left that would justify opening yet another tab there.
I'm moving the URL back to the main page, as it in turn refers to any suggestions on User-space pages, thus this appears to be better.
wanted‑thunderbird3-; meta bug
Flags: wanted-thunderbird3? → wanted-thunderbird3-
If this is a tracking bug, should probably move to core>tracking, right?
No, this bug is specific to the Thunderbird Preferences and it's tracking nature indicated by the "meta" keyword, definitely not a Core bug.
Status: NEW → RESOLVED
Closed: 14 years ago → 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.