Closed Bug 474523 Opened 16 years ago Closed 15 years ago

remove reply, reply all, forward, delete, junk, and forward/back buttons from default mail toolbar

Categories

(Thunderbird :: Toolbars and Tabs, defect)

Product:
Thunderbird
Component:
Toolbars and Tabs
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 3.0b4

People

(Reporter: clarkbw, Assigned: clarkbw)

References

Details

(Whiteboard: [no l10n impact])

Attachments

(1 file, 1 obsolete file)

updated patch for review
2.02 KB, patch
standard8
: review+
Details | Diff | Splinter Review
With the addition of the reply and forward buttons inside the message reader pane the default toolbar should not include the reply and forward buttons. Once bug 461098 has landed the reply all button should be removed from the default toolbar as well. This change is being made to increase the space given to the new search entry, part of the thunderbar ( bug 452281 )
I have to say i'm a bit hesitant about removing reply/replyall/forward. It's just so fundamental functionality.
How about the Delete and Junk buttons?
right, I thought there was another bug for those already but I guess not. updating title to reflect the change.
Summary: remove the reply and forward button from the default mail toolbar → remove reply, reply all, forward, delete, junk buttons from default mail toolbar
Summary: remove reply, reply all, forward, delete, junk buttons from default mail toolbar → remove reply, reply all, forward, delete, junk, and forward/back buttons from default mail toolbar
Assignee: nobody → clarkbw
Flags: blocking-thunderbird3+
Not that I've actually seen the new search entry to know how it's going to behave with limited space, but it seems a bit odd to give it lots of space only for new profiles. I could see either (or both) "we have to have more room, so we have to change the toolbar id to get that room" or "we need to get rid of the redundant buttons, so we need to change the toolbar id to get rid of them for existing profiles" but expecting all existing users to realize that we're leaving it up to them to make their toolbar usable, uncramped, not totally broken and filled with ellipses, whatever the actual effect is, doesn't seem quite like the right solution. Is the new search entry going to be a separate thing in addition to the existing search, a new toolbaritem with a new id which replaces the old item, or close enough to the old item that it can just slip in with the same id without messing up extensions that try to overlay the search, and will need to work with both the old and the new? The first two of those three possibilities (adding something new which we want to see on everyone's toolbar) are why we changed the toolbar id in Tb2 - search moved from a separate toolbar into the main one - which I expected would raise a great hue and cry, resetting everyone's toolbar customizations, but in fact it didn't. Hardly even made a ripple.
Assignee: clarkbw → nobody
Component: Mail Window Front End → Toolbars and Tabs
QA Contact: front-end → toolbars-tabs
The plan for the new search (bug 474701) is to replace the old quick search entry. This is necessary because having both would create a bit of confusion about which to choose and what keybindings enable which entry. I think you've got it right. So I guess the real patch needs to follow what you're saying, changing the toolbar id as well.
Bryan, I'm assuming that you want to own this bug, since you've been working on it already, so I'm assigning it to you. If that's not the case, and you'd prefer I find someone else to work on the real patch, feel free to hand this bug back to me.
Assignee: nobody → clarkbw
Whiteboard: [b3ux]
Status: NEW → ASSIGNED
I don't think this bug is a good idea. The current location of the Reply and Forward buttons is consistent with the vast majority of other windows apps (the Bold button in Word is in the toolbar, and not next to the text either). It's a bit like moving the Back and Forward buttons in Firefox elsewhere. Why? Also, humans recognize shapes and colors better than words, and the current header pane buttons for Reply an Forward are text-only (no icons). This bug should wait at *least* until that is mended. BTW: The same goes for all the buttons this bug wants to dislocate. PS. I have been using the nightly builds with the header pane buttons for months now, and have *not once* used the buttons there (other than deliberately for testing purposes). Think about that a moment.
This is essentially waiting on the new search ( bug 474701 ) and the landing of the reply / reply all / reply list button ( bug 45715 ) updated icons don't need to block this but would be nice
Whiteboard: [b3ux] → [b3ux][m3]
Depends on: 474701, 45715
this is sliding with the dependent bugs
Whiteboard: [b3ux][m3] → [b3ux][m4]
What is the plan for deletion of multiple messages? Will the message preview pane contain something in the multi-select case?
also need to depend on bug 454829 which is already marked as blocking
Depends on: 454829
slipping to m5. this isn't a difficult change, only that it's waiting on other larger changes
Whiteboard: [b3ux][m4] → [b3ux][m5]
Whiteboard: [b3ux][m5] → [b3ux][m6][waiting on blockers]
gotta stay one step ahead of the competition... er, blockers
Whiteboard: [b3ux][m6][waiting on blockers] → [waiting on blockers]
Target Milestone: Thunderbird 3.0b3 → Thunderbird 3.0b4
Seeking clarification of some points. 1) Will we be able to toss this new search bar into the toolbar pallet if there is no need for it? 2) The buttons being removed from the toolbar, will they still be available in the toolbar pallet? 3) Will the new search bar be vertically sized correctly to fit into the Menu bar the way the current quick search bar does?
I fully sympathise with the sentiment behind comment #15. Could someone please post a screenshot of the new search thingamajig? I'd like to see what is supposed to replace the toolbar buttons that users are used to being in the toolbar since, well, forever. Why is filtering / managing old emails so much more important than the everyday activities of replying, printing, deleting? Do users really want to manage their "conversations" more than they want a consisten place for their UI (across their applications)? I sure hope this new arrangement is more like the awesome-bar and less like the new tab switching panel.
(In reply to comment #15 and comment #16) While the major parts of bug 474701 appear to have landed, the UI didn't yet. Pending confirmation from someone official, my guess is that the new search bar would be a toolbar item like any other, and that the current buttons will still be on the icon palette in "Customize...", thus can be exchanged as desired. In combination with the customization aimed for in bug 465138 regarding the header-pane buttons, you may be able to hide the buttons you want to have on the main toolbar in the header pane to avoid redundancy. This obviously depends on the type of customization eventually implemented by bug 465138.
Attachment #364981 - Attachment is obsolete: true
(In reply to comment #15) > 1) Will we be able to toss this new search bar into the toolbar pallet if there > is no need for it? Yes, the new search will operate as a similar toolbar item as the existing quick search. > 2) The buttons being removed from the toolbar, will they still be available in > the toolbar pallet? Yes. I obsoleted the patch now because the plan will be to change the toolbar id, giving everyone the new, more limited, default set. That's a bit of a one time pain but necessary to make sure the new search shows up for people who have customized the toolbar in anyway. All of the existing items will still be available to users in the toolbar pallet. > 3) Will the new search bar be vertically sized correctly to fit into the Menu > bar the way the current quick search bar does? I wasn't aware of this. In Window it seems to increase the size of the menu bar when inserted there. Either way the new search should use a similar vertical height, it will be using more horizontal space however. The gloda mega-bug, bug 474701, has lagged the release of beta3 a bit and I'm fully expecting a lot of cleanup work to polish the search afterwards. We have a beta4 release specifically aimed at polish work for the search entry and other features. Once this all lands and you see issues, please file them and link them against the tracking bug, bug 497199.
(In reply to comment #18) > (In reply to comment #15) > > 3) Will the new search bar be vertically sized correctly to fit into the enu > > Menu bar the way the current quick search bar does? > > I wasn't aware of this. In Window it seems to increase the size of the menu > bar when inserted there. Either way the new search should use a similar > vertical height, it will be using more horizontal space however. > A few Pixels vertically are not a problem, it's the ability to use space in the menu bar that is the focus of 3). I prefer the Sky Pilot Classic theme because some of it's tool icons have sizings that can fit the menu bar also. It's a good location for easy access to less frequently used tools such as the View Bar and search.
No longer blocks: 474598
(In reply to comment #18) > Yes. I obsoleted the patch now because the plan will be to change the toolbar > id, giving everyone the new, more limited, default set. That's a bit of a one > time pain but necessary to make sure the new search shows up for people who > have customized the toolbar in anyway. Even without having customized the toolbar, this will certainly catch the established users by surprise... :-\
(In reply to comment #18) > Yes. I obsoleted the patch now because the plan will be to change the toolbar > id, giving everyone the new, more limited, default set. That's a bit of a one > time pain but necessary to make sure the new search shows up for people who > have customized the toolbar in anyway. Bug 247973 never was fixed, because it could produce issues for existing users. But now you don't respect customized toolbars for existing users? Which sense does it make, to force all users to use the limited set? I'm using Mozilla Mail/Thunderbird for many years and the these buttons on top are essential for me. It's one thing to implement buttons in the message reader, but forcing users to get rid of the nice, customizable toolbar is another thing. Many people will moan, when they notice, that their customized toolbar is gone and that they have to restore everything again. Are existing users not important anymore? :(
(In reply to comment #21) > toolbar is gone and that they have to restore everything again. Are existing > users not important anymore? :( Existing users are very important. So important, in fact, that we want them to experience the new UI features we have been working on!
To expand on comment #1 and comment #8, the overall changes in the 3-pane window and the message viewer, specifically moving the action buttons from the toolbar (where they have been since before Mozilla 1.0 was released) into the header pane (being initially hidden there depending on the context) is a substantial modification. This reminds me a bit on what Microsoft did when going from IE6 to IE7 or Office 2003 to 2007, giving those applications essentially a new identity by over-overhauling their user interface so that their established user base didn't recognize them any more. Thus a simple word of caution not to overdo it. As for the search bar, I realize there are still things to come, but so far it appears similar in its size requirements as the quick-search bar, thus it's not quite obvious why the additional space of seven toolbar buttons will be needed.
After updating Shredder Saturday morning I experimented with the Menu Bar and was able to place Quick Search, Gloda(?) Search, View picker, and the inop Folder Bar all side by side with space to spare. Win32, Res=1024x768, Shredder Full Screen. When those items were together I noticed that there is a design discrepancy, where the Quick Search widget is taller than the other three. Seems those 4 items need some polish to be of matching height. Also, noted the View widget is wider than needed for the content of it's dropdown listing. Given my results, it's not clear that buttons have to be default swapped to the toolbar pallet to accomodate the new search bar.
(In reply to comment #23) > As for the search bar, I realize there are still things to come, but so far it > appears similar in its size requirements as the quick-search bar, thus it's not > quite obvious why the additional space of seven toolbar buttons will be needed. Will the new search entry[1]: 1. be there *together* with the quick search box, or 2. *replace* the quick search box? If 1: That seems a waste of space and confusing (maxim: if given two similar choices, the user will waste more time trying to decide which choice to choose than he would save by making the better choice). If 2: Then the functionality of the two search methods should be combined into one search box (e.g., via drop-down, like the current Quick Search). Also, there would be no need to move the buttons away from their traditional (10+ years) and better (UI consistent with other apps) location in the toolbar. The reason I ask: Currently, the Quick Search searches only the current folder and it maintains the threading (both very useful features). In stark contrast, the new search entry opens a new tab (a bit jarring), shows the results of all folders (usually overkill?), and only gives a flat list of the results (lose conversations). [1] This thing needs a better/catchy name. BTW: In a recent nightly, the new search proceeded to index all my mail files (5-10 k mails). This took a long time (10-20 minutes) and caused severe slowdown on my computer (WinXP, dual-core, 2 GHz, 2 GB RAM) during this time. It was a horrible user experience. This operation should be much better load-balanced.
(In reply to comment #25) > 1. be there *together* with the quick search box, or > 2. *replace* the quick search box? The latter seems to apply based on comment #6: > The plan for the new search (bug 474701) is to replace the old quick search > entry. This is necessary because having both would create a bit of confusion > about which to choose and what keybindings enable which entry. But then, there are quick-search bugs pending (e.g., bug 462578) which appear to be active, thus it's ambiguous where this is going.
This has to be one of the worst ideas yet for all of these gui changes (which as more users see them, seem to hate). Users (including me) will be furious if you remove customized toolbar settings, and removing them from the defaults will be also be a huge mistake and very confusing. Everyone is used to using the main toolbar for basic functionality, and it is much more convenient as well. I do not think most people would rather click reply down inside the message body instead of the header. I don't quite understand this need to eliminate "redundancy" -- TB has always been about choice, and taking things away is a huge step backwards. Also, so many of these changes and regressions are related to the new search capabilities. For some, I'm sure the new search will be great. However, I suspect there are many people (like myself), who do not have huge collections of e-mail and even need to have advanced search capabilities. Why must we all be forced to see and use something like this? There has to be a better way of letting everyone know it's there without such drastic measures. PLEASE take a step back and try to understand a wider range of viewpoints and get some feedback before making rash decisions! If this keeps up TB3 will be a huge disappointment. I apologize for the rant, but I am so incredibly frustrated with all of the gui changes that seem to take away things and ruin much of what I've loved about TB. In fact, I have spent considerable time creating a new theme based on many of the old icons, and adding customizations to userChrome to get things back the way I like. To me, that just doesn't seem right. And most frustrated users do not have this kind dedication or technical skills, and might just quit using TB completely.
I completely agree with the above comment. If I heard about the Gloda-Search the first time, I thought a huge searchbar would come, but that thing isn't larger than the Quicksearch is. So is it really needed, to remove so many buttons from the nice, flexible toolbar and make existing users angry, that their previous settings are not respected anymore? Is it really needed, to force users to use fixed buttons in the message reader instead? A customizable toolbar was one of the main Firefox/Thunderbird advantages. Main functions are always on top, using buttons in the message reader isn't comfortable at all. Please, if you won't get rid of the message reader "improvements", make at least this bug here a Wontfix. I doubt, that even new users will like these improvements, most of the old users will worry about it.
To clarify, this is just changing the *default* state for the main toolbar. The buttons will still be a couple clicks away in the "Customize" window if you actually want them.
Please leave rants outside of this bug, it only makes things more complicated. I'm sure the Thunderbird team is aware of users that are not content with this decisision, but please try to look at it from a different angle. We all love the reply/all/list buttons in the main toolbar, but that's because they have always been there. If you get used to the reply button being directly on the message, then you will see that it means less mouse travel time and buttons directly in context.
Sorry about my rant, it's just that I want to make sure everyone's paying attention to the concerns. But I still disagree with the assessment that we only like the icons in the main toolbar because it's just always been that way. I think some of the problem is forgetting that different users use the application in very different ways. For example, I use the 3-pane view and almost never open a message up in a new tab. In this case, the main toolbar is always closer and having to mouse down into the message body would be a huge inconvenience. However, at work we use Lotus Notes and in that app I always DO open the e-mail in a new tab, and use the buttons in the message header, not the toolbar. Forcing users to become accustomed to a new way of working just because "it's for their own" good is not so nice. Yes, sometimes shifts in UI use is required, but this is such a basic thing in almost every app that I'm certain most would be quite upset. In my examples above, I should not be forced to open TB3 mail in new tabs to have the most convenient features, and conversely Notes should not force the use of a 3-pane view. Choice is extremely important. There should be a way to prominently display the new search features without making what some would consider radical UI changes. Hopefully as the UI lands some good ideas will come forward.
(In reply to comment #30) > To clarify, this is just changing the *default* state for the main toolbar. To clarify, that just makes things slightly *less bad*. This bug would mean jet another setting I would need to "fix" on all my users' installations (adding the "Size" column being another). (In reply to comment #31) > If you get used to the reply button being directly on the > message, then you will see that it means less mouse travel time and buttons > directly in context. Not true. See the "PS" in comment #8 (now plus five months!). I'm not aware of any mock-up of the new search bar, so it seems nobody knows how much space it will possibly need. Therefore, it seems that moving the UI buttons to the header was someone's "cool" idea, and since he already programmed it, it became a fait accompli - no matter what the consequences.
(In reply to comment #33) > I'm not aware of any mock-up of the new search bar, so it seems nobody knows > how much space it will possibly need. http://www.visophyte.org/blog/2009/04/01/thunderbird-gloda-exptoolbar-protovis-paninaro-oh-oh-oh/ Also, perhaps now would be a good time to point out that these UI changes really aren't all that different from Gmail's web interface, which I'm sure plenty of people are used to by now.
That "cool idea" was established in bug 449691, and the discussion (or the lack thereof) here gives me a bit of a deja-vu feeling. The first 50 or so comments on that bug provided a presentation of the header-pane project, attracting various counter-arguments against that redesign, as one would expect. Similar to what's going on here, commenters against it are expected to provide solid reasons, rather than the proponents of the change providing solid reasons why that change has to be done. Isn't the latter the usual course of action? While bug 449691 went into "production mode" and generated what we see today, the underlying issues are still present and need to be considered here and in the other bugs. Again, ignoring valid arguments doesn't invalidate them. > (comment #30) this is just changing the *default* state for the main toolbar. Sure, but it's not a one-click solution to get everything back. Assuming that bug 465138 will eventually provide for a customization palette, you would still need to open two palettes and perform 12 drag-and-drop action to get to the familiar setup in the current branch releases. Thus, this argument only in part holds (and it will be "fun" to teach newbies in the forums how to do that...). > (comment #31) If you get used to the reply button being directly on the > message, then you will see that it means less mouse travel time and buttons > directly in context. Maybe, unless bug 464309 (or bug 325144 now, the scopes are not well defined) get implemented letting the header pane scroll with the message. In this case, they are out of reach - nothing in the toolbar any more, so where do you click the reply/forward/delete/etc then? And yes, this is indeed all known by the Thunderbird team, unless they forgot about the discussions in bug 449691.
(In reply to comment #34) > Also, perhaps now would be a good time to point out that these UI changes > really aren't all that different from Gmail's web interface, which I'm sure > plenty of people are used to by now. (Quoting Bryan Clark in bug 449691 comment #38) > I don't think there's a "web mail look", if you examine msn, hotmail, yahoo, > and gmail they all have different views and looks for many different pieces. > Even if there was a specific look I don't think it's what we want to aim for. > We are not copying any one of these systems, we may look at pieces they use, > but it would be ridiculous to attempt to copy any one of these systems. > Thunderbird has a goal of representing messaging or communication to people in > an understandable way; that does not necessarily translate into Thunderbird > needing to look like a client application (or web mail). Our goal is to serve > the users, whatever look we choose is for their benefit not the computer or > operating systems.
(In reply to comment #34) > > mock-up of the new search bar > > http://www.visophyte.org/blog/2009/04/01/thunderbird-gloda-exptoolbar-protovis-paninaro-oh-oh-oh/ OMG. What are you guys thinking? Stop praying to the false god of SEARCH! ;-)
(In reply to comment #37) > OMG. What are you guys thinking? Stop praying to the false god of SEARCH! ;-) Oh yeah ... A working "recently filed to" functionality would make a lot of searching superfluous ...
Guys, please, move discussion to the newsgroup! See the first rule of https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
The intended design of (1) the search functionality and (2) parallel plans on the header-pane design are important parameters for this bug and therefore any discussion on those topics of relevance, thus this is not in violation of the etiquette rules (minus the ranting, but sometimes even that is necessary).
I don't check, why Bugzilla is open and watchable for all people, if valid points from end users are not welcome. :) Many people here pointed out a couple of valid arguments, but instead of listening to us, we should write in the newsgroups, which probably never get any attention from any dev? I doubt, that it's the aim of anyone here, to break the rules, we just show you our points. It's true, that the buttons will be still available in the toolbar, but doesn't change the fact, that you ignore existing user settings. As rsx11m said, you need many clicks to restore your old buttons. Ignoring previous user settings is always risky. Also wrong is, that we love the 'Reply', 'Forward' etc buttons in the toolbar, just because they are there since the dawn of time. For most people it's simply more easy to use functions from top of an application, instead of the middle of an application. Also the fact, that most programs use such functions on top for many, many years, makes it more risky, to change that.
> (comment #39) please, move discussion to the newsgroup Experience with other bugs unfortunately demonstrates that splitting up a discussion over multiple locations (bugzilla, newsgroups, wiki, IRC, blogs, etc.) does not necessarily improve the communication. In fact, I think it contributes to the unhappiness here that some discussions (and decisions) are held elsewhere and the overall picture is not clear when reading the bugs. Somewhat more transparency in the decision making process would be appreciated. To name an example, the link provided in comment #34 could have been posted much earlier, the size-requirement question came up in comment #5 already.
Hey, I'm going to try to summarize what I seeing in various places, but there's a lot going on so I'm sorry if I miss somethings. * The change is substantial because of the high visibility, be careful. :) Agreed and that is why many of these comments are helpful. We don't have a transition plan in place yet but we really need one for this to be successful. If you have suggestions for transition ideas that would be really helpful. * The current location of the buttons is traditional and long standing Yes this is correct and I don't want to break tradition without reason. However I don't think tradition necessarily gives justification for the toolbar being the best location. Tradition has been a reason for just as many (if not more) bad things as it has been for good things. I'm assuming that we can make the changes we have good enough that for most people it won't matter that we've broken this tradition. However that won't be the case for everyone which is why the old way is still possible, just not the default. * The current location of the buttons is consistent with other applications Yes, this made the decision to move the buttons very difficult. Breaking tradition for something new and better is a little easier that breaking the mold of everything around you. Here's part of why I felt this change is for the better. I don't believe the existing applications that use toolbar buttons are a good location, it has never been justified as so. When the first GUI mail applications (non terminal based) came out toolbars were available and people used those. Other email applications copied this look, not because it was best, but because it was what was done and they had the widgets needed to make it happen. I've written this up before for discussion on the newsgroup so I'm not going to re-write it all again. The toolbar is an optimal place for buttons that can be used at anytime, it is not good for buttons that can only be used some of the time. The best location for any buttons is directly near the item it is acting upon and the best time to reveal any button to a user when when it is available. You can argue that Firefox has toolbar buttons buttons that disagree with this but you'll likely see those buttons go away or become less prevalent over time. e.g. the refresh and stop buttons do not make sense in the toolbar, they are related to the url bar only and will move closer to that location (FF mockups already have). https://wiki.mozilla.org/Firefox/4.0_Windows_Theme_Mockups and https://wiki.mozilla.org/Firefox/3.7_Windows_Theme_Mockups * The new header buttons are worse, they lack icons, take space, etc. The new buttons do need some more polish work and that is planned happen in this round of beta work. I think it's possible to add some kind of icon the the header buttons however we're tight for horizontal space there so we never went through with it. I have lots of thoughts icons in user interfaces and how useful they really are but that kind of discussion is really better for the newsgroup. * New search is similar in size requirements, unclear if this change is needed Yes, currently the new search is the same size and that does make it very unclear why this change is needed. The main reason for removing the toolbar items from the default toolbar wasn't just the new search even though it was intended to be larger than the quick search. The new search is designed to have a larger width than the Quick Search because the empty text is supposed to be more descriptive and have the keyboard hint displayed (bug 500747). Also the designs planned for an auto-complete on subjects and contacts which requires more room in the entry than the Quick Search allows (bug ????). Neither of those items have been fully implemented yet so the size is still the original. A side benefit to this bugs change in toolbar buttons fixes the currently broken toolbar view at 1024px (bug 498569) because there isn't enough space to fit all the buttons. We are changing the toolbar under the assumption that the new system is better. Hopefully that assumption holds true however if it doesn't the choice is still available to keep the old buttons; it would be good to get new ideas for ways to make that choice easier. * New Search (needs better name) vs. Quick Search Right, Gloda Search doesn't really sound great either. I have no ideas on this and would love some help. * People should have the choice of new search vs. old search I can see how it feel this way. There is a choice, the old quick search is still available in the customize toolbar palette so anyone can go back to the old quick search. We are changing the default, again because we think it's going to be better and it has a wort or three now but those will hopefully go away. * Mouse travel distance to toolbar is always closer This I find unclear. I can understand that when people are accustomed to the buttons being in one area then that distance seems shorter. This is very similar to when people give directions on a route they travel often and usually assume it takes less time than it really does. While someone traveling a route for the first time would judge it taking much longer than it really does; that's human perception in the works. Lets just assume that the distance from the thread pane/message list to the toolbar or header is always about the same (equidistant). However once you move your mouse into the message preview area (to scroll or click a link) I think we can assume the header is always closer than the toolbar. So overall I think there should be less distance traveled, though this is a metric that can't stand on it's own. * Upgrading users should be able to keep the old custom toolbar buttons with one click That is a tough design challenge and I tried to come up with ways to handle this but they all seemed dubious. The best I could come up with is a revert option for those who upgraded but getting to to fit so it wasn't annoying yet still available was really difficult. At first I thought it would work much better as an extension than built-in. In case you weren't aware the "Thanks for Upgrading" page on the final version of Thunderbird is supposed to offer extensions that might make the experience better, especially for long time Thunderbird users. This page could include a "revert to my old custom toolbar" function, possibly as an extension. Lots of extensions like this already exist or are being built. For instance there is an add-on for keeping the old size columns in the folder pane https://addons.mozilla.org/en-US/thunderbird/addon/9716 * Developers are ignoring comments and not listening on discussion channels I'm sorry it appears that way to some people but I don't think this is true. There are at least 29 people listening to this bug alone and every developer watches the newsgroups so things aren't getting lost. For me personally when a bug or newsgroup thread starts to get "rants" then I'm less likely to jump in there; maybe some developers feel that way as well. I'm interested in discussion so I can learn more and improve but ranting is not a discussion the "ranter" isn't listening, just venting. I'm glad for the most part this discussion has remained calm and I appreciate everyone who tried to reign it back in. I can understand when these things get upsetting and it all looks stupid but it's unlikely that we'll get everything done and done right the first time so I appreciate everyone who bears with us.
Bryan, first of all thanks for your detailed response. To follow up on the notion that the toolbar "is not good for buttons that can only be used some of the time", a main reason for myself to dislike the header-pane buttons is that they pop in and out of the user interface depending on their applicability. Thus, nothing is there when no message is selected, all of them are displayed when a message is viewed from a normal folder, some are missing in a special folder like Archives or when you switch to multi-message view. I personally find this confusing, given that the same button shows up at different locations under different circumstances, thus one has to reestablish every time which button is actually performing which function. The more static arrangement in the toolbar allows an easy identification of the button's functionality based on its geographic location, and it is simply grayed out when not applicable. Despite a "longer way" based on mouse metrics, it is nevertheless easier and faster to reach for me since I don't have to spend time having to orient myself in which context I am and which button is which. Using icons instead of text (bug 505169) may provide an easier identification by visual cues rather than having to read text, but it still leaves the varying location and visibility issues. For comparison, I'm having similar issues with some of the context menus changing content now where they are just disabled but not removed on the branch releases (e.g., "Save All" for attachments). Since you are referring to the Firefox 3.7/4.0 mockups, I'm following with some concern what they are doing by essentially abolishing the menus on a dedicated bar and distribution functions all over the place. The multi-context buttons go into the same category of difficult orientation as described above for the button location. It also appears that the Firefox designs largely follow what Vista and Windows 7 dictate as a UX concept, along with trying to adapt the look-and-feel from Safari and Chrome. I don't think this would be a good model for Thunderbird to follow. As for the transition, it becomes apparent that for some cases a profile-upgrade UI may be required. For example, silently enabling IMAP offline copies when migrating a profile may cause an issue (bug 508276 comment #7), thus there would be a precedence for such a UI to double-check with the user if that upgrade is desired. To make a one-click solution available for the toolbar, the Start menu in Windows XP may actually provide a nice template. In its properties, you can select between the "new" or "classic" versions (the latter mimicking Win2k and before). To apply this to the case here, there could be three toolbars in total: (1) your current toolbar with all customizations; (2) the new toolbar at the same location with a different ID and the default settings proposed in your patch; (3) the toolbar in the header pane with action buttons. This would allow to show either (1) (thus hiding the action buttons in the process) to retain the classic view, or (2)+(3) for the new view with the buttons being located in the header pane. A boolean or radio item in the toolbar context menu could toggle between those two options. During transition, the respective UI could give the user a choice between "have a look at all the new features we have" and "keep the classic toolbar and all customizations I've made" to advertise the new features while giving users the "no thanks" option without too much hassle.
Bryan, thanks for your long reply. The above comment is a very nice summary of a few issues with that UI decisions. I fully agree with rsx11m. Additionally, a few other words. One of the main reasons, why Firefox was so successful, was because the customizable toolbar. People were able the first time to re-order their buttons and customize like they like it. One of the main reasons, why I'm not happy about the header-pane buttons is the size of the header. In TB 2, I'm able to have a 1 line info in the header, if I want it. When I want to see additional infos, I click on the [+]. In TB3, the header needs much more space because of these buttons. For people like me, who read most mails in the preview pane, the lost of space isn't good. It isn't really comfortable to use buttons, which are in the middle of a program. For me, it's easier and faster to reach the buttons in the toolbar too. I doubt, that the only reason for this is, that they were always there. Another problem is, that we now have buttons in 3 places. Buttons in message reader, buttons in toolbar and buttons in the tabbar too. Well, the toolbar is customizable. The message reader buttons probably will be, but the buttons in the toolbar (calendar, tasks and maybe address book) are fixed. I'm not sure in general, if buttons in 3 places are user friendly. My main idea would be to create a second toolbar for Gloda, instead of using the main toolbar. The advantage would be, that you can show this toolbar for existing users as well, without touching their customized toolbar. If an existing user decides, that he doesn't need the new search, he simply can hide the Gloda toolbar with 2 or 3 clicks. So he isn't forced to restore all of his customized buttons.
The above two comments are an eloquent summary of the UI issues and concerns, and I agree completely with them. Some additional comments/suggestions...regarding the message header, I agree that for those of use who use the 3-pane view and rarely go into the message body, having a compact one-line header is essential. I'm not sure if you've been following the development of the new "compact header" extension, but I think that's the direction things need to go. Specially, what I would love to see: * A one line compact header by default, with perhaps the additional option for a two line compact header. * Regardless, the header buttons should be icons by default, matching those in the main toolbar. * The ability to choose which icons to show/hide in the header. * The ability to choose compact or expander header based on context. For example, in the 3-pane view a compact header makes sense. However, if you open a message in its own tab, the expanded header might make more sense. Ideally, you should be able to set the default view in each context. * If possible, the ideal solution would be able to pick and choose the layout and display elements for both the compact and expanded header. It would be wonderful to be able to set a preference for a one/two line compact header with a choice of buttons and fields, and be able to do the same for the expanded header. I know some of these ideas are a bit more involved that what was planned for TB3, but hopefully you'll at least consider them or the ideas as a general direction for the future.
The re-introduction of a single-line "brief" or compact header view is probably somewhat beyond the scope of this specific bug on the toolbar buttons, nevertheless its implications have to be considered here. Apparently the need for the head-pane buttons (and thus space) in the compact view made in unattractive and thus lead to bug 480623. The relevance for this discussion is that if there is any case in which no header-pane buttons are accessible, be it because of scrolling or hiding that row in a compact view, you cannot remove them from the toolbar as those would be the only way left in those cases to initiate an action on the message. Pointer for other bugs mentioned in comment #46: Customization of header-pane button toolbar is bug 465138, icons as buttons is bug 505169. I'm not aware of any follow-up bug on the compact header.
Thanks for all the comments, I wish my turn around time was better than it is. I can understand the header buttons popping in and out being different and a bit odd. We are trying to be logical about what actions make sense when deciding what buttons to show. In the Archive folder you can't archive anything further so we don't show that button. I'm hoping this system just takes some getting used to and if at anytime buttons aren't available when they should be we need to file a bug. I'm not really sure if there's a good solution if you dislike the change in available options. Initially we tried leaving the space in for buttons that didn't make sense, like the Junk button. When a message was already Junk we just hid the button but continued to take up the buttons space. This however made things look very out of place so we started to conclude that it wasn't so much the consistent placement as it was the consistent order. I think this is much like your example of the context menu items. The change in the latest mockups of Firefox is very similar to what many other applications are doing. A current common design pattern is to move away from large menu bars with all the options to arranging options closer to the areas they affect. I think the overall concept is good and has been shown by researchers/practioners to be better for users. However it should also be noted that this new technique is significantly harder to implement correctly. Lets assume that a menu system gives a usability average, confusing half the users and working well enough for the other half. If we assume the new system comes with major usability gains we have to consider that it brings major risks. The menu system has little to no risk in implementation because its fairly standard and isn't open to styling or change. While the new system allows designers to work on an open canvas which means things could not look and work great or look and work very poorly; there is no real standard. I hope we (at least with continued iterations) can work great. I like the transition ideas! We're on the same path I just want to ask that we optimize for the new and help people revert to the old. (ask for forgiveness, not permission) Here's what I've worked on a little bit over the past couple of days. In bug 486432 we're going to make it easier to get back to the "What's New Page", which is the first thing a user coming from an older version of TB to the newer version will see. Also at this time they would see the toolbar change, tabs, new icons, and a new search. In the "What's New" page I'd like to try a couple videos that introduce the major new features (and one up the firefox people with their single video). At the same time I'd like to use that space to showcase the improvements to our extensions system. In that area we can offer some of the featured extensions that "take you back" from some of the new features that people don't want to the old features of TB2. Many of these extensions should be fairly trivial to write. For example we don't actually trash the customized toolbar data when we start TB up with the new toolbar id (what this bug does) so an extension could grab that data and revert you to your old toolbar. BAM! I want to take this path because I think we want everyone to try the new changes, even if it's just for a day. We want everyone to have the option to revert those change they disagree with. And the extensions will give us real metrics of the number of people who have reverted and for what parts. Extensions are almost a one click install solution... plus a restart. I hope that's a decent compromise. Another point I don't think I covered well enough before is the header size. We are working to solve this issue but there is an immense amount of technical debt here. The current TB headers are poorly implemented and as such it is extremely difficult to make any changes to them. One would think that just cleaning up the excess padding everywhere would be easy but it in fact takes hours and hours of time. dmose is still investigating new possible implementations of the header such that we could move to a grid view where space is used efficiently. I'm hoping to have the current header down to about 3 to 4 vertical lines where I believe right now it takes about 6. There's nothing about this change that is willful or part of the design, it really is a matter of crap code and I'm just as upset as anyone. Either we'll be able to fix this unstable foundation and get something satisfactory or we will continue to play this game of Jenga (tm) that we do now. I'm not sure what kind of user experience would be possible by implementing Gloda as a second toolbar. I don't think I've heard that idea before so I'd have to ask some developers what it would be like. If you wanted to try it out and do some screenshots reporting on a new bug or in the newsgroup I'd be interested. I like all the compact header ideas and I'm actually really excited to see if there are improvements built into the extension. A likely path I see next is if we can remove the technical debt of the current header by reimplementing using good coding style and proper testing practices. From that point we could look at pulling in a compact header style that I would hope has evolved separately to become better than just the old TB2 style. But now I feel like it's time to take this somewhere else. I think we've discussed most of the general areas regarding this change and in order to go deeper into any one particular discussion we need to change to a newsgroup or a specific bug about that change. This is not a push off to ignore comments but we're starting to branch off into lots of different topics and bugzilla just isn't meant for that kind of discussion; we need to stay on topic of the bug. Feel free to post something in m.d.a.t and I'll try to check it more often so we can continue. Thanks for all the great feedback.
Whiteboard: [waiting on blockers] → [waiting on blockers][no l10n impact]
(In reply to comment #45 and the respective response in comment #48) > My main idea would be to create a second toolbar for Gloda, instead of using > the main toolbar. The advantage would be, that you can show this toolbar for > existing users as well, without touching their customized toolbar. This is in essence how SeaMonkey implements it. Underneath the main toolbar with the button icons an optional second toolbar can be shown with drop-down menus and the search bar. Have a look at the 2nd and 3rd screen shots shown in the (otherwise unrelated) bug 509701 attachment 393764 [details]. (In reply to comment #44) > be three toolbars in total: (1) your current toolbar with all customizations; > (2) the new toolbar at the same location with a different ID and the default > settings proposed in your patch; (3) the toolbar in the header pane with action > buttons. This would allow to show either (1) (thus hiding the action buttons in > the process) to retain the classic view, or (2)+(3) for the new view with the > buttons being located in the header pane. I've added this to bug 465138 comment #15 on header-pane customization. Those go hand-in-hand with the existence of the two old+new toolbar definitions introduced by the bug here. (In reply to comment #48) > Many of these extensions should be fairly trivial to write. For example we > don't actually trash the customized toolbar data when we start TB up with the > new toolbar id (what this bug does) so an extension could grab that data and > revert you to your old toolbar. I fail to understand the need for an extension here, why put this additional burden on the user to switch between views? It's just a toggle in a menu, something like View > Toolbars > Classic/New, which can default to New.
Whiteboard: [waiting on blockers][no l10n impact] → [no l10n impact][waiting on blockers]
Attachment #364981 - Flags: review?(bugzilla)
here's the updated patch with the ID change
Attachment #399686 - Flags: review?(bugzilla)
Attachment #364981 - Flags: review?(bugzilla)
Comment on attachment 364981 [details] [diff] [review] removes buttons from the default toolbar set on both mac and others canceling this one
Attachment #399686 - Flags: review?(bugzilla) → review+
Checked in: http://hg.mozilla.org/comm-central/rev/7ff1aded821c
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [no l10n impact][waiting on blockers] → [no l10n impact]
Bryan, is there a bug pending for any TB2/TB3 migration UI you mentioned? As a workaround, I've just hacked localstore.rdf and changed all mail-bar2 entries to mail-bar3, which worked quite well.
(In reply to comment #53) > Bryan, is there a bug pending for any TB2/TB3 migration UI you mentioned? Thanks for the reminder! There isn't one yet. Can you file that and cc me so we can get that on the radar during the rc1 time frame. > As a workaround, I've just hacked localstore.rdf and changed all mail-bar2 > entries to mail-bar3, which worked quite well. That sounds promising!
Blocks: 515715
> (In reply to comment #54) Can you file that and cc me so > we can get that on the radar during the rc1 time frame. Done, that's bug 515715 for the migration/transition UI.
There seem to be some huge regressions caused by the "fix" for this bug: - The images on the toolbar icons (yes, I immediately re-instated them) don't match their function. The Delete icon now has a flame image (Junk), the Compact Folder icon has no image, Tag Message is a blue back arrow, Mark Messages is now a Tag icon. - After getting a Search Everywhere result and clicking on one of the filters and also after entering the "Show all as List", it should be possible to go "back" to the unfiltered results. - The Search Everywhere bar is much too wide. It would be perfectly fine at half the width. You could also make the width adjustable, like the Search bar in Firefox. This would also make the misguided displacement of the toolbar buttons unnecessary. Nobody needs to do a search very often (despite the "search-is-god" hype) and nobody will do complex searches more than once in a blue moon. It's definitely not worth the cost of diminishing (I want to say "crippling") the UI that is used every day. And fiddling with the header UI will only make it less-worse, not better.
A good chunk of patches was checked in last night, along with the one here: - icon mixup on Windows XP is independent bug 515624 and resolved by now; - the search-bar width changes depending on other toolbar items present, but cannot be explicitly specified (that's handled in bug 515648).
(In reply to comment #56) > There seem to be some huge regressions caused by the "fix" for this bug: Peter, as always please file regressions in separate bugs after having searched for ones filed. Comments on fixed bugs will most likely to get lost. Hint: for most search faceting regressions we're prefixing them with [faceted search] until we get a bugzilla component created. > - The images on the toolbar icons (yes, I immediately re-instated them) don't > match their function. The Delete icon now has a flame image (Junk), the Compact > Folder icon has no image, Tag Message is a blue back arrow, Mark Messages is > now a Tag icon. This is because I missed submitting one of the patches for bug 506011 - that has now been resolved for tomorrow's nightly. > - After getting a Search Everywhere result and clicking on one of the filters > and also after entering the "Show all as List", it should be possible to go > "back" to the unfiltered results. Already filed as bug 515742. > - The Search Everywhere bar is much too wide. It would be perfectly fine at > half the width. You could also make the width adjustable, like the Search bar > in Firefox. This would also make the misguided displacement of the toolbar > buttons unnecessary. I think Bryan has already explained most of the reasons and I think it is safe to say that we differ in opinions here. The search bar size is bug 515648.
(In reply to comment #58) > (In reply to comment #56) > > - The Search Everywhere bar is much too wide. > The search bar size is bug 515648. That's for making it adjustable. Additionally, the *default* size should be much smaller. PS. Glad to see the other issues are already on-the-radar or fixed.
Blocks: 516610
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: