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

RESOLVED FIXED in Thunderbird 3.0b4

Status

P1
normal
RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: stef, Assigned: dmose)

Tracking

(Blocks: 2 bugs)

unspecified
Thunderbird 3.0b4
Dependency tree / graph
Bug Flags:
blocking-thunderbird3 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [no l10n impact])

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

10 years ago
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

Updated

10 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 1

10 years ago
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.
(Reporter)

Comment 2

10 years ago
Created attachment 385076 [details]
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).
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?
(Reporter)

Updated

10 years ago
Summary: Remove "more" indicator from mail header view → mail header view: more button has problems and should be improved in some way
(Reporter)

Updated

10 years ago
(Assignee)

Comment 4

10 years ago
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.
Assignee: nobody → dmose
Target Milestone: --- → Thunderbird 3.0b4
(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*
(Reporter)

Updated

10 years ago
Flags: blocking-thunderbird3?
(Assignee)

Updated

10 years ago
Flags: blocking-thunderbird3? → blocking-thunderbird3+

Updated

10 years ago
Duplicate of this bug: 500638
Dan, could you please give me an estimate on whether this bug would have an l10n impact or not?
(Assignee)

Comment 8

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

Updated

9 years ago
Whiteboard: [has l10n impact]

Updated

9 years ago
Blocks: 513553
Duplicate of this bug: 513587
(Assignee)

Updated

9 years ago
Blocks: 456814
(Assignee)

Updated

9 years ago
Priority: -- → P1
(Assignee)

Comment 10

9 years ago
Created attachment 397807 [details] [diff] [review]
patch, v1 (WIP)

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

Updated

9 years ago
Whiteboard: [has l10n impact] → [has l10n impact][WIP patch attached]
(Assignee)

Updated

9 years ago
Blocks: 471312
(Assignee)

Updated

9 years ago
Whiteboard: [has l10n impact][WIP patch attached] → [has l10n impact] [WIP patch attached; needs iteration]
Dan, your WIP patch does not touch mail/locales. Can we therefore assume that this bug does not have any kind of l10n impact?
Status: NEW → ASSIGNED
(Assignee)

Comment 12

9 years ago
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.

Updated

9 years ago
Whiteboard: [has l10n impact] [WIP patch attached; needs iteration] → [has l10n impact][WIP patch attached; needs iteration]
(Assignee)

Updated

9 years ago
No longer blocks: 469878
(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.
Whiteboard: [has l10n impact][WIP patch attached; needs iteration] → [no l10n impact][WIP patch attached; needs iteration]
(Assignee)

Comment 14

9 years ago
Created attachment 399969 [details] [diff] [review]
simpler more, v1
Attachment #397807 - Attachment is obsolete: true
Attachment #399969 - Flags: ui-review?(clarkbw)
(Assignee)

Comment 15

9 years ago
Created attachment 399970 [details] [diff] [review]
simpler more, v1a

This time for sure!
Attachment #399969 - Attachment is obsolete: true
Attachment #399970 - Flags: ui-review?
Attachment #399969 - Flags: ui-review?(clarkbw)
(Assignee)

Updated

9 years ago
Attachment #399970 - Flags: ui-review? → ui-review?(clarkbw)
(Assignee)

Comment 16

9 years ago
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.
(Assignee)

Updated

9 years ago
Whiteboard: [no l10n impact][WIP patch attached; needs iteration] → [no l10n impact][patch attached; needs UI-review]
(Assignee)

Updated

9 years ago
Attachment #399970 - Flags: review?(philringnalda)
(Assignee)

Comment 17

9 years ago
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 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.
Attachment #399970 - Flags: ui-review?(clarkbw) → ui-review+
(Assignee)

Updated

9 years ago
Whiteboard: [no l10n impact][patch attached; needs UI-review] → [no l10n impact][patch attached; needs review]
Whiteboard: [no l10n impact][patch attached; needs review] → [no l10n impact][patch attached; needs review 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 "someone@somewhere.org, Some Very Very Very Very Long Name <someoneelse@somewhere.org>" (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.
Attachment #399970 - Flags: review?(philringnalda) → review+
http://hg.mozilla.org/comm-central/rev/c49f355aed4d
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: [no l10n impact][patch attached; needs review philor] → [no l10n impact]

Comment 21

9 years ago
Can we get a screenshot of the finished result?

Comment 22

9 years ago
Created attachment 400275 [details]
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 "someone@somewhere.org, Some Very Very
> Very Very Long Name <someoneelse@somewhere.org>" (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

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

Please disregard, dmose's CompactHeader extension was still active.
Attachment #400275 - Attachment is obsolete: true

Comment 24

9 years ago
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

9 years ago
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)
(Assignee)

Comment 26

9 years ago
(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

9 years ago
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?
You need to log in before you can comment on or make changes to this bug.