This is the bug for tracking the changes to the Thunderbird Mail Toolbar. In a nutshell we'll be moving most of the buttons off the toolbar as the functionality for those buttons gets pushed into more direct inline actions. The quick search entry becomes a larger search entry with auto-complete on people, emails, message subjects, events, and tasks. ( see http://www.visophyte.org/blog/2008/08/19/thunderbird-full-text-search-prototype-a-la-sqlite-fts3/ and http://www.visophyte.org/blog/2008/08/19/thunderbird-contact-auto-completion-with-bubbles/ for prototype examples ) With the changes being built into bug 449691 ( improved message reader ) the following buttons should move from the toolbar into the message reader itself. (reply), (reply all), (forward), (tag), (delete), (junk), (print). Key combos and right click popups are still available in many other areas of the interface for these concepts. With the changes being built into bug 446306 ( mailbox centric folder pane ) the addressbook button should move from the toolbar into the Folder Pane. The Write button should become larger, stylized and lose it's icon. With the changes being built into bug 281417 ( get mail gets all mail ) the get mail button will become slightly larger, slightly stylized, and be only an icon. The goal of this change is to develop a more iconic looking toolbar that is also very functional. The overall height is decreased, which increases vertical space for mail reading. The emphasis on search is increased as our ability to search mail has become much better and we want to encourage people to use the search. The removal of all the mail action buttons that change sensitivity depending on where focus is directed means that when action buttons are visible they are usable; a concept that is much easier for many users to understand.

Definitely looking forward to a less height tooolbar! I can't tell from the mockups but i assume one will still be able to limit in on some specific criteria. Often with mail one do know which fields to search (if it's From, To, or the subject is something special.

(In reply to comment #1) > I can't tell from the mockups but i assume one will still be able to limit in > on some specific criteria. Often with mail one do know which fields to search > (if it's From, To, or the subject is something special. Yes, we're actually going to make this (hopefully) easier. We should be able to auto-complete on the from:, to:, subject:, and other syntax elements. This would allow you to type "fr<tab> clark<tab>" and it completes to: from:clarkbw@email.com; providing a search result list of messages from that sender.

That could work for one-header matches, though combinations like "to or cc" would be awkward to enter. But how do you make that discoverable?

Just to note, it's important to look at this from the POV of: Discoverable for those who want to learn. There are a set of users, like the old "my grandmother", who are not going to learn how to type to: and cc: to get that kind of granularity immediately. Those users will have to use a combination of typing and mouse or maybe all mouse selection. However there are another set of users who will learn that format assuming we show them what the format is. Initially when the search bar auto-completes on a person it performs a match for "conversations" including that persons "identity"; where conversations means to, cc, bcc, and from and identity means all emails associated with the person. Once a person (hits enter) searches for the conversation identity match the search results will be opened up in a new tab inside thunderbird. The search results tab will use the top area for search/browse facets that will build the search bar. Essentially every facet that a user chooses will be inserted into the search entry in the correct format. So for the example above if you only wanted to: or cc: you could click on the facets area choosing only those types of options and the search entry area would convert itself to display the correct search string; likely from the form {Identity Match} to the form "(to: {Identity Match} or cc: {Identity Match})". Additional changes could be made to only match a single email of the Identity and then the search entry area would change again to correspond. For the set of users who won't learn the search format they can continue to use the search facets to build searches by clicking. The users who notice the search bar format changes and learn the format will be able to type that format directly into the search bar with help from the auto-complete.

While I think it's great to have a powerful search feature, I think that ultimately this new design seems to waste a lot of screen space. First, most people I know rarely have to do global searches in Thunderbird. This might be useful for people who want Thunderbird to be like Gmail and put all of their information into a single mailbox called "Inbox" instead of organizing it into folders, but still, does the search box have to be so big and prominent? For example, even for people that use a relatively small screen size of 1024 x 768, you're talking about using maybe 200 pixels for the GetMail and Write buttons, but 800+ pixels of screen width for the search text field. With my 1920 x 1200 display, will the textfield use almost the entire width of my screen, and this 1700+ pixels will be highly visible yet maybe only used once per month. In other words, an eyesore. Vertically there will also be wasted space if the single toolbar in TB 2 will be replaced with two toolbars. The only button on the main toolbar that most people I know will use every day is the Write button, whereas the preview pane would become cluttered with the Reply, Reply All, Print, etc buttons instead of containing only the text of the message that we want to read. I personally think that Thunderbird 2's toolbar is great and all you have to do is make the search textfield more prominent, perhaps by putting it at the top of the folder pane where it won't be so wide and loud.

(In reply to comment #0) > The Write button should become larger, stylized and lose it's icon. Not sure if an iconless button will look right right next to the menubar? Something like ( [↓] Get mail v ) ( _✎_ Write ) [ ... ] comes to mind that fulfills at least some of the goals... but I guess there'll be another time for those details ;) (In reply to comment #1) > on some specific criteria. Often with mail one do know which fields to search > (if it's From, To, or the subject is something special. I suspect unless search perf varies greatly depending on it, narrowing to specific headers with any ui probably just takes more time to get to results. Full body text might be another story... (In reply to comment #3) > That could work for one-header matches, though combinations like "to or cc" > would be awkward to enter. But how do you make that discoverable? Parity hint: gmail search doesn't differentiate between to and cc; to:foopydoo matches a message that is only cc:foopydoo. When reading a message the distinction is sometimes intended as a hint, but I doubt it's too useful in search. (In reply to comment #5) > First, most people I know rarely have to do global searches in Thunderbird. I hear the intent is to prioritize the search to look in the selected folder first. > With my 1920 x 1200 display, will the textfield use almost the entire width of In 1920px width the tbird2 default toolbar is mostly empty space; in this design it's mostly empty search bar so the effect is rather the same. I suppose the toolbar will remain customizable, anyhow. > is make the search textfield more prominent, perhaps by putting it at the top > of the folder pane where it won't be so wide and loud. There's definitely not enough room for it on my folder pane, a frugal 130px :) The search being prominent and having the room to explain itself somewhat more verbosely by default is a good idea I think; I've seen users of the less ui-literate kind waste over a minute scrolling around looking for something that tbird2 quicksearch would have narrowed into view in seconds, probably because "Subject or From" and the magnifier didn't quite advertise its usefulness enough.

(In reply to comment #6) > I suppose the toolbar will remain customizable, anyhow. I would guess that most people (including me) would be completely happy if the main toolbar remains fully customizable, but my fear is that this bug proposes to remove that ability and everyone would be forced to have only GetMail, Write, and Search on it, always, with no possibility to customize it with all of the normal buttons such as Delete and Reply. Even if we only click on the GetMail and Search fields once per month. In addition, I hope that this proposal will consider extensions, many of which add buttons to the main toolbar that are essential for the use of the extensions. > In 1920px width the tbird2 default toolbar is mostly empty space; in this > design it's mostly empty search bar so the effect is rather the same. Well, that's not true for me. :) I have buttons from the left to the right sides of the screen. I use icons+text and that uses most of the horizontal space, unlike what a search box needs.

(In reply to comment #7) > (In reply to comment #6) > > I suppose the toolbar will remain customizable, anyhow. > > I would guess that most people (including me) would be completely happy if the > main toolbar remains fully customizable, but my fear is that this bug proposes > to remove that ability and everyone would be forced to have only GetMail, > Write, and Search on it, always, with no possibility to customize it with all > of the normal buttons such as Delete and Reply. Even if we only click on the > GetMail and Search fields once per month. This bug has no mention related to removing customize-ability of the toolbar because that's definitely a non-goal. It would be more pig-headed of me than usual to assume a single toolbar configuration would work for everyone :) > In addition, I hope that this proposal will consider extensions, many of which > add buttons to the main toolbar that are essential for the use of the > extensions. I believe this ties into the development of the toolbar itself, in it's current implementation form it simply removes the default set of buttons to a minimal and changes the download button, write button and search entry. I don't think that is off track from any other previous toolbar changes, but I may be wrong about that.

I think we should try hard to get this in by b2

There is a prototype of this toolbar available, however it has a couple requirements that can make it difficult to put together. The toolbar prototype is here as an extension to Thunderbird http://hg.mozilla.org/users/bugmail_asutherland.org/exptoolbar/ The extension requires gloda to be installed, gloda is also available here as a Thunderbird extension ( until gloda is in the core - bug 450494 ) http://hg.mozilla.org/users/bugmail_asutherland.org/gloda/ And bug 402365 has a patch in attachment 341994 [details] [diff] [review] which enables the new (required) tab support in Thunderbird.

clearing up title, adding alias and flagging correctly

Landing this in the tree won't block beta 1; moving this bug out.

I don't think this will make b2, but it'd be good to start a patch for at least parts of this.

I think you already know and just confirmation: Current exptoolbar don't support multibyte char for search and even when we search with ascii only word, body text of messages in the search result pages will be garbage chars. Search centric toolbar must support multibyte char.

(In reply to comment #14) > I think you already know and just confirmation: > Current exptoolbar don't support multibyte char for search and even when we > search with ascii only word, body text of messages in the search result pages > will be garbage chars. > > Search centric toolbar must support multibyte char. Possibly-related: I searched for a unicode char (真 to be exact) and I indeed had a email containing that char in my email inbox. No results show up in exptoolbar, though there is a search result in the normal search box.

(In reply to comment #15) > No results show up in exptoolbar, though there is a search result in the normal search box. No results show up in exptoolbar _search_, though there is a search result from using the normal search box functionality.

why does the exptoolbar do so much? It seems that it searches more through contacts then through messages (if i type just a string i want to search trough everything of that string not select a contact) i hope we get a really google like search bar, this one tries to do much. Let me decide with what i type where it should search in. See bug 63573

Since we're probably too close to the final release date to make the exptoolbar extension, as itself, land in the tree we're going to take some elements and land them in the current toolbar. Specifically the search results and conversation viewer, while excellent, still need a lot of work before they could land. I'm breaking down the search component into a couple different bugs such that we have an improved search experience from the current quick search, but will be missing the improved search results. * new search entry in default mail toolbar - bug 474701 * search facets bar above search results tab - bug 474711

clarkbw: given that the bugs you've spun off already block Thunderbird 3, as far as I can tell, this bug no longer does; setting blocking-thunderbird3-.

(In reply to comment #14) > Search centric toolbar must support multibyte char. I checked db with SQLite Manager Addon and body/attachmentNames field of messagesText/messagesText_content table of global-messages-db.sqlite seems to contain mojibake (garbage chars). So, I think not exptoolbar but gloda backend (caller of insertMessage) don't support multi-byte chars so far. I filed separate bug 479214 for this problem.

When I tested with fixed Gloda JS mime emitter (bug 479214) and experimental custom tokenizer for sqlite fts3 (bug 472764), we can use Japanese etc correctly from Exptoolbar. That is, as I expected in the last comment #20, Exptoolbar frontend supports multibyte chars correctly.

merging this into the new search toolbar as that's where development is happening. I'm sorry that there isn't a place to file bugs against the exptoolbar code.