Re-evaluating putting the Buttons in the Headers, and other Header-related stuff
Peter Lairo
There are two general issues I would like to point out; and invite others to provide feedback.
Generally, I think that:
- Putting the Reply, Forward, Delete, etc.
buttons into the message header is a mistake.
- Combining the reply-to-sender and
reply-to-many buttons into one button is also a mistake.
Why Putting the Reply, Forward, Delete, etc.
buttons into the message header is a mistake:
- The header is already crowded.
- There is enough space in the toolbar (even with the new gloda search bar).
- The icons in the header are now, out of necessity, smaller (too small).
- The buttons are now in non-standard locations.
- The buttons are now scattered throughout the
UI.
- Buttons in the header eliminate the visual clue that they can apply to multiple messages (e.g., delete several selected messages).
- What is going to happen with the header buttons once the header can scroll? (bug 464309, "Message headers don't scroll with the message", https://bugzilla.mozilla.org/show_bug.cgi?id=464309)
- Putting the buttons into the header and fixing
all the ongoing issues is taking up a huge amount of developer time.
That's time away from far more important issues (e.g., bug 250539, bug
401779, bug 310158)
- Make the tool-bar's button context-sensitive. If another app tab is visible, then swap the toolbar for that app's toolbar. Buttons that are relevant to both apps (e.g., e-mail and calendar), then show those buttons on both tool-bars.
Why the Reply-to-sender and Reply-to-many
buttons should be separate buttons:
Why we should keep the buttons separate:
- The buttons are already smaller than the toolbar buttons (i.e., harder to aim at targets).
- The Reply-to-sender and Reply-to-many icons,
especially at this tiny size, look almost indistinguishable from each
other.
- Most users (e.g., my parents) do not understand the concept of a drop-down menu as a sliver along the side of a button. Let's also remember that targeting that sliver is extremely difficult, even more so for elderly, very young, and handicapped users. So we are essentially preventing those (and many other) users from selecting between reply-to-sender and reply-all, no matter what default is chosen. We are at minimum creating a huge obstacle.
- There is enough horizontal space on the
"From"-line of the header for this important button, especially for the
icon-only version, which should be the default and, if not the default,
many will quickly switch to.
[Reply-to-sender] [Reply-to-many \/] [Forward] [Delete]
That way, the first button (left-most) is always Reply, the special-case buttons noticeably appear at the location of the Reply button, and the other (non-reply) buttons are always physically in the same location (on right and right-aligned). To increase consistency even further, when there are not many recipients, then the "Reply-to-many" button could be grayed-out (instead of removing it) for those messages. That way, all buttons are consistently located and easily found using basic human memory.
Please see bug 516141 to fix this. ("Separate buttons for Reply and Reply-All/Reply-to-List (depending on context) in message header", https://bugzilla.mozilla.org/show_bug.cgi?id=516141)
Best default if we must combine:
If we must have only one reply button, then having
Reply-to-sender as the default is clearly the lesser of two evils
because it reduces the chance of accidentally replying to many people
when this could be embarrassing or even damaging.Having the option of separate/combined buttons:
Bug 511924 created the option of having separate Reply-to-sender and Reply-to-many buttons. That's good. But unfortunately, the default is still the combined button.Also, having drop-downs on both buttons is just horrible UI (it reminds me of the uncle of all bad UI: Lotus Notes). At minimum, the logic should detect when there are two buttons, and then remove the drop-down from the reply-to-sender button.
Other remaining issues with the header buttons:
- The reply-to-all icon is nearly indistinguishable from the reply-to-sender icon, especially at that too-small-size.
- The reply-all button disappears when there is only one recipient. This makes the reply button's location vary, which is bad. It would be better if the reply-all button just became disabled (gray). This is made even worse by #1.
- Selecting multiple messages: The buttons are always icons+text and don't respect the user-chosen setting (e.g., icons only).
- The Archive and Junk buttons are taller than the others in icon+text mode (WindowsXP). (in the unlikely case that hasn't been mentioned/noticed yet)
- The "Other Actions" menu opens "up" although there is plenty of space below the button.
- It's not possible to mark multiple selected messages as junk (the button disappears for multi-selections).
- There are no tool-tips for the buttons when multiple messages are selected.
- The tool-tip for the delete button doesn't say "undelete" for mark-as-deleted messages.
- The Tag button should also be put into the
header.
Need ability to disable the header toolbars completely:
We need the option to not show any buttons in the header. e.g.,:View / Headers / All
Normal
--------------
x Show buttons
Alternative:
View / Toolbars / Header Toolbar
Of course, the other remaining header elements should then be able to use the vacated space (e.g., longer Subject line).
Conclusion:
The best solution is:- Remove the buttons from the header and leave them on the Mail Toolbar.
- Make the Mail toolbar dynamically adapt to the
active tab (Messages, Calendar,...).
- Make it possible to
disable the header toolbars completely.
- Do everything possible to make the header buttons as usable as possible for non-expert users.
-- Regards, Peter Lairo The browser you can trust: www.Firefox.com Reclaim Your Inbox: www.GetThunderbird.com Islam: http://www.jihadwatch.org/islam101/ Israel: http://www.jewishvirtuallibrary.org/jsource/myths2/ Church of the Flying Spaghetti Monster: http://www.venganza.org/ Anthropogenic Global Warming skepsis: http://tinyurl.com/AGW-Skepsis
Peter Lairo
If part of the motivation to displace the buttons into the header was to have space on the toolbar for other "apps" (like Lightning), then do it the way WordPerfect does:
- Make the tool-bar's button context-sensitive. If another app tab is visible, then swap the toolbar for that app's toolbar. Buttons that are relevant to both apps (e.g., e-mail and calendar), then show those buttons on both tool-bars.
Other remaining issues with the header buttons:
- (#6) It's not possible to mark multiple selected messages as junk (the button disappears for multi-selections).
- (#6) It's not possible to mark multiple selected messages as junk or assign Tags or to "Mark" them (The buttons disappear for multi-selections. The "Mark" button isn't even in the header at all).
Dan Mosedale
> Generally, I think that:
>
> 1. Putting the Reply, Forward, Delete, etc. buttons into the message
> header is a mistake.
We understand: you've stated your opinion and advocated for it many ways
in many different places. We've heard you.
That said, this decision has been made. Perhaps we will decide to
revisit it at some point in the future, perhaps not.
We can't and won't spend time discussing it to death now, as we need to
focus on getting 3.0RC1 out the door.
Dan
Peter Lairo
I have previously identified the individual issues in scattered and
often obscure places. This thread was an attempt to start a focused
discussion on a serious issue affecting the primary UI.
This issue has never really been discussed at all, let alone "to death"
(which I consider a defamatory attempt at a misrepresentation of my
intentions). In fact, no one has even addressed most of the issues I've
raised at all, nor explained how putting buttons in the header is more
important than the numerous disadvantages that I've identified. I've
always had the suspicion, from day-one[1], that this was a forgone
conclusion, and that no amount of facts would deter it. You have just
proven my suspicions to be correct.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=480623#c47
Robert Kaiser
> Generally, I think that:
>
> header is a mistake.
> 2. Combining the reply-to-sender and reply-to-many buttons into one
> button is also a mistake.
Not sure if they are mistakes overall, but you don't like those steps,
granted.
You could consider using SeaMonkey 2.0, which doesn't do either of those
things.
Not everyone needs to be happy with the same product - that's the reason
why there's different ones on the market.
Robert Kaiser
Dan Mosedale
> This issue has never really been discussed at all, let alone "to
> death" (which I consider a defamatory attempt at a misrepresentation
> of my intentions).
including you, don't like the message header changes. There has been an
enormous amount of discussion in various places about this. While it
hasn't been discussed from _precisely_ this angle, the point I'm trying
to make is that the higher level decision is made for Thunderbird 3.
We're basically comfortable with where it's at, and we need to spend our
time on other parts of the product, not on continuing to discuss this one.
> In fact, no one has even addressed most of the issues I've raised at
> all, nor explained how putting buttons in the header is more important
> than the numerous disadvantages that I've identified.
contributor's satisfaction, the reality is that far more input is
provided than we can practically respond to. Practically speaking, all
we can do is read all the input, try and engage in constructive
discussion where things seem unclear, and make what we believe are the
best decisions possible at a given time.
> I've always had the suspicion, from day-one[1], that this was a
> forgone conclusion, and that no amount of facts would deter it. You
> have just proven my suspicions to be correct.
those use cases, for which I apologize. I had hoped to have it done by
now, but other work got in the way. The reality is that we're too late
in the Thunderbird 3 cycle to expect big changes here.
Dan
Rimas Kudelis
Actually, if you skip part 1 of Peter's post, and at least read
everything starting with "Why the Reply-to-sender and Reply-to-many
buttons should be separate buttons", there's a lot of criticism that
makes sense.
I personally tried to switch to the new toolbar layout, but couldn't
live with it for even 10 minutes, because in its current state, it's
just incomplete and doesn't make much sense:
1) I couldn't mark more than one message as spam at once. Isn't that a
huge feature loss?
2) I've got quite a big screen. Why should I really aim for that small
triangle between the Reply and Forward buttons? I think it would be much
better if that button could just ungroup automatically, when there's
enough space in the header bar.
2a) By the way, shouldn't that arrow be part of a button, similarly to
"Get mail" in toolbar?
3) Also, it would be nice if the layout of header bar buttons would be
cusomizable (so that I could remove unused buttons to make more space to
those that I use).
3) I'm not a big tag user, but the fact that the Tag button is
unavailable in header adds to this feeling of incompleteness.
Maybe there was also something else that I don't remember now... All in
all, while I'm eagerly waiting for 3.0, I'm already looking forward to
3.next - I hope it will be a release much more mature than 3.0 will be...
RQ
Marcel Kneuer
is thunderbird 5 or 6 or better "yetanothermailprogramm 1.0" based on
thunderbird 2.
For "yetanothermailprogramm 1.0" all the interface changes are good. But
for people who lived with tb2 for years (!!) they are very bad and
unusally. In my office I have some people testing beta versions. And
with every beta version, in the special v4, they are more frustrated. I
can change everything back (smart folders, missing buttons,...) for all
my users but what is with million users outside without support?
No we can't change it back, but we'll have a lot of updaters hating us
and tb3.
Marcel
On 01.10.09 23:07, Dan Mosedale wrote:
> On 10/1/09 12:37 PM, Peter Lairo wrote:
>> This issue has never really been discussed at all, let alone "to
>> death" (which I consider a defamatory attempt at a misrepresentation
>> of my intentions).
> This is yet another angle on a theme: a set of extremely vocal people,
> including you, don't like the message header changes. There has been an
> enormous amount of discussion in various places about this. While it
> hasn't been discussed from _precisely_ this angle, the point I'm trying
> to make is that the higher level decision is made for Thunderbird 3.
> We're basically comfortable with where it's at, and we need to spend our
> time on other parts of the product, not on continuing to discuss this one.
>> In fact, no one has even addressed most of the issues I've raised at
>> all, nor explained how putting buttons in the header is more important
>> than the numerous disadvantages that I've identified.
> While it would be great if we could address every issue to every
> contributor's satisfaction, the reality is that far more input is
> provided than we can practically respond to. Practically speaking, all
> we can do is read all the input, try and engage in constructive
> discussion where things seem unclear, and make what we believe are the
> best decisions possible at a given time.
>> I've always had the suspicion, from day-one[1], that this was a
>> forgone conclusion, and that no amount of facts would deter it. You
>> have just proven my suspicions to be correct.
> I'm sorry you feel this way. I haven't yet had a chance to get back to
> those use cases, for which I apologize. I had hoped to have it done by
> now, but other work got in the way. The reality is that we're too late
> in the Thunderbird 3 cycle to expect big changes here.
>
> Dan
>
>
> _______________________________________________
> dev-apps-thunderbird mailing list
> dev-apps-t...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
JoeS
> 3) Also, it would be nice if the layout of header bar buttons would be
> cusomizable (so that I could remove unused buttons to make more space to
> those that I use).
https://bugzilla.mozilla.org/show_bug.cgi?id=519956
--
JoeS Using TB3
http://kb.mozillazine.org/Thunderbird_3.0_-_New_Features_and_Changes
https://developer.mozilla.org/en/Thunderbird/Thunderbird_Binaries
Wayne Mery
These are good usability points. They are fixable by you, or ...
unmentioned so far is a nice new migration assistant developing (and
promised in a previous post iirc) which helps address these and other
areas. nightly builds. Help>Migration Assistant.
For items that aren't yet addressed or don't have a bug, please make
sure a discrete bug is filed.
Eddy Nigg
Well, I wasn't aware of discussions addressing those issues and it
wasn't important enough for me to "complain", but I must say that I
agree with most what Peter suggested. I never use those buttons in the
content area - it was nice to see them when they appeared initially
(like, yeah something new in TB), but besides that, they make this area
extremely cluttered. I think you guys should over-think some of what's
being said here.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Bryan Clark
> Why Putting the Reply, Forward, Delete, etc. buttons into the
> message header is a mistake:
>
This doesn't give many options. I could offer that if you turned off
the buttons you don't gain any room in the header. The buttons use
space that doesn't get used otherwise by the from header.
One could easily say the toolbar from Thunderbird 2 is crowded. At
1024px wide the toolbar in TB2 pushes the quick search off the screen.
At 800px width you miss a number of buttons as well. With the current
TB3 toolbar and header layout all buttons and search are visible at both
800px and 1024px with the same options available (excluding prev/next
which could reasonable be added to fit in the toolbar).
> * There is enough space in the toolbar (even with the new gloda
> search bar).
If you add back Reply, Reply All, Reply List, Forward, Archive, Junk,
and Delete the toolbar becomes crowded. Those 7 items fill the toolbar
such that at smaller screen sizes it becomes unreasonable again, this is
ignoring the prev / next buttons.
> * The icons in the header are now, out of necessity, smaller (too
> small).
The icons are 16x16, the same size as the small icons used in the toolbar.
> * The buttons are now in non-standard locations.
I'm not really sure what you mean by non-standard here, different from
some other clients yes. However none of the other clients directly
follow each other with a specific standard. Email clients tend to use
the top toolbar for somethings and the header area for other things;
spreading the functionality around.
Here's some analysis of clients from memory and quick checks. If we
were to consider web mail we would have to look at yahoo and msn / live
mail as top providers.
* MSN Live Mail - Delete and Junk are always present while Reply and
Forward buttons appear / disappear when looking at the list or message
itself.
* Yahoo Mail - Repy, Forward, Delete, Junk, etc are only shown if there
are messages in the folder; otherwise hidden. If no messages are
selected these buttons show a pop up with text to the effect of "You
must select a message first and then click reply"
If we only look at clients of reasonable market share and forward
momentum we're looking at Outlook and Mail.app as top applications.
* Outlook - Delete (icon only), Reply, etc. are in the toolbar and
disabled / enabled depending on what is selected. Going by memory I
believe these are 16x16 icons for their buttons.
* Mail.app - Delete, Junk, Reply, Reply All, Forward shown in the
toolbar; all of which are enabled / disabled depending on what is
selected. NOTE: that Mail.app uses 18x12 icons for their toolbar which
is of smaller height than our small toolbar icons.
In terms of market share, where email users are, all the client
applications combined are barely a blip on the chart compared to Yahoo
and MSN. We could try argue that the client applications have the
"correct" interface and the others, with many many more users, are wrong
but I think that's a difficult argument to make.
Each of these interfaces is different and so users have to adapt when
switching to any of them. Thunderbird should continue to do what we
believe is correct and not copy other systems blindly.
To cushion users who are migrated from interfaces where we want to steal
users I think it makes a lot of sense to have an add-on that makes
Thunderbird look (and behave) more like that system. Outlook users
would appreciate a more outlook layout as would Mail.app users but those
changes are likely best for add-ons as they can't happen at the same
time and aren't needed by everyone.
> * The buttons are now scattered throughout the UI.
This isn't clear to me. Scattered would actually mean they are all over
different places when they are actually in one place; the header. If
anything the buttons related to email message operations have condensed
into a single location.
> * Buttons in the header eliminate the visual clue that they can
> apply to multiple messages (e.g., delete several selected messages).
The multiple message summary handles this with a delete and archive
button. I'm not sure why we don't have a junk button there, I thought
there was a bug filed about this but apparently not. We should be able
to fit this in for release.
> * What is going to happen with the header buttons once the header
> can scroll? (bug 464309, "Message headers don't scroll with the
> message", https://bugzilla.mozilla.org/show_bug.cgi?id=464309)
The multi-message summary handles this situation right now fairly well
and I think we can cross this bridge when we get to it.
> * Putting the buttons into the header and fixing all the ongoing
> issues is taking up a huge amount of developer time. That's time
> away from far more important issues (e.g., bug 250539, bug 401779,
> bug 310158)
There are always other issues that haven't received priority and some
changes take more developer time than other changes but someone is
always upset with every change; always. (see subject wrapping as an
example)
> If part of the motivation to displace the buttons into the header was to
> have space on the toolbar for other "apps" (like Lightning), then do it
> the way WordPerfect does:
>
> * Make the tool-bar's button context-sensitive. If another app tab
> is visible, then swap the toolbar for that app's toolbar. Buttons
> that are relevant to both apps (e.g., e-mail and calendar), then
> show those buttons on both tool-bars.
As more and more new applications are designed you'll see less and less
of this design pattern. If having the reply buttons in the toolbar has
any advantage it is that they are always in the same place. When you
start swapping them out for other buttons depending on what kind of tab
or inner application is being viewed you lose that advantage. That type
of application design pattern is being left in the stone age of computer
applications.
The advantage of the header buttons over the toolbar buttons is that
they are always in the same location (coordinate space like the toolbar)
but are only shown when they can be used. Toolbar buttons either have
to be constantly enabled or disabled depending on if they can be used
with the current selection.
To create a "smart reply" button in the toolbar would mean you would not
only have a button that enables and disables depending on selection but
it would also change text from Reply All to Reply List depending on what
is selected. This causes either visual jumping / moving of the
surrounding buttons or allocating the maximum amount of space needed for
a button that might never be used; i.e. users who don't use mailing
lists get a mailing list sized button for reply all.
> Why we should keep the buttons separate:
>
> * The buttons are already smaller than the toolbar buttons (i.e.,
> harder to aim at targets).
But inline with what other applications are using for buttons. When
examining other email applications and web clients they are all using
about 16px height buttons.
> * The Reply-to-sender and Reply-to-many icons, especially at this
> tiny size, look almost indistinguishable from each other.
This is a bug and is being worked on. I'm confident that we can have
clearer reply, reply all, and reply list buttons.
> * Most users (e.g., my parents) do not understand the concept of a
> drop-down menu as a sliver along the side of a button. Let's also
> remember that targeting that sliver is extremely difficult, even
> more so for elderly, very young, and handicapped users. So we are
> essentially preventing those (and many other) users from selecting
> between reply-to-sender and reply-all, no matter what default is
> chosen. We are at minimum creating a huge obstacle.
The buttons do need better indicators of the drop down. I believe with
the latest change to toolbar buttons we should be able to get a much
better visual indication of a drop down target (at least for Windows and
Linux) Essentially this is a bug and should be fixed for the TB3
release; I don't remember the bug number off hand.
If we assume that we can fix the drop down button such that it is a
larger target then we are not preventing old people, children, and the
disabled from choosing other reply options.
The issue of users who do not understand a menu-button is a long
standing one with the design of the button itself. We use menu-buttons
in a number of places in the Thunderbird interface so this is concerning
in general.
This is a situation where I don't see the answer as being a single back
to two button solution as you do.
In many a usability study I've seen, users who didn't understand email
and used it mostly for family / personal reasons would choose the wrong
reply often, being reply sender. And because they didn't understand
what happened they would never know that they didn't participate in a
discussion but only sent a reply back to the last person who sent a
message. In these cases the unintended "sender only" wasn't aware the
message didn't go group-wide either and as such conversations splintered
and people blamed emails getting lost. These are a class of users who
won't figure out how to change the default.
Essentially when faced with an email header most of the users didn't
really understand the choice of reply or reply all. Reply sounds like
the correct choice but in a group discussion but it's actually reply all
which is correct but "more accurate"; an idea that only really rings
with engineer types.
For that and many other reasons I believe that we need to have the Reply
/ Reply All toggle in the composition window. I feel like I'm beating a
dead horse at this point but I've spent so much time working on other
things that we haven't gotten to this _actually very_ important element.
> * There is enough horizontal space on the "From"-line of the header
> for this important button, especially for the icon-only version,
> which should be the default and, if not the default, many will
> quickly switch to.
I think there is a lot more to do if we want to make something like this
the default. Thomas had a number of good suggestions I think are worth
looking into and are likely better than an extra button for reasons
mentioned.
> That way, the first button (left-most) is always Reply, the special-case
> buttons noticeably appear at the location of the Reply button, and the
> other (non-reply) buttons are always physically in the same location (on
> right and right-aligned). To increase consistency even further, when
> there are not many recipients, then the "Reply-to-many" button could be
> grayed-out (instead of removing it) for those messages. That way, all
> buttons are consistently located and easily found using basic human memory.
As I pointed out earlier people don't always evaluate the header very
well and thus make the wrong choice for this button. I often miss the
fact that an email was sent to me and to other people because I tend to
gloss over the headers; especially if the line is short in length. I've
seen in studies and met many other people prone to this as well. This
discussion would be one of future possible errors on the new design if
the old two button design was flawless in this respect.
I would recommend the approach of defaulting to the reply only or reply
all combined with a good toggle interface for the compose window. For
some people reply all makes more sense as the default and reply being
the exception; these are mostly personal mail only users. For personal
and business users where email is more heavily used then reply to sender
is a more sensible default. People need the option to choose their
default and everyone needs the safety net to prevent mistakes.
> Also, having drop-downs on both buttons is just horrible UI (it reminds
> me of the uncle of all bad UI: Lotus Notes). At minimum, the logic
> should detect when there are two buttons, and then remove the drop-down
> from the reply-to-sender button.
Yes the current implementation can be improved. As I was the one up all
night trying to get something in I know it's not quite finished but it
allowed us to get the needed string in before string freeze. Feel free
to provide patches yourself as I'm pretty tired and haven't seen much of
my family for weeks. Many times your attitude is really annoying.
> 1. The reply-to-all icon is nearly indistinguishable from the
> reply-to-sender icon, especially at that too-small-size.
There is a bug for this.
> 2. The reply-all button disappears when there is only one recipient.
> This makes the reply button's location vary, which is bad. It
> would be better if the reply-all button just became disabled
> (gray). This is made even worse by #1.
If we continue with the two button implementation then we'll likely need
to redesign them to work better together. However I'm not certain
having the reply all button always show is the correct redesign. I
think something like a combined button might make more sense. i.e. (
reply ) or ( reply | reply all ) such that it is still the same object
but has more options when the situation requires.
> 3. Selecting multiple messages: The buttons are always icons+text and
> don't respect the user-chosen setting (e.g., icons only).
I believe there is a bug for this.
> 4. The Archive and Junk buttons are taller than the others in
> icon+text mode (WindowsXP). (in the unlikely case that hasn't been
> mentioned/noticed yet)
There is a bug on this.
> 5. The "Other Actions" menu opens "up" although there is plenty of
> space below the button.
I've never heard of this before, maybe that's a toolkit issue?
> 6. It's not possible to mark multiple selected messages as junk (the
> button disappears for multi-selections).
I thought there was a bug on this a while ago but I couldn't find it
recently. We should add this.
> 7. There are no tool-tips for the buttons when multiple messages are
> selected.
I think there is a bug for this but there should be one if there isn't.
> 8. The tool-tip for the delete button doesn't say "undelete" for
> mark-as-deleted messages.
I haven't seen a bug for this.
> 9. The Tag button should also be put into the header.
I don't think we have a bug for this either but we should.
> Need ability to disable the header toolbars completely:
I believe this is being done in the continue toolbar customization bug.
You brought up a larger topic that I think is really interesting but
perhaps for another thread. There are a number of things that could be
done to target Thunderbird for a specific set of users. The elderly for
one are a class of users who are classically ignored and have special
needs like increasing the text size that aren't handled very well right now.
Another is the netbook problem where smaller screen sizes make
Thunderbird difficult to use. I started on an add-on recently which
could optimize for a "netbook mode". Right now the add-on simply turns
on auto-hide tabs, hides the status bar, and sets toolbars to small icon
only mode. There are lots of other avenues to take here in further
iterations.
http://hg.mozilla.org/users/clarkbw_gnome.org/tb4netbooks/
My larger point is that we can't make Thunderbird everything to
everyone. But thanks to lots of hard work by the TB devs it's much
easier to write extensions. And we can create specific extensions to
handle these problems, possibly even packaging Thunderbird with these
extensions by default.
Cheers,
~ Bryan
Wayne Mery
On 10/2/2009 3:18 AM, Alan Lord (News) wrote:
> On 02/10/09 00:11, Eddy Nigg wrote:
> <snip />
>>
>> Well, I wasn't aware of discussions addressing those issues and it
>> wasn't important enough for me to "complain", but I must say that I
>> agree with most what Peter suggested. I never use those buttons in the
>> content area - it was nice to see them when they appeared initially
>> (like, yeah something new in TB), but besides that, they make this area
>> extremely cluttered. I think you guys should over-think some of what's
>> being said here.
>>
>
> I also haven't seen a great deal of discussion regarding this rather odd
> and counter-intuitive UI chnage.
>
> I think Peter is pretty much spot on.
These issues have been in wiki proposals, in bugs, in open meetings, and
in newsgroup posts for many, many months - quite accessible. For example
bug 449691 and bug 456814 header bugs started over a year ago. And bug
474523 regarding toolbar at start of this year.
> I haven't got used to the buttons in the header either. It just doesn't
> make sense to scatter them all over the place and, as others have
> already pointed out, I had *no* idea I could use them for multiple
> messages.
Your comment about multiple messages seems to indicate the toolbar isn't
sufficient (I agree) and ...
a) That operations on multiple message selection isn't terribly
discoverable via the main toolbar. Not surprising. OTOH, with selection
summary turned on, one could potentially see what operations are
available for multiple messages. But right now only Trash and Archive
are shown. So more needs to be added.
b) Sadly, that people probably also don't know the context menu exists,
and yet it lists pretty much everything one would want to know about
they've clicked on. It's right there, close to the message(s) without
having to blast up to the toolbar or any icon location, and it's also
keyboard accessible. It's the best of both worlds IMO, keyboard+mouse in
one spot. (can you tell I rarely used the toolbars or buttons?)
Hopefully a) above will be improved in 3.0. I think Bryan and others
briefly touched on it. Thanks for pointing it out.
Benjamin Smedberg
> These issues have been in wiki proposals, in bugs, in open meetings, and
> in newsgroup posts for many, many months - quite accessible. For example
> bug 449691 and bug 456814 header bugs started over a year ago. And bug
> 474523 regarding toolbar at start of this year.
I think that many of us who use TBird betas and are otherwise disconnected
from Tbird development only just discovered these plans when we were updated
to b4. Now that I've customized b4 to be just like b3 I can mostly continue
ignoring the extra toolbar, but in the default configuration b4 was
basically completely unusable. Whether the designs were public/in bugs/etc
is really irrelevant to the concern we're experiencing right now.
--BDS
Nikolay Shopik
>
> We can't and won't spend time discussing it to death now, as we need to
> focus on getting 3.0RC1 out the door.
This basically means - we can't argue about that right now, let's forget
about that for next major release. Because nobody expect minor release
3.0.x to fix this as it make major changes in interface and user not
expecting this when doing update to new minor release.
David Ascher
FYI, We're planning to do a 3.1 release not too far in the future,
though, where we can do UI changes. And there are add-ons that can undo
all of these changes in the meantime.
--david
Nikolay Shopik
> FYI, We're planning to do a 3.1 release not too far in the future,
> though, where we can do UI changes. And there are add-ons that can undo
> all of these changes in the meantime.
Yeah but we don't know how far we from 3.1 release yet. Addons are fine
by me, but let's not forget how powerful is DEFAULT around world, when
user expect everything be in place right out of box. And especially
users who are migrating from their old conviniet to use mail client.
Also let's not forget general rule don't brake what not broke. You
decide to make such changes mostly because of netbooks and small screens
horizontal resolution, but what about vertical, toolbar still take up
need space.
Netbooks are popular without dobut, but why these changes can't make
into addon?
Ben Bucksch
> With the current TB3 toolbar and header layout all buttons and search
> are visible at both 800px and 1024px with the same options available
Unfortunately, they are not. The buttons are hiding a big part of the
From address, and the "Other actions" button often hides the "more"
recipients button. That's [1], please see the screenshots there, which
are made with even bigger window sizes than 1024px width.
* I think that the buttons in the message header are a great idea,
because they put the UI (the buttons) closer to what it they apply to
(the message), so it's a more direct and natural UI.
* However, the placement [1] should have been fixed (proposals there)
before shipping. Unfortunately, it'll be a lot of work and risky, and
it's too late for that now for 3.0. Maybe I'll work on it for 3.1.
* Unfortunately, the additional button added in [2] makes the situation
considerably worse now (just look at the screenshots in [1] and imagine
even *less* space for From). Can you consider reverting that change, so
that by default, there's only one reply button, (with a proper default
action and dropdown, like before), leaving more space for "From"? This
is highly visible, and unbearable when you're in that situation (window
<= 1024px, and not knowing/looking for this pref).
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=520249
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=523254
https://bugzilla.mozilla.org/show_bug.cgi?id=511924