Closed Bug 508250 Opened 15 years ago Closed 11 years ago

Provide "Forward as" options as dropdown button menu entries (dualbutton / menu-button for forwarding inline vs. attachment)

Categories

(Thunderbird :: Mail Window Front End, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 24.0

People

(Reporter: tessarakt, Assigned: Paenglab)

References

()

Details

(Keywords: ux-consistency, ux-discovery, ux-efficiency, Whiteboard: [gs])

Attachments

(4 files, 5 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.2) Gecko/20090729 Firefox/3.5b4pre AutoPager/0.5.2.2 (http://www.teesoft.info/)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3pre) Gecko/20090803 Lightning/1.0pre Shredder/3.0b4pre

The main menu has an entry
Message -> Forward as -> [Inline | Attachment]

However, the "Forward" button in the main toolbar and the button in the message pane don't offer choices.

The button in the main toolbar should have an behavior like the "Write" button: Pressing the picture performs the default action (forwarding in default mode), pressing the arrow should open the menu and offer the choices.

The same holds for the button in the message header. It's behavior should resemble that of the "reply ..." button.

Reproducible: Always
Try my Forward extension...
https://addons.mozilla.org/en-US/thunderbird/addon/7026/

Otherwise this is probably a duplicate of (part of) bug 17796
17796 is a SeaMonkey bug, so not an exact duplicate.
Strictly speaking, it's a dupe of bug 392924, which was closed "won't fix" based on bug 17796 comment #95. That comment was posted in 2005 and things have changed since, thus that decision should be reevaluated. Even if bug 474523 removes that button from the default toolbar, it may still apply if put there by customization.

Confirming as valid RFE, though this would put Onno's extension out of business. ;-)
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
Bryan, another kind request for quick UI-review.

- This is basic functionality which has been requested since 1999 (in SeaMonkey bug 17796, 21 votes). It's probably easy to implement (just a split dropdown button...). Seamonkey now has this implemented.
- We have no reason to assume that choosing *either* Inline or Attachment as a default setting from options will cater for the user's daily needs. Both in business and private contexts, we can easily have scenarious where it depends on the circumstances of each mail which method of forwarding will be used for different mails. Toggling the setting is way to complex, going through the message menus isn't much better. We don't even offer a choice (a la "Forward as >") in the context menu.
- With this RFE, we'll be exposing valuable functionality (many users will never come across the non-default forward option...) at virtually no cost: No clutter, almost no extra space (few px for the little arrow).
Bryan, here's a screenshot of the proposed UI, hoping for your UI-review+.
Some thoughts and reasons in previous comment 4.
Attachment #431672 - Flags: ui-review?(clarkbw)
(In reply to comment #5)
> Created an attachment (id=431672) [details]
> Screenshot 1: Forward button dropdown in Seamonkey and UI Proposal for TB 

Actually, the screenshot is misleading
- dropdown part of reply to sender button will be removed (as it never showed anything) in bug 519956
- the dropdown part of reply all button has been requested by Bryan to be suppressed if it doesn't have anything to offer (bug 519956 comment 144)
We're already saving those few pixels that we need to implement this.
-> In many cases, forward dropdown will be the only dropdown button, so no 100 arrows problem.
Instead of making the default selection bold, I think it's better to show the default choice first and the non default choice second. Using bold in the header button drop down clashes with the reply button drop down menus...
Attached image My UI proposal for TB
Attachment #431679 - Flags: ui-review?(clarkbw)
For a number of people the option of Inline or Attachment is not an obvious choice, I think we need to avoid default UI options that present those kind of choices.

I'm wondering how we can make this work so that other, more advanced, Thunderbird users could take advantage of this.  I'm sure this could easily be kept as an extension.  I'm not sure I'd want to make this button into a preference between the button or menu-button.

I'm going to clear out the ui-reviews until we have some direction.
Attachment #431672 - Flags: ui-review?(clarkbw)
Attachment #431679 - Flags: ui-review?(clarkbw)
(In reply to comment #9)
> For a number of people the option of Inline or Attachment is not an obvious
> choice, I think we need to avoid default UI options that present those kind of
> choices.

Is it really that bad if the button works as a button by default that does the default action, but has an optional dropdown menu, like the reply button? I rather think the users who would be confused by the inline vs. attachment difference would be mostly the same users that wouldn't know they could click on the little drop down menu, and would happily click the forward button.

One suggestion for the drop down text - something like forward | message body vs forward entire message.
(In reply to comment #10)
> One suggestion for the drop down text - something like forward | message body
> vs forward entire message.

To me that desn't feel right. I feel the distinction between body and entire message could be even more difficult than that between inline text and attachment. And it's not what I usually base my choice on. Instead, I consider whether I want the text inline, so I can edit it, strip it, comment it, or whatever, or whether I want to attach it like I attach a file, as an opaque entity I can be sure will be transmitted unmodified.
Agreed "message body" could be confusing, considering forward also forwards message attachments.
(In reply to comment #10)
> Is it really that bad if the button works as a button by default that does the
> default action, but has an optional dropdown menu, like the reply button? I
> rather think the users who would be confused by the inline vs. attachment
> difference would be mostly the same users that wouldn't know they could click
> on the little drop down menu, and would happily click the forward button.

I wouldn't think that the error case is bad, as in irrevocable data loss, but I do think the option is pretty confusing and not quite the same as reply vs. reply all in a drop down.

I was thinking over the weekend that if bug 519956 were to get finalized we could offer a forward button with the drop down in the toolbar palette and thus we could avoid the default drop down scenario but also allowing other users to gain that functionality.
http://gsfn.us/t/1cc5x

That getsatisfaction report was unable to even find the "Forward As > Attachment" command because it is so well-hidden in the main menu, instead of being made available as a tiny dropdown where one would expect it, next to forward button and forward context menu.
Summary: Provide "Forward as" options as drop-down button menu entries → Provide "Forward as" options as dropdown button menu entries (dualbutton / menu-button for forwarding inline vs. attachment)
Whiteboard: [gs]
See Also: → 17796
(In reply to comment #13)
> I wouldn't think that the error case is bad, as in irrevocable data loss, but 
> I do think the option is pretty confusing and not quite the same as reply vs.
> reply all in a drop down.

Bryan, you are certainly right that the type of choice we propose here for the dropdown part of Forward button is not *exactly* the same as that of reply to sender vs. reply all. But then, the dropdowns you get for the write button, or the tag button, are also entirely different. I think the bottom line is that users have come to expect a dropdown to offer alternative commands that *relate to* the main button functionality. So it's obvious that the dropdowns are all  different in type, depending on what functionality the main button has.
Forward to sender or Forward to all just don't make sense on a forward button (and thus no user will expect that when deliberately peeping into the dropdown);
Forward as inline vs. Forward as attachment do make a lot of sense there.

Actually, I would revert Bryans logic:

1) If we were to keep all options hidden that might under any circumstance potentially cause a bit of initial irration to some first-time user, we could ultimately hide half of our UI because there are complex features everywhere that might irritate at some point.

2) The "Protect the simple user against anything surprising"-logic will fatally turn into a self-fullfilling prophecy:
a) we are keeping any advanced options out of sight so as to "protect" the simple user
b) simple user will never come across the advanced options
c) simple user will forever stay uninformed about the advanced options (and assume they are no-go advanced stuff because they are so thoroughly tucked away), re-enforcing the need to "protect" him against those
IOW, hiding useful functionality will ultimately make that functionality undiscoverable, and even forgotten, as users are kept unaware of it

3) On the contrary, we should make useful advanced options *visible* in a *smart* and *non-intrusive* way so that *all* users, while being assisted with sane defaults, still have a chance of discovering advanced alternatives and benefitting from the choice, which will ultimately lead to a higher degree of user satisfaction.

4) Applied to this case, having a tiny, independent dropdown button next to the big default forward button is a smart and non-intrusive way of educating the (simple) user that they actually have a choice when forwarding messages, so we are gently hinting at an important and useful feature, without obfuscating the simple default functionality in any way.

5) It's interesting to note that even a so-called "advanced user" who has already used "Forward as attachment" before is apparently having problems to find the command in the main menu, as in the support case of http://gsfn.us/t/1cc5x.

This discusssion is very reminiscent of a very unfortunate discussion in FF about providing access to the keyword (not tags!) feature from the yellow star's bookmark panel:
- FF devs say: Oh, let's keep that advanced keyword stuff tucked away in the library, it's too difficult for the average user
- As a consequence, no user will EVER come across the ingenious keyword aka location bar alias/quick search functionality unless he already knows about it
- ingenious keyword functionality (which still forms an important and unique part of FF supreme location bar efficiency) will ultimately die out as a feature because no one ever comes across
- The smart solution would be to have a *tiny* more button on the bookmark panel that reveals the "advanced" properties *on request*. That hides them enough so that the simple user isn't confused by things he cannot yet understand, but still keeps them within reach when the simple user grows up and feels like exploring what's behind the "more" button.
- Same philosophy applied to this bug: Give the simple user a chance learn and explore, whenever he feels ready for it, what these "other" forward options are under the tiny "dropdown" button next to the big default FORWARD button that you can't miss.

> I was thinking over the weekend that if bug 519956 were to get finalized we
> could offer a forward button with the drop down in the toolbar palette and 
> thus we could avoid the default drop down scenario but also allowing other
> users to gain that functionality.

If that's the only way to make Bryan happy, yes. Otherwise, I don't think this is the right strategy as explained in detail above.

Btw, who defends the advanced users who also want sane defaults without re-configuring every little corner that has been ironed away to "protect" the simple users?
^^
Yes, one can "elegantize" the UI until you are left with only what 90% of users use, which seems to me to be the wrong model. (unless there is a strong, intuitive alternative)

I leave the core issue of this bug to others more intimate to its use. (I almost never use buttons)
(In reply to Wayne Mery (:wsmwk) from comment #17)
> Yes, one can "elegantize" the UI until you are left with only what 90% of
> users use, which seems to me to be the wrong model. (unless there is a
> strong, intuitive alternative)

Wayne's comment is really spot-on. To add on that, more thoughts about the (non)sense of counting (skip this comment if you're not in the mood for philosophy):

1) I doubt that there'll be a shared feature set used by 90% of users; the intersection might be much smaller than we think.

Just counting how many users use a feature is too simple. In reality, things are a lot more complex, and we also need qualitative measurements which are hard to get:

2) We'd also need to measure *how important* certain features are for certain users. Suppose there would be only 10% of users using "Forward as attachment", but for those 10%, the feature might be so important that if you take it away (with or without providing addons), they'll stop using Thunderbird.

3) Different users have different values, so the same applies for other users for whom other features are absolutely must-have. So if we take away all the features that are only used by 5% or 10% of all users (merely based on a *per-feature* quantitative count), we might be surprised ending up with no users at all (instead of 90%).

4) We'd also need to measure emotions. Perhaps there are a million users downloading a certain addon. It's too simple to just assume that all of them are happily following the logic of downloading addons easily for whatever they think is missing. Perhaps it's a million users for whom the usability pain of not having that feature was so big that the pain of digging into addons and bothering to install them and pray for addon updates every time we update our application is just less painful. But we don't know their emotions while going down the addon path, and we might be shocked how many of them are actually cursing our product while they do. Which is bad for the popularity of our product even if they are only 5.000 users.

5) However, for successful program design it's certainly still not enough to count users of a feature, to measure the importance of features to those who use them, and to measure the emotions we cause through bad or missing features. Apart from all of those, good developers will be creative and innovative in their products. Computers and iPhones were not developed because the millions were screaming for them, but because some capable people trusted their creative intuitions. A good developer also has those common-sense intuitions about how not to break or complicate things and create usability issues for no reason.

6) In fact, there's hope even for developers who don't have those intuitions: It's called design guidelines. Oh yes, and they cater for what we might call user intuitions or expectations which over the course of time have been built up by adherence to good design guidelines (I'm deliberately simplyfying things, but you get the idea - think about why Windows was so successful...). Among them some familiar friends like UX-consistency, UX-efficiency, UX-discovery and so on... Which, after the philosophical excursus, brings me back to this bug... (see next comment).
The lack of of this feature violates several UX principles, e.g.:

* UX-consistency
It's inconsistent that we offer two valid ways of attaching (inline vs. as attachment), but one of them is represented only in half of the respective UI. Whichever the user's preference, we have no reason to assume that users are not using the other option at least occasionally. It's inconsistent that I can use my preferred option with a single click on a button in the message header pane (in-place), but to get to the other option, I need three mouse moves/clicks through the main menu. It's also inconsistent that we don't offer the two valid ways of attaching in the context menu, nor as a keyboard shortcut, nor with modifier keys (not saying we can/must have all of them, but the in-place dropdown button is really the minimum solution to be expected!).

*UX-efficiency
See above. It's obvious using "the other way" is highly inefficient in every respect. Avoidable UX-inefficiency should be avoided, and creates bad emotions in users. Pls let us have the bloo...ming dropdown.

*UX-discovery
As mentioned before (my comment 15), implementing the dualbutton with that tiny dropdown corner will actually help all kinds of users to discover both ways of attaching. Which is a good thing. Currently, we are making it way to hard for users to discover "the other way", which is a bad thing. Because it violates UX-discovery.

Another telling (if extreme) example to illustrate the UX failure due to this bug can be found in the most recent duplicate, Bug 699500, Comment 0:

> Rather than having to close the compose window, dig into the preference,
> switch the preference, and start the mail over again... it would be nice if
> there was a way to switch forwarding modes.

Yes, it's just one datapoint, but it illustrates the obvious: People don't like or even think of going into main menus for everyday routines that could be so easily available in the main UI, at the ever-so-low cost of a 9px-wide dropdown corner added to the forward button (And in case you worry about those 9px, have a look at bug 525210, Attachment 464469 [details] to see how with native button layout, we could easily reduce all those horizontal gaps between all the buttons to something around 4px).
For the reasons mentioned in comment 19 (and more), I don't believe in counting addon users or wasting more time to fight common sense UX design by creating and analysing questionable data pilot studies than it would take to actually implement the feature, but for those who do believe in numbers, here are some:

From the statistics (1) of Onno Eker's "Forward" addon (2), which addresses exactly and only this bug:

52,193 Total Downloads (of which 425 in the last 30 days)
 6,328 Average Daily Users (6,641 average in last 30 days)

I don't know how these work, or if they are true, but that's what it says.
Add to that an unknown number of users that use Kaosmos' "ForwardAs" addon (3) from an unofficial download website.

1) https://addons.mozilla.org/en-us/thunderbird/addon/forward/statistics/?last=30
2) https://addons.mozilla.org/de/thunderbird/addon/forward/
3) https://nic-nac-project.org/~kaosmos/index-en.html#frwas
(In reply to Thomas D. from comment #21)
> For the reasons mentioned in comment 19 (and more), I don't believe in
> counting addon users or wasting more time to fight common sense UX design by
> creating and analysing questionable data pilot studies than it would take to
> actually implement the feature

Couldn't agree more (see bug 647036 for another example of misguided statistics).

On a side note, SeaMonkey has offered that drop-down menu in their standard releases for quite a while now, and I don't recall /one/ thread in the SeaMonkey forums indicating that someone was confused by the options it provides.

Personally, I'm forwarding inline by default and use the "As Attachment" mostly to forward spam to my provider for training of their filters.
As an alternative, how would people feel about ctrl-clicking on the Forward button to use the non-default forwarding type (so, usually you'd ctrl-click to forward as attachment)? I've already discussed this with bwinton, and he thinks this would be an acceptable compromise.
(In reply to Jim Porter (:squib) from comment #23)
> As an alternative, how would people feel about ctrl-clicking on the Forward
> button to use the non-default forwarding type (so, usually you'd ctrl-click
> to forward as attachment)? I've already discussed this with bwinton, and he
> thinks this would be an acceptable compromise.

I would not like this.  In my experience with Thunderbird there are no ctrl-click buttons and so I'd never think to ctrl-click any button.  (For me, on a Mac, ctrl-click brings up the "Customize" menu so maybe this is a cross-platform UI misunderstanding?)  There may be buttons which act this way, but I've never encountered them so none of that helps in being able to find the new Forward functions.

If the functionality is invisible in the UI (ie. there's no visible indication that a button responds to ctrl-click) then it is unlikely to be found and used.

The simplest and most obvious solution would seem to me to make Forward a drop down like "Get Mail" which offers "Inline" or "Attachment".  Make the default whatever is set in the preferences, just like it is right now.

It feels like there's an internal debate about drop down buttons.  This feature should not be held up because of a larger UI debate.  If it's decided later there's something better than drop downs, switch EVERYTHING to that all at once including the Forward button.  The worst thing would be to make some buttons act one way and some buttons act another, which I feel Jim's proposal would do.
(In reply to schwern from comment #24)
> (In reply to Jim Porter (:squib) from comment #23)
> > As an alternative, how would people feel about ctrl-clicking on the Forward
> > button to use the non-default forwarding type (so, usually you'd ctrl-click
> > to forward as attachment)? I've already discussed this with bwinton, and he
> > thinks this would be an acceptable compromise.
> 
> I would not like this.  In my experience with Thunderbird there are no
> ctrl-click buttons and so I'd never think to ctrl-click any button.  (For
> me, on a Mac, ctrl-click brings up the "Customize" menu so maybe this is a
> cross-platform UI misunderstanding?)  There may be buttons which act this
> way, but I've never encountered them so none of that helps in being able to
> find the new Forward functions.
> 
> If the functionality is invisible in the UI (ie. there's no visible
> indication that a button responds to ctrl-click) then it is unlikely to be
> found and used.

It's not invisible, since the options exist in the Message menu, or you could just compose a new message and drag the old message into the attachment pane. In any case, this UX already has precedent, since shift-clicking on composition buttons ("Write", "Reply", etc) opens the HTML editor (or plaintext, depending on your prefs).

> The simplest and most obvious solution would seem to me to make Forward a
> drop down like "Get Mail" which offers "Inline" or "Attachment".  Make the
> default whatever is set in the preferences, just like it is right now.

That's probably not going to happen, since I see no reason to disagree with clarkbw's points (and bwinton didn't seem to either). Going down this path, you could ask why we don't turn the reply button into a dual-button letting you choose whether to compose in plain text or HTML. Or why we don't turn the delete button into a dual-button letting you send to trash or delete permanently.
(In reply to Jim Porter (:squib) from comment #25)
> > If the functionality is invisible in the UI (ie. there's no visible
> > indication that a button responds to ctrl-click) then it is unlikely to be
> > found and used.
> 
> It's not invisible, since the options exist in the Message menu, or you
> could just compose a new message and drag the old message into the
> attachment pane.

The functionality may be visible elsewhere, but that doesn't make it any more likely that I'm going to know ctrl-click does the same thing.  If the new functionality is unlikely to be found and used, what's the point of adding it?


> In any case, this UX already has precedent, since
> shift-clicking on composition buttons ("Write", "Reply", etc) opens the HTML
> editor (or plaintext, depending on your prefs).

These too are invisible.  I had no idea they existed.  I had no way of knowing by looking at the UI.

Furthermore, just because shift-click does something doesn't mean I'm going to start clicking on things with various modifier keys just to see if it does something special.

 
> > The simplest and most obvious solution would seem to me to make Forward a
> > drop down like "Get Mail" which offers "Inline" or "Attachment".  Make the
> > default whatever is set in the preferences, just like it is right now.
> 
> That's probably not going to happen, since I see no reason to disagree with
> clarkbw's points (and bwinton didn't seem to either). Going down this path,
> you could ask why we don't turn the reply button into a dual-button letting
> you choose whether to compose in plain text or HTML. Or why we don't turn
> the delete button into a dual-button letting you send to trash or delete
> permanently.

Quite honestly, those all sound worthy of discussion.  Certainly they don't invoke "this way madness lies" to me.  Maybe we're miscommunicating?

To be clear, I'm referring to behavior of "Get Mail" which has a default (get all mail) but also a drop down to select specific behaviors with the default clearly at the top.  clarkbw's points seem to solely deal with what the default forwarding behavior should be, and there is a very simple answer: it's whatever the preferences say it should be just like it is now.  That does not regress any from the current situation.  Alternatively, the button has no default and when you click it, it just splits.
Since Jim referred to clarkbw, I'd like his suggestion a few comments up:

(In reply to Bryan Clark [:clarkbw] from comment #13)
> could offer a forward button with the drop down in the toolbar palette and
> thus we could avoid the default drop down scenario but also allowing other
> users to gain that functionality.

The comparison with the Shift toggle for plain-text/HTML composition is a bit misplaced here and would be moot to that extent if bug 216132/bug 140800 were addressed to allow switching on the fly with the editor open already. I don't see this similarly applicable to the Forward As function (which in turn would be independent of the plain-text/HTML toggle, thus you'd need a 4-way toggle if implementing it by keyboard modifiers) unless the aim is to convert the forward mode in an already opened composition window in the same way.
Another (not mutually exclusive) alternative: add "Forward as Attachment" under the "Other actions" dropdown.

(In reply to schwern from comment #26)
> (In reply to Jim Porter (:squib) from comment #25)
> > In any case, this UX already has precedent, since
> > shift-clicking on composition buttons ("Write", "Reply", etc) opens the HTML
> > editor (or plaintext, depending on your prefs).
> 
> These too are invisible.  I had no idea they existed.  I had no way of
> knowing by looking at the UI.

Likewise, ctrl-clicking or shift-clicking links in Firefox has no UI, but people are aware of it (at least based on support requests when it breaks). This is one of those areas where providing good documentation would help; it would be pretty easy to write a knowledge base article about how to forward messages in different ways, and one would hope people would take a few seconds to consult documentation before asking for support. Maybe that's overly optimistic, but it would also provide a quick like to give to people asking for support, too.

> > That's probably not going to happen, since I see no reason to disagree with
> > clarkbw's points (and bwinton didn't seem to either). Going down this path,
> > you could ask why we don't turn the reply button into a dual-button letting
> > you choose whether to compose in plain text or HTML. Or why we don't turn
> > the delete button into a dual-button letting you send to trash or delete
> > permanently.
> 
> Quite honestly, those all sound worthy of discussion.  Certainly they don't
> invoke "this way madness lies" to me.  Maybe we're miscommunicating?

Every header button could easily have a dropdown associated with it, but this takes up extra space and adds more complexity for something that, I imagine, not many people need (the same applies to "delete permanently" and "compose in HTML/plain text"). Of course, now that we have Test Pilot, we can figure out exactly how many people need this feature by writing a survey that directly asks people if they've needed to forward messages as attachments. However, I absolutely disagree with the notion stated in comment 21 that a Test Pilot study is more work than fixing this, therefore we should just fix it. The simplicity of a patch has no bearing on whether it's good or bad UX.

> clarkbw's points seem to solely deal with what the default forwarding behavior should be...

I believe his point is that the dropdown would present users with a choice that they aren't sufficiently informed to make. Even when a feature doesn't take up much space in the UI, it still carries a burden. Whether people care about the distinction between attaching inline or as an attachment, they'll still click the dropdown to see what it says. If the user doesn't have a clear understanding of the distinction between forwarding inline or as an attachment, they won't be able to answer the question that the UI presents (this is a violation of ux-interruption). Even users who do understand the difference may not care most of the time (I know I don't), so we'd be forcing them to make a decision about something they didn't expect.

That's why I'm proposing alternatives: we can definitely make it easier for users who *do* care about the distinction without presenting others with options they either don't understand or don't care about.

(In reply to rsx11m from comment #27)
> I don't see this similarly applicable to the Forward As function ... unless the 
> aim is to convert the forward mode in an already opened composition window in the
> same way.

Actually, I *would* like to do that eventually (more or less). We've already got the ability to quote a message as though you replied after the fact (in the composer, Options -> Quote Message). It wouldn't be unreasonable to do something like that for forwarding. One UI I've considered is to add a "Message..." option to the Attach button's dropdown in the composer, which would make it easier to attach multiple messages, etc.
Duplicate Bug 819925 has another anecdotic evidence how we are confusing average users by hiding "Forward As" somewhere deep down in the AppMenu:

Reporter of that bug even proposed to make "Message" menu available for toolbar customization of Mail Toolbar, only for the ultimate goal of having easier access to "Forward As".

Well, developers willing, we could just make it optionally available at everyone's fingertips by adding a 3mm wide split dropdown corner to the existing "Forward" button, so that it becomes a *split/dual* [Forward |v] button, as proposed in this bug.
(In reply to Jim Porter (:squib) from comment #28)
> Another (not mutually exclusive) alternative: add "Forward as Attachment"
> under the "Other actions" dropdown.

That's better than status quo, but it's really cynical to add the "Forward as Attachment" command in the cesspool of "Other actions" (which users have to parse every time they press the "Other actions" button), instead of adding it where it belongs, as an optional alternative when users deliberately click the 3mm wide dropdown arrow of the [Forward |v] split menu button proposed here.

> (In reply to schwern from comment #26)
> Likewise, ctrl-clicking or shift-clicking links in Firefox has no UI, but
> people are aware of it (at least based on support requests when it breaks).

Imho that comparison doesn't work very well:
- there can be hundreds of links on a single web page, so it's quite unthinkable to have a permanent visual dropdown UI added to each of them; but there's only a single forward button on each message, to which this bug requests to add 3mm of width for a separate dropdown arrow.
- Even without Ctrl+Click, FF users can access the alternative behaviour in an intuitive and in-place way from the context menu ("Open link in new tab"). Whereas in TB, users have to dig into the main menu (4 steps using app menu!) to get to the alternative behaviour (this bug).
- The frequency and urgency of user's need to open links in a new tab to not lose web page context is probably somewhat considerably higher than forwarding messages in default or alternative way (so there's a higher motivation to discover the keyboard shortcut for that).
- The established Ctrl-clicking of links is still not quite the same as Ctrl-clicking buttons, which is pretty unheard of. Fwiw, the shift-click button behaviour we're currently fixing elsewhere is equally undiscoverable, but it's a stopgap solution until we expose that text/hmtl alternative in the UI with bug 216132 / bug 140800. Moreover, it would be very complex to add a visible text/html switch to all of the current UI, whereas it's very simple and ux-consistent to just add optional alternative behaviour (send as attachment) to the forward button.
- Ctrl+clicking buttons is *a lot* less discoverable than adding the dropdown, and imo there is no need for that complexity when we can have a simple solution (yeah, I don't believe we're exposing users to unanswerable questions with the split button, as I'll explain later)
- On the contrary, we should deliberately *expose* that choice so as to educate curious users about it; non-curious users can just easily ignore it as they press the main button part of the split [Forward |v] button.

> This is one of those areas where providing good documentation would help; it
> would be pretty easy to write a knowledge base article about how to forward
> messages in different ways, and one would hope people would take a few
> seconds to consult documentation before asking for support. Maybe that's
> overly optimistic

It is indeed overly optimistic, and I really don't see the point of having to rtfm instead of just exposing this little choice as a minimally intrusive option in the primary UI.
 
> However, I absolutely disagree with the notion stated in
> comment 21 that a Test Pilot study is more work than fixing this, therefore
> we should just fix it. The simplicity of a patch has no bearing on whether
> it's good or bad UX.

That's right, that's why I (in comment 15 ff) and others (e.g. David Bienvenu in comment 10, or Wayne's comment 17) have given plenty of arguments why we think the split-button solution is actually good UX, because it's ux-consistent, ux-discoverable, and ux-efficient. Moreover, SeaMonkey already has it and nobody has pointed out any UX-problems so far.

> > clarkbw's points seem to solely deal with what the default forwarding
> >  behavior should be...
> I believe his point is that the dropdown would present users with a choice
> that they aren't sufficiently informed to make. Even when a feature doesn't
> take up much space in the UI, it still carries a burden. Whether people care
> about the distinction between attaching inline or as an attachment, they'll
> still click the dropdown to see what it says.

I doubt that assumption very much. I know for sure that average users like Mum & Dad will never click on anything they don't absolutely have to click on to get their work done (they might not even *realize* the separate dropdown!). *Split* buttons like the [Forward |v] button proposed here are the perfect UI for that scenario: 2cm wide, big click target for the average user (to do plain vanilla forward, no fuss, no thought), and a tiny, separate, 3mm small click target for those who feel they need something else (forward as attachment). It's a win-win UX for both types of users. Really.


> If the user doesn't have a
> clear understanding of the distinction between forwarding inline or as an
> attachment, they won't be able to answer the question that the UI presents
> (this is a violation of ux-interruption).

Only that we are *not* presenting that question (inline vs. attachment) to the average user, because we're hiding it in a 3mm wide separate dropdown whereas the biggest part of the *split* button proposed here will act as plain-vanilla forward by default (without asking questions). So I really don't think there's any danger of UX-interruption here.

The real UX-interruption currently happens for users of all sorts who legitimately want to use the alternative way of "forward as attachment" on a single message (or more precisely, the opposite of whichever default they chose for plain forward).

I don't even see what is so difficult to understand about the difference between "forward inline" and "forward as attachment". Imo, "Forward as attachment" is very easy and straightforward to understand (even for simple users), perhaps "Forward inline" is a bit harder. Even for simple users, they would just have to try those *once* to see the difference. And I'd think it's actually desirable for them to to try and learn the difference. But then, with a *split* button, we're not forcing them to learn if they don't want, they can just press the main part of the button and ignore the choice which is hidden in the dropdown.

Btw, we are already forcing users to be confronted with the alternative "Forward as attachment" as soon as they select more than one message for forwarding...

> Even users who do understand the
> difference may not care most of the time (I know I don't), so we'd be
> forcing them to make a decision about something they didn't expect.

Sorry but imo that's not true. A *split* button with a tiny, separate dropdown does not force you to into unwanted decisions, as explained above.

> That's why I'm proposing alternatives: we can definitely make it easier for
> users who *do* care about the distinction without presenting others with
> options they either don't understand or don't care about.

Alternative 1 (Ctrl+Click) is undiscoverable.
Alternative 2 (optional *split* button available only through toolbar customization) is also pretty undiscoverable, and makes it unnecessarily hard for everyone to use and learn about the two equally relevant alternatives of forwarding (inline vs. as attachment).

That said, having Alternative 2 would be much better than the status quo.
(But I'm not sure if the extra work of maintaining two different button types is justified if we could just have a single button type that caters for everyone.)

I just wonder how you want to solve the same problem for the context menu, where we currently have a clear and entirely superfluous case of ux-interruption for those users who need "forward as attachment" of a single message. Since we already have devs complaining about too many options in the context menu, it would make a lot of sense to combine entries. *Split* menus (as we have now for the [Options | >] menu in AppMenu) are the obvious ideal win-win solution for everybody again. If we do the obvious for the context menu (split [Forward |>] menu), we'll just be ux-inconsistent again if we don't have the same *split* [Forward |v] button in the main UI, as proposed in this bug.
Attached patch patch for context menu (obsolete) — Splinter Review
I've made a patch for the context menu only as a first step.
I renamed the id of mailContext-forwardAsAttachment to mailContext-multiForwardAsAttachment because this menu entry is only visible when multiple messages are selected. Then I used the old id for the new menu entry. I hope this doesn't break extensions.
I also used the same accesskey for mailContext-forwardAsMenu and mailContext-multiForwardAsAttachment because they are never shown together.

If I have the time this weekend, I'll try to do a patch for the buttons.
Attachment #693594 - Flags: review?(squibblyflabbetydoo)
Richard, thanks for your patch, it's great to see this moving.

However for single msg selection, attachment 693594 [details] [diff] [review] replaces the plain vanilla "Forward" menu with a "Forward As >" popup menu. Personally, I'd be happy with that but as the devil's advocate (on behalf of Jim ;)), that actually forces all users to make a choice they don't want to make ("as inline" vs "as attachment") because plain vanilla "Forward" (to trigger whichever default forwarding method) is no longer available.

Ideally, we want a *split* (dual) menu in the same way you designed the
[Options | >] dualmenu in AppMenu (with separate main button part and dropdown):

[Forward | >][Forward Inline]
             [Forward as Attachment]

So users can still click the main [Forward |  part of the menu to just forward using their preferred default method (without having to make a choice).
Could you try that?
Please don't put split-buttons in the context menu. As far as I can tell, that doesn't have any precedent on any of the major OSes.
(In reply to Jim Porter (:squib) from comment #34)
> Please don't put split-buttons in the context menu. As far as I can tell,
> that doesn't have any precedent on any of the major OSes.

???

Both TB and FF are already using split-buttons in their main AppMenus, so what's different about using them in context menus?

The UX of split-button (dual menu) is just the same as any other popup menu (and you can use it the same way if you so wish, navigate to the popup menu and pick one option), only better (because you can *also* click the main part of the split menu which is more efficient and spares you from the choice).

Precedent or not, where is the UX problem?

The only problem I can see is that split-menus are currently not keyboard-accessible, which is not an argument against split-menus, but an argument for fixing that problem (also for FF, Bug 719761). Same for the insufficient distinction of tooltips (Bug 71329).
(In reply to Thomas D. from comment #35)
> (In reply to Jim Porter (:squib) from comment #34)
> > Please don't put split-buttons in the context menu. As far as I can tell,
> > that doesn't have any precedent on any of the major OSes.
> 
> ???

While other menus use split-buttons, context menus never use them, even in places where it might be useful to. We should try to remain consistent with the host OS.
(In reply to Jim Porter (:squib) from comment #36)
> (In reply to Thomas D. from comment #35)
> > (In reply to Jim Porter (:squib) from comment #34)
> > > Please don't put split-buttons in the context menu. As far as I can tell,
> > > that doesn't have any precedent on any of the major OSes.
> > 
> > ???
> 
> While other menus use split-buttons, context menus never use them, even in
> places where it might be useful to. We should try to remain consistent with
> the host OS.

Sorry, but I'm failing to follow that logic. If it's useful (as you say), intuitive, and not negatively interfering with the predominant UX of the host OS, we shouldn't we we be better while still being consistent?

Plus, FF and TB have already stopped to remain consistent with many host OS when they abolished the Title bar and the Menu bar. I understand and believe they have done so because they want better UX for their users.

I'm very much in favor of sticking to good practices and standards, but if we can be better than the standards without breaking things in unexpected ways, imho we should do so... And btw, OS also do the same, just look at the start screen of Win8, which is clearly not the same as Win7, but it's a gradual innovation which actually preserves most existing use patterns if you just push the same buttons as you used to.
(In reply to Thomas D. from comment #37)
> (In reply to Jim Porter (:squib) from comment #36)
> > (In reply to Thomas D. from comment #35)
> > > (In reply to Jim Porter (:squib) from comment #34)
> > > > Please don't put split-buttons in the context menu. As far as I can tell,
> > > > that doesn't have any precedent on any of the major OSes.
> > > 
> > > ???
> > 
> > While other menus use split-buttons, context menus never use them, even in
> > places where it might be useful to. We should try to remain consistent with
> > the host OS.
> 
> Sorry, but I'm failing to follow that logic. If it's useful (as you say),
> intuitive, and not negatively interfering with the predominant UX of the
> host OS, we shouldn't we we be better while still being consistent?

typo fix: why shouldn't we be better in the details while still being largely consistent with interaction patterns?
The problem is that it's not particularly intuitive, unless you think about the behavior of *different* kinds of menus. On Windows, for instance, submenus in context menus can be opened more quickly by clicking on them. Changing an item to a dual-button would make it appear as a submenu, but behave as a regular item when clicking.

The inconsistency of that with other context menus (in addition to subtle keyboard-access issues we'd have to fix) makes this a lot less attractive. If we feel people use "Forward As" often enough to put it in the context menu (I'm not entirely convinced that they do), it would be simpler for programmers and clearer for users just to have "Forward" and "Forward As" as two separate items.

That said, I still think it would be sufficient to add the ability to ctrl-click on "Forward" to forward in the non-default method, and then provide tooltips to introduce people to the feature. A dualbutton for the toolbars would be ok too.
(In reply to Jim Porter (:squib) from comment #39)
> That said, I still think it would be sufficient to add the ability to
> ctrl-click on "Forward" to forward in the non-default method, and then

Ctrl-click is used to toggle html composition (everywhere else, and there's a bug open to use it for the menus too), but i guess we could use Shift-click.
Oh ignore me, it's early here;) 
Shift+fwd toggles plain vs html.
(In reply to Thomas D. from comment #33)
> However for single msg selection, attachment 693594 [details] [diff] [review]
> [review] replaces the plain vanilla "Forward" menu with a "Forward As >"

It doesn't replace the "Forward" menu, it adds the "Forward as >" menu below like it is already on main menu and AppMenu under "Message". This makes the three menus consistent and doesn't need a split-menu. Only the accesskey is different because in context menu "w" is used for "Open Message in New Window". With bug 731673 applied also the shift modifier will work.
(In reply to Richard Marti [:Paenglab] from comment #42)
> (In reply to Thomas D. from comment #33)
> > However for single msg selection, attachment 693594 [details] [diff] [review]
> > [review] replaces the plain vanilla "Forward" menu with a "Forward As >"
> 
> It doesn't replace the "Forward" menu,

Sorry, I misread the patch...

> it adds the "Forward as >" menu below
> like it is already on main menu and AppMenu under "Message". This makes the
> three menus consistent and doesn't need a split-menu. ... With bug 731673
> applied also the shift modifier will work.

I like that approach for its ux-consistency between the threee menus and hassle-free mouse-only operation.

(In reply to Jim Porter (:squib) from comment #39)
> The problem is that it's not particularly intuitive, unless you think about
> the behavior of *different* kinds of menus. On Windows, for instance,
> submenus in context menus can be opened more quickly by clicking on them.
> Changing an item to a dual-button would make it appear as a submenu, but
> behave as a regular item when clicking.
> The inconsistency of that with other context menus (in addition to subtle
> keyboard-access issues we'd have to fix) makes this a lot less attractive.

Agreed.

> If we feel people use "Forward As" often enough to put it in the context
> menu (I'm not entirely convinced that they do), it would be simpler for
> programmers and clearer for users just to have "Forward" and "Forward As" as
> two separate items.

+1
 
> That said, I still think it would be sufficient to add the ability to
> ctrl-click on "Forward" to forward in the non-default method, and then
> provide tooltips to introduce people to the feature.

Tooltips could indeed make Ctrl+Forward more discoverable, but I'd prefer to allow for mouse-only access with the two separate menus.

> A dualbutton for the toolbars would be ok too.

Jim, could this be a *default* dualbutton (with or without a spare plain (Ctrl+)forward button in the customization palette)? I think showing the dualbutton by default will make it more consistent with the menus where we also explicitly offer the choice between inline vs. as attachment.
Please have a look at my Forward extension to see how i add Forward As to the Application menu. It's MPL2.0 licensed, so you can use the code for Thunderbird. The only weird thing in my extension is the header forward button, because I add it in javascript insted of xul. That was done because there was no other way in the beta stage of TB3.0... In the latest version that isn't yet released (0.16), I also change the default action to Forward as Attachments when you have more than 1 message selected. See http://forward.mozdev.org/ for the latest source.

Other extensions that do something with the Forward button/menu are:
- Compact Header: Clones the toolbar button to the header
- Stationery: Adds a menuitem to the Forward button
- NotTo_Ojx: Adds a menuitem to the Forward button
- ForwardAs: Similar to my add-on, hosted on http://nic-nac-project.de/~kaosmos/index-en.html. Haven't checked this extension, but it probably does something with the Forward menu and buttton too...
Attached patch patch for toolbarbuttons (obsolete) — Splinter Review
A little bit earlier than weekend, but with the end of the Mayan calendar I don't know if I'm able to to this then ;-).

This patch lets the main toolbar- and messageheader-button work as before with the default forward behavior. Clicking on the dropdown arrow opens the popup with both forward possibilities.

This patch needs bug 731673 and the contextmenu patch applied first.
Assignee: nobody → richard.marti
Status: NEW → ASSIGNED
Attachment #693991 - Flags: review?(squibblyflabbetydoo)
Apologies for taking so long on this review. I promise I'll look at this after the 15th, when my plate isn't quite so full.
Comment on attachment 693991 [details] [diff] [review]
patch for toolbarbuttons

I don't think we should be using a menu-button for the toolbar buttons. We should use a dual-button, and have the main button be whatever the default action is.
Attachment #693991 - Flags: review?(squibblyflabbetydoo) → review-
Comment on attachment 693594 [details] [diff] [review]
patch for context menu

Review of attachment 693594 [details] [diff] [review]:
-----------------------------------------------------------------

Unfortunately, this doesn't work for me. The context menu shows a bunch of extra splitters and items that should be hidden.
Attachment #693594 - Flags: review?(squibblyflabbetydoo) → review-
(In reply to Jim Porter (:squib) from comment #47)
> Comment on attachment 693991 [details] [diff] [review]
> patch for toolbarbuttons
> 
> I don't think we should be using a menu-button for the toolbar buttons. We
> should use a dual-button, and have the main button be whatever the default
> action is.

Isn't the menu-button the dual-button? With the patch the main button executes the default action and on the right is the dropdown arrow where the popup offers both possibilities.

If this isn't the correct button, please can you give me an example of one?
Flags: needinfo?(squibblyflabbetydoo)
(In reply to Jim Porter (:squib) from comment #48)
> Comment on attachment 693594 [details] [diff] [review]
> patch for context menu
> 
> Review of attachment 693594 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Unfortunately, this doesn't work for me. The context menu shows a bunch of
> extra splitters and items that should be hidden.

Strange, this patch adds no splitter. Maybe I forgot to say bug 731673 should be applied. This bug is now checked-in. Please can try it again?
Comment on attachment 693594 [details] [diff] [review]
patch for context menu

Whoops, I think I confused myself with Win32. menu-button should be fine.
Attachment #693594 - Flags: review- → review?(squibblyflabbetydoo)
Flags: needinfo?(squibblyflabbetydoo)
Comment on attachment 693991 [details] [diff] [review]
patch for toolbarbuttons

Asking again for r as you wrote menu-button should be okay.
Attachment #693991 - Flags: review- → review?(squibblyflabbetydoo)
(In reply to Jim Porter (:squib) from comment #51)
> patch for context menu

I think consistency among "context menu", "message menu", "app menu" is important.
No need to change "message menu" / "app menu" according to improvement in "context menu"?
MainMenu and AppMenu have already the possibility to choose between inline and attachment.
(In reply to Richard Marti [:Paenglab] from comment #54)
> MainMenu and AppMenu have already the possibility to choose between inline and attachment.

I know it. It is ported to context menu by patch.
My concern is : porting of new mailContext-multiForwardAsAttachment in context menu to MainMenu/AppMenu, and buttons too, for consistncy.
(In reply to WADA from comment #55)
> (In reply to Richard Marti [:Paenglab] from comment #54)
> > MainMenu and AppMenu have already the possibility to choose between inline and attachment.
> 
> I know it. It is ported to context menu by patch.
> My concern is : porting of new mailContext-multiForwardAsAttachment in
> context menu to MainMenu/AppMenu, and buttons too, for consistncy.

Given the long history of vibrant debate but no action on this bug, perhaps we could let whatever improvement the patch here is finally going to bring about land first and then deal with remaining / new problems of ux-consistency after that, probably in another bug.
+1, this looks reasonably complete to me.
Comment on attachment 693594 [details] [diff] [review]
patch for context menu

Review of attachment 693594 [details] [diff] [review]:
-----------------------------------------------------------------

I think this looks good. rs=me with the comments below addressed.

::: mail/base/content/mailWindowOverlay.xul
@@ +683,5 @@
>                label="&contextForward.label;"
>                accesskey="&contextForward.accesskey;"
>                oncommand="MsgForwardMessage(event);"/>
> +    <menu id="mailContext-forwardAsMenu"
> +          label="&forwardAsMenu.label;"

Please create a new string here, and for all the other additions.
Attachment #693594 - Flags: review?(squibblyflabbetydoo) → review+
Comment on attachment 693991 [details] [diff] [review]
patch for toolbarbuttons

Review of attachment 693991 [details] [diff] [review]:
-----------------------------------------------------------------

This should be good. rs=me with the comments below addressed.

::: mail/base/content/mailWindowOverlay.xul
@@ +3007,5 @@
>                     label="&forwardButton.label;"
>                     tooltiptext="&forwardButton.tooltip;"
>                     observes="button_forward"
> +                   command="cmd_forward"
> +                   type="menu-button">

Nit: please move this line to between the id and class attributes, like "button-file" below.

@@ +3010,5 @@
> +                   command="cmd_forward"
> +                   type="menu-button">
> +      <menupopup id="button-ForwardPopup">
> +        <menuitem id="button-ForwardAsInlineMenu"
> +                  label="&forwardAsInline.label;"

I think these should have their own strings too, like with the other patch. You can also ask :bwinton what he thinks about this.

::: mail/base/content/msgHdrViewOverlay.xul
@@ +199,5 @@
> +                             class="toolbarbutton-1 msgHeaderView-button hdrForwardButton"
> +                             type="menu-button">
> +                <menupopup id="hdrForwardDropdown">
> +                  <menuitem id="hdrForwardAsInlineMenu"
> +                            label="&forwardAsInline.label;"

Please use new strings for these too. Mainly, I want to make sure we're consistent with how strings are used in the other toolbar buttons.
Attachment #693991 - Flags: review?(squibblyflabbetydoo) → review+
(In reply to Jim Porter (:squib) from comment #59)
> Comment on attachment 693991 [details] [diff] [review]
> patch for toolbarbuttons
> 
> Review of attachment 693991 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This should be good. rs=me with the comments below addressed.
> 
> ::: mail/base/content/mailWindowOverlay.xul
> @@ +3007,5 @@
> >                     label="&forwardButton.label;"
> >                     tooltiptext="&forwardButton.tooltip;"
> >                     observes="button_forward"
> > +                   command="cmd_forward"
> > +                   type="menu-button">
> 
> Nit: please move this line to between the id and class attributes, like
> "button-file" below.

Done

> @@ +3010,5 @@
> > +                   command="cmd_forward"
> > +                   type="menu-button">
> > +      <menupopup id="button-ForwardPopup">
> > +        <menuitem id="button-ForwardAsInlineMenu"
> > +                  label="&forwardAsInline.label;"
> 
> I think these should have their own strings too, like with the other patch.
> You can also ask :bwinton what he thinks about this.
> 
> ::: mail/base/content/msgHdrViewOverlay.xul
> @@ +199,5 @@
> > +                             class="toolbarbutton-1 msgHeaderView-button hdrForwardButton"
> > +                             type="menu-button">
> > +                <menupopup id="hdrForwardDropdown">
> > +                  <menuitem id="hdrForwardAsInlineMenu"
> > +                            label="&forwardAsInline.label;"
> 
> Please use new strings for these too. Mainly, I want to make sure we're
> consistent with how strings are used in the other toolbar buttons.

Hm, when I'm checking the other toolbabuttons I'm seeing button-getmsg, is using getAllNewMsgCmd.label. Or button-goback and button-goforward are using goBackCmd.label and goForwardCmd.label. Also button-print, button-mark and button-tag are using such "shared" labels. Should I still use new labels?
(In reply to Jim Porter (:squib) from comment #58)
> Comment on attachment 693594 [details] [diff] [review]
> patch for context menu
> 
> Review of attachment 693594 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I think this looks good. rs=me with the comments below addressed.
> 
> ::: mail/base/content/mailWindowOverlay.xul
> @@ +683,5 @@
> >                label="&contextForward.label;"
> >                accesskey="&contextForward.accesskey;"
> >                oncommand="MsgForwardMessage(event);"/>
> > +    <menu id="mailContext-forwardAsMenu"
> > +          label="&forwardAsMenu.label;"
> 
> Please create a new string here, and for all the other additions.

All done, carrying over r+
Attachment #693594 - Attachment is obsolete: true
Attachment #734529 - Flags: review+
Forgot to set NEEDINFO for comment 60
Flags: needinfo?(squibblyflabbetydoo)
Attached patch patch for check-in. Part 2 (obsolete) — Splinter Review
(In reply to Jim Porter (:squib) from comment #59)
> Comment on attachment 693991 [details] [diff] [review]
> patch for toolbarbuttons
> 
> Review of attachment 693991 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This should be good. rs=me with the comments below addressed.
> 
> ::: mail/base/content/mailWindowOverlay.xul
> @@ +3007,5 @@
> >                     label="&forwardButton.label;"
> >                     tooltiptext="&forwardButton.tooltip;"
> >                     observes="button_forward"
> > +                   command="cmd_forward"
> > +                   type="menu-button">
> 
> Nit: please move this line to between the id and class attributes, like
> "button-file" below.

Done

> @@ +3010,5 @@
> > +                   command="cmd_forward"
> > +                   type="menu-button">
> > +      <menupopup id="button-ForwardPopup">
> > +        <menuitem id="button-ForwardAsInlineMenu"
> > +                  label="&forwardAsInline.label;"
> 
> I think these should have their own strings too, like with the other patch.
> You can also ask :bwinton what he thinks about this.
> 
> ::: mail/base/content/msgHdrViewOverlay.xul
> @@ +199,5 @@
> > +                             class="toolbarbutton-1 msgHeaderView-button hdrForwardButton"
> > +                             type="menu-button">
> > +                <menupopup id="hdrForwardDropdown">
> > +                  <menuitem id="hdrForwardAsInlineMenu"
> > +                            label="&forwardAsInline.label;"
> 
> Please use new strings for these too. Mainly, I want to make sure we're
> consistent with how strings are used in the other toolbar buttons.

Added new strings:

+<!-- Toolbar Button Popup -->
+<!ENTITY buttonMenuForwardAsInline.label "Forward As Inline">
+<!ENTITY buttonMenuForwardAsAttachment.label "Forward As Attachment">

Blake, do you want a ui-r? Or is the naming like this okay?
Attachment #693991 - Attachment is obsolete: true
Attachment #735083 - Flags: review+
Flags: needinfo?(bwinton)
To be consistent, the string for buttonMenuForwardAsInline.label should read "Forward Inline", without the "As"...
Posting to clear my needinfo request, since I discussed this on IRC.
Flags: needinfo?(squibblyflabbetydoo)
(In reply to Onno Ekker from comment #64)
> To be consistent, the string for buttonMenuForwardAsInline.label should read
> "Forward Inline", without the "As"...

+1. It should be "Forward Inline", because "Forward As Inline" is gramatically odd. (Unfortunately, that oddness is already in the message menu, but we shouldn't repeat that here while we're adding new strings anyway.)

Otherwise, I'm really looking forward to this patch!!! :)
(In reply to Thomas D. from comment #66)
> +<!ENTITY buttonMenuForwardAsInline.label "Forward As Inline">
> It should be "Forward Inline", because "Forward As Inline" is gramatically odd.

And the entity name should be changed accordingly, so that we have:
+<!ENTITY buttonMenuForwardInline.label "Forward Inline">
...plus respective changes where that new string is used.
Depends on: 231660
(In reply to Richard Marti [:Paenglab] from comment #63)
> Added new strings:
> 
> +<!-- Toolbar Button Popup -->
> +<!ENTITY buttonMenuForwardAsInline.label "Forward As Inline">
> +<!ENTITY buttonMenuForwardAsAttachment.label "Forward As Attachment">
> 
> Blake, do you want a ui-r? Or is the naming like this okay?

Sorry about the delay.  Naming the menu options that way seems good to me, and no less grammatically odd than "Forward Inline/Forward Attachment".  So, that part is fine.  But…

Since the menu has "Forward" and "Forward As", and the context menu has "Forward" and "Forward As", and we have a "Reply" and "Smart Reply (dual-button)", I really think we should have the default button in the message header be "Forward", but add a "Forward As" dual-button, with dropdowns that say "Inline" and "Attachment" that people can add to the header if they want.

(And to forestall Thomas D's disagreement: Yes, I understand that you want the dual-button there by default, but I don't believe that most people understand which type of forwarding they want, much less change their minds on which one they want on a per-message basis, and so the dual-button should not be the default, in my opinion.)

So, I guess that's a ui-r-, but I promise to ui-review the next patch as soon as you ping me on irc.

Thanks,
Blake.
Flags: needinfo?(bwinton)
(In reply to Blake Winton (:bwinton) from comment #68)
> (In reply to Richard Marti [:Paenglab] from comment #63)
> > Added new strings:
> > 
> > +<!-- Toolbar Button Popup -->
> > +<!ENTITY buttonMenuForwardAsInline.label "Forward As Inline">
> > +<!ENTITY buttonMenuForwardAsAttachment.label "Forward As Attachment">
> > 
> > Blake, do you want a ui-r? Or is the naming like this okay?
> 
> Sorry about the delay.  Naming the menu options that way seems good to me,
> and no less grammatically odd than "Forward Inline/Forward Attachment".  So,
> that part is fine.  But…

Blake, I think there was a misunderstanding of what Onno and I proposed in terms of strings. This is our proposal for the msg header button (which unfortunately you haven't evaluated yet):

[Forward][v]
+---------------------+
|Forward Inline       |
|Forward As Attachment|
+---------------------+

Unless proven otherwise, I think that's grammatically correct, and much less odd than having "Forward *As* Inline" + "Forward As Attachment.
What do you think?
Flags: needinfo?(bwinton)
All the menu options say "Forward As >> Inline/Attachment".  Why should we differ from them for the button?
Flags: needinfo?(bwinton)
For comparison, SeaMonkey's "Forward" button just says "Inline" vs. "Attachment" (thus, without "As"). I agree that "Forward As Inline" sounds a bit weird, given that "Inline" isn't a noun. It was only labelled like that in the menu given that "Forward As" is the menuitem name already.
I'd agree for the case we have full sentences the proposal in comment 69 is good. "Forward As >> stuff" is just something we used because nobody has come up with anything better in that non-sentence case.
(In reply to Blake Winton (:bwinton) from comment #68)
> (dual-button)", I really think we should have the default button in the
> message header be "Forward", but add a "Forward As" dual-button, with
> dropdowns that say "Inline" and "Attachment" that people can add to the
> header if they want.

Well, if the button itself is labelled "Forward As" then either proposal is moot anyway given that this would mirror the menu situation (I've missed that Blake is asking for separate "simple" and dual-function buttons; I haven't seen any confusion about the single "Forward" button from the SeaMonkey users though, thus there doesn't seem to be much of an ambiguity).
Attached patch Patch part 2 (obsolete) — Splinter Review
On main toolbar there is still the dual button because the button isn't by default in this bar. So if you customize your toolbar, then you're probably a more advanced user, and so having the dropdown-button makes more sense.

On message header toolbar I've added a second button called "Forward As" in Customize window to distinguish the two buttons. Placed on the toolbar it is still labeled "Forward".

I changed the "As" in the popups to a lowercase "as" to make it a little bit less important. Is this okay?
Attachment #735083 - Attachment is obsolete: true
Attachment #748978 - Flags: ui-review?(bwinton)
Attachment #748978 - Flags: review?(bwinton)
Comment on attachment 748978 [details] [diff] [review]
Patch part 2

(In reply to Richard Marti [:Paenglab] from comment #74)
> On main toolbar there is still the dual button because the button isn't by
> default in this bar. So if you customize your toolbar, then you're probably
> a more advanced user, and so having the dropdown-button makes more sense.

Agreed.  (Although I noticed that we have two "Forward" buttons in the main toolbar customization now…  https://dl.dropbox.com/s/g1x6mjhi1nivaer/DualForward.png )

> On message header toolbar I've added a second button called "Forward As" in
> Customize window to distinguish the two buttons. Placed on the toolbar it is
> still labeled "Forward".

Agreed.

> I changed the "As" in the popups to a lowercase "as" to make it a little bit
> less important. Is this okay?

All of our other buttons are all capitalized, so I think we need to go with a capital "A".  But, playing around with it it felt a little odd, so I think if we're going to keep "Forward As" in the labels of the drop-down menu items, then we should probably have them be "Forward Inline" and "Forward As Attachment".

So, ui-r=me with that changed, and the two forward buttons merged/fixed.  ;)

And the code seems fine, so I'll say r=me, too.

Thanks,
Blake.
Attachment #748978 - Flags: ui-review?(bwinton)
Attachment #748978 - Flags: ui-review+
Attachment #748978 - Flags: review?(bwinton)
Attachment #748978 - Flags: review+
Attached patch patch for check-in. Part 2 (obsolete) — Splinter Review
(In reply to Blake Winton (:bwinton) from comment #75)
> Comment on attachment 748978 [details] [diff] [review]
> Patch part 2
> 
> Agreed.  (Although I noticed that we have two "Forward" buttons in the main
> toolbar customization now… 
> https://dl.dropbox.com/s/g1x6mjhi1nivaer/DualForward.png )

This is bug 600305

> All of our other buttons are all capitalized, so I think we need to go with
> a capital "A".  But, playing around with it it felt a little odd, so I think
> if we're going to keep "Forward As" in the labels of the drop-down menu
> items, then we should probably have them be "Forward Inline" and "Forward As
> Attachment".

Changed to this.
Attachment #748978 - Attachment is obsolete: true
Attachment #749152 - Flags: ui-review+
Attachment #749152 - Flags: review+
Keywords: checkin-needed
(In reply to Blake Winton (:bwinton) from comment #75)
> All of our other buttons are all capitalized, so I think we need to go with
> a capital "A".  But, playing around with it it felt a little odd, so I think
> if we're going to keep "Forward As" in the labels of the drop-down menu
> items, then we should probably have them be "Forward Inline" and "Forward As
> Attachment".

Thanks for letting language sanity prevail :)

Speaking of things language, here's another little nit:

> <!ENTITY replyListButton.tooltip "Reply to mailing list">
> <!ENTITY forwardButton.tooltip "Forward selected message">
>+<!ENTITY forwardAsInline.tooltip "Forward selected message Inline">
>+<!ENTITY forwardAsAttachment.tooltip "Forward selected message as Attachment">

Compared to all other tooltips around them, these two deviate because they use internal capitalization. However, the current logic is that the tooltips should be natural language with default capitalization, which is lowercase in English.

So as a minimal fix, they should be changed to:

+<!ENTITY forwardAsInline.tooltip "Forward selected message inline">
+<!ENTITY forwardAsAttachment.tooltip "Forward selected message as attachment">

I think this one is required for consistency, so I'm expecting Blake's thumbs up here. Blake?

While we are here, tooltips should be more informative than the command labels, so I was thinking if we could add two words to the "Forward Inline" tooltip to make it a little more descriptive (while even catering for the friends of "as", but in a grammatically correct way...):

+<!ENTITY forwardAsInline.tooltip "Forward selected message as inline text">
+<!ENTITY forwardAsAttachment.tooltip "Forward selected message as attachment">

Imho it's a little easier to understand from that tooltip what "Forward Inline" actually means, instead of just repeating the button label without adding informational value.

Blake, what do you think?
Flags: needinfo?(bwinton)
Clearing checkin-needed until we have Blake's answer.
Keywords: checkin-needed
(In reply to Thomas D. from comment #77)
> Speaking of things language, here's another little nit:
> >+<!ENTITY forwardAsInline.tooltip "Forward selected message Inline">
> >+<!ENTITY forwardAsAttachment.tooltip "Forward selected message as Attachment">
> So as a minimal fix, they should be changed to:
> +<!ENTITY forwardAsInline.tooltip "Forward selected message inline">
> +<!ENTITY forwardAsAttachment.tooltip "Forward selected message as
> attachment">

Good catch.

> While we are here, tooltips should be more informative than the command
> labels, so I was thinking if we could add two words to the "Forward Inline"
> tooltip to make it a little more descriptive (while even catering for the
> friends of "as", but in a grammatically correct way...):
> 
> +<!ENTITY forwardAsInline.tooltip "Forward selected message as inline text">
> +<!ENTITY forwardAsAttachment.tooltip "Forward selected message as
> attachment">
> Blake, what do you think?

I like "Forward selected message as inline text", but if we're making that kind of change the other one should be "Forward selected message as an attachment"…

Thanks,
Blake.
Flags: needinfo?(bwinton)
(In reply to Blake Winton (:bwinton) from comment #79)
> (In reply to Thomas D. from comment #77)
> > Speaking of things language, here's another little nit:
> > >+<!ENTITY forwardAsInline.tooltip "Forward selected message Inline">
> > >+<!ENTITY forwardAsAttachment.tooltip "Forward selected message as Attachment">
> > So as a minimal fix, they should be changed to:
> > +<!ENTITY forwardAsInline.tooltip "Forward selected message inline">
> > +<!ENTITY forwardAsAttachment.tooltip "Forward selected message as
> > attachment">
> 
> Good catch.
> 
> > While we are here, tooltips should be more informative than the command
> > labels, so I was thinking if we could add two words to the "Forward Inline"
> > tooltip to make it a little more descriptive (while even catering for the
> > friends of "as", but in a grammatically correct way...):
> > 
> > +<!ENTITY forwardAsInline.tooltip "Forward selected message as inline text">
> > +<!ENTITY forwardAsAttachment.tooltip "Forward selected message as
> > attachment">
> > Blake, what do you think?
> 
> I like "Forward selected message as inline text", but if we're making that
> kind of change the other one should be "Forward selected message as an
> attachment"…

Good catch ;) Thanks.

So these are the new tooltips for the patch, per Blake's recommendation:

+<!ENTITY forwardAsInline.tooltip "Forward selected message as inline text">
+<!ENTITY forwardAsAttachment.tooltip "Forward selected message as an attachment">

Fwiw, just in case somebody wonders, my language intuition says that we do *not* want to say "...as *an* inline text", so the above sounds just right :)
(In reply to Blake Winton (:bwinton) from comment #79)
> 
> I like "Forward selected message as inline text", but if we're making that
> kind of change the other one should be "Forward selected message as an
> attachment"…

Done
Attachment #749152 - Attachment is obsolete: true
Attachment #749258 - Flags: ui-review+
Attachment #749258 - Flags: review+
Keywords: checkin-needed
https://hg.mozilla.org/comm-central/rev/b6566a522eaa
https://hg.mozilla.org/comm-central/rev/ae206f9f23c9
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 24.0
Hmm.. I can hardly wait till the next Daily to test this (and see what I have to do to make my Forward extension work with the changes). Maybe I should try to build Thunderbird myself once more :-)
A small thing I noticed: The tooltip for the header button menuitems say "Forward selected message...". I think this should be "Forward this message...", just as the tooltip on the junk and delete menuitems, so with "this" instead of "selected".

And the tooltip for the mail toolbar menuitem is better if it uses plural form when more than one message is selected.
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #84)
> A small thing I noticed: The tooltip for the header button menuitems say
> "Forward selected message...". I think this should be "Forward this
> message...", just as the tooltip on the junk and delete menuitems, so with
> "this" instead of "selected".

I agree it should follow the form.  Also  "Forward selected message as....." seems long.  (I know the word count would be the same but the syllables are more. The briefer the better).
It needs to be said that I now think its right that the FORWARD options are now available on both the context menu and the UI message toolbar.  I for one regularly have times where forwarding is required with the method often dictated to by the scenario/email; there is no one or other 'main' method (either INLINE or as ATTACHMENT) - so its a lot better that the 'assumption' that people dont need it because "its not the norm" is now no longer taken.

However, regarding the additional button ('FORDWARD V') on the Message Toolbar I have to say that I had to be told about its existence before I was able to add it.  Given that the original existing 'FORWARD' button was already there I had no reason to think there was an alternative choice of button (and therefore didnt look for it).  And given that the new alternative still defaults and acts the same as the original (if the dropdown menu off the isnt implemented) then surely this button provides the same function as the original and therefore makes the original one redundant.  So, why make a NEW button that part provides existing functionality of an existing button, plus new functionality that is useful, and yet keep it hidden for users to discover by chance?

IMO the new button should REPLACE COMPLETELY the existing 'FORWARD' button (making it now the new 'FORWARD V' with options.  Also, given that the new button does exactly the same as the original be default, what valid reason can there be that the old existing one with limited functionality still remains?
jimimaseye, this bug is closed. Please file any follow-up requests in a new report. Thanks.
You need to log in before you can comment on or make changes to this bug.