499989 - mail header view: more button has problems and should be improved in some way

Status: RESOLVED FIXED

(Thunderbird :: Message Reader UI, defect, P1)

Description

[Stefan Plewako [:stef]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9.1) Gecko/20090616 Firefox/3.5
Build Identifier: 

Please remove "more" indicator entirely - it is buggy and really bad solution for too long headers.

Reproducible: Always

Comment 1

[Stefan Plewako [:stef]]

Bug 480623 was fixed but the "more" indicator is still present in recent nightlies.

I don't know general plan for header view in tb3.0 but at least for now, it would much better to use even simple tb2.x like buttons (and we have enough place for them) to collapse whole header pane or too long headers (per each).

If compact message header view will be back one day, I'm sure that it will contain own solution for the too long headers problem.

Comment 2

[Stefan Plewako [:stef]]

Attachment: Screenshot (Shredder 3b3pre, pl, 20090624)

In the latest nightlies we can now observe even 3 (or maybe more?) "more" indicators (in pl it is translated as "szczegóły").

Additionally this "more" is inconsistent with references and other actions  indicators (gray triangles).

Comment 3

[Thomas D. (:thomas8)]

The current summary of this bug ("Remove "more" indicator from mail header view") is misleading in that it might be misunderstood as a request to remove the feature associated with the "more" button when there are many addresses e.g. in to or cc header. I don't think TB devs will be suicidal enough to actually remove that specific "collapse/expand" functionality entirely, as this would cause severe usability issues which may lead to user turmoil.

As per comment #1, this bug does not actually call for the removal of the feature, but seeks to improve it (e.g. by using TB2-style +/- twisties - indeed, those did the job pretty well!!!) This should reflect in the summary.

Suggested improved summary for this bug:

mail header view: More-button has problems and should be improved in some way (expand collapsed list of many addresses e.g. in to or cc headers)

Another problem with the more-button is that in the current nightly, there is no way to re-collapse the list of addresses after the user has expanded it using the more-button. Dan or someone else in charge, does this need a separate bug?

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Yeah, that summary works better; thanks.

(In reply to comment #3)
>
> Another problem with the more-button is that in the current nightly, there is
> no way to re-collapse the list of addresses after the user has expanded it
> using the more-button. Dan or someone else in charge, does this need a separate
> bug?

My recollection is that this was an intentional part of the design; perhaps clarkbw can confirm or deny that.

Thomas, I've just added privs to your account so that you can confirm and edit bugs yourself in the future.

Comment 5

[Thomas D. (:thomas8)]

(In reply to comment #4)
> Yeah, that summary works better; thanks.
It's just that I don't like suicidal summaries... ;-)

> > Another problem with the more-button is that in the current nightly, there is
> > no way to re-collapse the list of addresses after the user has expanded it
> > using the more-button. Dan or someone else in charge, does this need a separate
> > bug?
>
> My recollection is that this was an intentional part of the design;

Let's hope not. I don't think users would like that at all, and the use case is obvious in the feature: Why are we offering collapsed headers at all? Is it perhaps because they'd waste too much screen real estate? That still holds true /after/ user happened to expand the header to check for something in there and then wants to continue working with the body part of that same mail without obstrusive long headers in the way. If there's no "collapse" button, only workaround would be to select another message and then return to first message - NO, we wouldn't want that...
 
> Thomas, I've just added privs to your account so that you can confirm and edit
> bugs yourself in the future.

Thank you! I'm delighted and I'll appreciate that very much. I must have worked hard to get there ;-) Or is it on occasion of my 100th nag posting? *eg*

Comment 7

[Simon Paquet [:sipaq]]

Dan, could you please give me an estimate on whether this bug would have an l10n impact or not?

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

Not yet clear, I think there's about a 50/50 chance of impact.  So perhaps it's best to assume there is.

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: patch, v1 (WIP)

This is a work-in-progress patch.  Posting here as a checkpoint; not yet useful for testing or review.

Comment 11

[Simon Paquet [:sipaq]]

Dan, your WIP patch does not touch mail/locales. Can we therefore assume that this bug does not have any kind of l10n impact?

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

No.  If we get lucky, this will end up switching from (more) to (and 3 more).  It's not clear that that will actually make it, but it might.

Comment 13

[Mark Banner (:standard8)]

(In reply to comment #12)
> No.  If we get lucky, this will end up switching from (more) to (and 3 more). 
> It's not clear that that will actually make it, but it might.

It hasn't made it so switching to no-l10n impact and we can work out how/when later.

Comment 14

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: simpler more, v1

Comment 15

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: simpler more, v1a

This time for sure!

Comment 16

[Dan Mosedale (:dmosedale, :dmose)]

After a bunch of fighting with the code and working out a reduce test case encapsulating the problems I was seeing, NeilAway was kind enough to help me work through what was going on.  The ultimate conclusion was that neither the XUL nor the XHTML box models really support the original design.  It's probably actually possible to implement by essentially doing pieces of the box model layout by hand in JavaScript.  Good times!

The message header code, however is already far too complex, and adding even more complexity on top of that is going to making it even more painful to maintain than it is today, which isn't something we can afford to do.

So, the simpler-more patch implements a similar UX, but it deals differently with overflow: it _always_ renders the first two email addresses and then a (more) widget.  If the (more) widget overflows the frame, the user needs to resize in order to reach it.

Comment 17

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 399970 [details] [diff] [review]
simpler more, v1a

philor: I managed to avoid adding more complexity to the caching code by tying the cache size to the maximum number of addresses before the (more).

Also included in the patch is an offering: I sacrificed the useShortView code to the gods of maintainability since it wasn't actually being used.

Comment 18

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 399970 [details] [diff] [review]
simpler more, v1a

nice!  This is much more reliable than before.  I think we can make some future tweaks to improve "performance" of the number of items shown.

Comment 19

[Phil Ringnalda (:philor)]

Comment on attachment 399970 [details] [diff] [review]
simpler more, v1a

Ouch. My midnight comment reading failed to grasp that you meant "if someone using the vertical layout gets mail from "[e-mail], Some Very Very Very Very Long Name <[e-mail]>" (which was actually the very first testcase I tried it on), that they would have to either resize their window or change layouts to even see that there is a more indicator.

However, I really don't have any better ideas, so pushing the pain out to the edges is probably the best we can do. I'll land a version with the trailing whitespace removed, and the comments using the words you meant to use, in a little bit.

Comment 20

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/comm-central/rev/c49f355aed4d

Comment 21

[Worcester12345]

Can we get a screenshot of the finished result?

Comment 22

[Thomas Stache]

Attachment: Screenshot of problem with long email address

(In reply to comment #19)
> (From update of attachment 399970 [details] [diff] [review])
> Ouch. My midnight comment reading failed to grasp that you meant "if someone
> using the vertical layout gets mail from "[e-mail], Some Very Very
> Very Very Long Name <[e-mail]>" (which was actually the very
> first testcase I tried it on), that they would have to either resize their
> window or change layouts to even see that there is a more indicator.

It's actually worse than that: not the "more" button get's squeezed out, but the action button chrome get's pushed all over the place, e.g. the Lightning sidebar. Is there really no solution using box reflow, which Gecko actually does very well?

Comment 23

[Thomas Stache]

Comment on attachment 400275 [details]
Screenshot of problem with long email address

Please disregard, dmose's CompactHeader extension was still active.

Comment 24

[Joachim Herb]

I noticed (too late) that the useShortView was removed. This was useful for the CompactHeader add-on (https://addons.mozilla.org/thunderbird/addon/13564). Any chance to get it back?

Comment 25

[Joachim Herb]

Another question: What would be necessary to add this functionality to other header fields, especially the subject. At the moment the subject is truncated at the end of the first line. The way which was chosen in bug 466025 seems to have problems (see bug 466025 comment 92)

Comment 26

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #24)
> I noticed (too late) that the useShortView was removed. This was useful for the
> CompactHeader add-on (https://addons.mozilla.org/thunderbird/addon/13564). Any
> chance to get it back?

I removed it because that code needs to be simplified considerably in order to get to the point of maintainability.  Is it hard to reimplement in an extension?  If so, what would make it easier?

(In reply to comment #25)
> Another question: What would be necessary to add this functionality to other
> header fields, especially the subject. At the moment the subject is truncated
> at the end of the first line. The way which was chosen in bug 466025 seems to
> have problems (see bug 466025 comment 92)

First we need to make it possible to wrap the subject at all, as per bug 489609.  It's possible that it would then make sense to sometimes truncate using (more); I'd suggest staying tuned to that bug.  (Or, for bonus points, put together a patch :-).

Comment 27

[exmerlin]

Why was this bug closed as fixed? As far as I can see the 'more' button still has the problems mentioned above. Since I upgraded to Thunderbird 3 I only see a single entry of the 'to' and 'cc' headers followed by 'more'. This is very annoying to me. The original solution in Thunderbird 2 obviously was a lot more user friendly. Can we hope to get it back?