Closed Bug 480623 Opened 15 years ago Closed 15 years ago

move compact message header view to an extension

Categories

(Thunderbird :: Message Reader UI, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b3

People

(Reporter: dmosedale, Assigned: dmosedale)

References

Details

(Keywords: dev-doc-needed, Whiteboard: see comment 44-46, 55)

Attachments

(5 files, 3 obsolete files)

Note that I've explicitly started off only CCing a few folks on this bug, because I think the opinions of the folks who have actually been doing coding and UX work here should carry the most weight.

Because there's a lot of work that still needs attention from the core developers before we can ship Thunderbird 3, thunderbird-drivers have been thinking hard about how we can ship the best possible product in the shortest possible time.  The attention of the core development team is already spread far too thin, and we're concerned about shipping an app that tries to do too many things, at the cost of all of them having too many bugs and being not polished enough.

Bryan and I have been really encouraged by the good headerUI work in bug 466025, which made quick progress in large part because it's gated neither by the slower speed of the Thunderbird core development process nor by Bryan's and my limited time.  In part because of this, but also because the feedback on the compact header view was different than anticipated, we think that the right path here is likely to be removing the compact message header view from core code entirely, and freeing it up to evolve quickly as an extension.

This would also have a couple of advantages for the compact view itself:

1) people who are interested in working on it would have a single place to do that work.

2) contributors would no longer be expecting the core developers to do the heavy lifting, which would provide extra motivation to step up and help with the extension.

Thoughts?
Flags: blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0b3
The big question I have is whether it's easy for the addon to bring in all of the stuff that exists in the existing compact view, like the bindings that have the addressbook-hooking-in stuff,   Presuming doing the ripping out and building the extension points isn't horrible, this sounds like a good idea.

(btw: i think we'd want several add-ons -- maybe one that's like the existing one, and another one based on ovidiu's work, to show that variety is the spice of add-on life ;-).
Following only some bugs about this new header layout and seeing there are lot of "challenges", not only which buttons should do what or compact/opened header etc .. my impression is there are too much ideas generated already, too many expections. 
Beside technical issues as pointed to by davida, how should an extension solve all of that? Also different extensions will NOT be able to do that.

The first question (FMPOV): what are the goals for TB3 message header?
Just to name a few ..
- move function calling into the message/header area and unload the normal toolbar
- have a compact/opened header
- show names and mail addresses [1]
- enable copy all/selected addresses for pasting
- more & more

Did I missed a agreed-upon-list?

Before starting over with an extension, I would like to see some agreements on this

Günter

[1] will post two PNG's showing that "creative" presentation of header layout and names & email-addresses. These also include the TB2 and the just upcoming "Postbox" layout. PB is very limited, but that's clearer to me ...
(In reply to comment #0)
> This would also have a couple of advantages for the compact view itself:
> 
> 1) people who are interested in working on it would have a single place to do
> that work.

Can there be a more single place than core? An extension is (mostly) a single place for *one* person to work on it, and nothing prevents an interested party from submitting patches. Given the amount of work to get it to look ok on all platform has been significant, extension authors aren't that likely do it for more than their pet platform.
 
> 2) contributors would no longer be expecting the core developers to do the
> heavy lifting, which would provide extra motivation to step up and help with
> the extension.

I'm not at all keen on moving that functionality out to extensions, it's core functionality especially for wide screen laptops.

It's not like the compact header view has been a lot of work to maintain (it hadn't changed much since ever before this release). If the feedback on current work is bad, just revert to the tb2 version of the compact header view. It's having the buttons in the header that keeps that back? Such a large part of the new problems and compromises are due to the buttons being in there, it's questionable if they should at all. I wonder how they would fit in in some kind of slick toolbar thing above/beneath the current header pane would look/work...
OS: Mac OS X → All
Hardware: x86 → All
I'll respond to the comments here soon; just setting ASSIGNED to indicate that I'm taking responsibility for sorting out this bug, not to indicate that any specific decision has been made.
Status: NEW → ASSIGNED
Whiteboard: [b3ux]
Whiteboard: [b3ux] → [b3ux] [m2]
Relegating this to an extension IMO seems to say that folks who don't like the current display are "edge cases", or at least not the target of the current development thrust.

Certainly even intermediate users began asking for userChrome.css to modify the display. Which brings up another question: Why isn't there easier access to customization via userChrome (maybe even in a UI) as an alternative to extensions in general. Just a thought, and of course, not this bug.
Whiteboard: [b3ux] [m2] → [b3ux][m2]
2c worth from a user that's been tracking the nightlies.

I've been using TB3 with this view for long enough now, that I'd be upset if it got reverted to whatever it was before (my memory of those times has long gone).

What I love about it is the consistency with FF3 for adding a contact in the same way that you add a bookmark in FF3.

While it may be tempting to push out to an extension, I'd argue that the core product should be up with the times.  I really don't think TB3 should have the old UI, when, since TB2, so much has changed in the world of web based mail UIs.

It's no longer Outlook (which I do suffer at work) that TB3 has to compete with, but instead the web UIs.

Perhaps there should instead be a 'retro' extension, for people who want the TB2 version :)
I was hoping to get a chance to drive this discussion over the past week, but other events interceded.
Whiteboard: [b3ux][m2] → [b3ux][m4]
Whiteboard: [b3ux][m4] → [b3ux][m5]
The new header is even taller than the one in Tb2 (i.e. it's huge). Removing the compact header view is therefore a big mistake IMO.

This is primary UI! If there aren't enough developers, then push back the release of Tb3. Please don't sacrifice the quality for some artificial due date.

--> WONTFIX (please)
Whiteboard: [b3ux][m5] → [b3ux][m6]
I'm going to start by responding to a few comments individually:

(In reply to comment #1)
> The big question I have is whether it's easy for the addon to bring in all of
> the stuff that exists in the existing compact view, like the bindings that have
> the addressbook-hooking-in stuff,   Presuming doing the ripping out and
> building the extension points isn't horrible, this sounds like a good idea.

Agreed that it's really important that this actually be doable in an extension.
To that end, I've gotten that work started.  In a local tree, I have extracted the compact header from the core and have it up and running in an extension.

> (btw: i think we'd want several add-ons -- maybe one that's like the existing
> one, and another one based on ovidiu's work, to show that variety is the spice
> of add-on life ;-).

I very much hope people will be sufficiently motivated to make their own header view extensions.  The work I think that the core developers can afford to do right now is to extract what's currently in the tree into an extension, as I've done, and put it up on mozdev.org.  

(In reply to comment #2)
> Following only some bugs about this new header layout and seeing there are lot
> of "challenges", not only which buttons should do what or compact/opened header
> etc .. my impression is there are too much ideas generated already, too many
> expections. 

Absolutely.  The intent of removing the compact header from the core developers' plate is to provide more bandwidth to sort out the remaining issues in the expanded header.

> Beside technical issues as pointed to by davida, how should an extension solve
> all of that? Also different extensions will NOT be able to do that.

I have code that suggests otherwise.  :-)  Doing that hacking has turned out to be very valuable, because it's causing me to add necessary extension points.

> The first question (FMPOV): what are the goals for TB3 message header?
> 
> [...]
>
> Before starting over with an extension, I would like to see some agreements on
> this

While I'm not convinced that answering this question should block us from moving forward with this featurectomy, I do agree that it seems like a worthwhile discussion to have.  I'm going to let clarkbw take a crack at it, as his thinking about these issues is crisper than mine.

> [1] will post two PNG's showing that "creative" presentation of header layout
> and names & email-addresses. These also include the TB2 and the just upcoming
> "Postbox" layout. PB is very limited, but that's clearer to me ...

Thanks; it's definitely helpful to be able to look at some of the different things going on side-by-side.

(In reply to comment #6)
> (In reply to comment #0)
> > This would also have a couple of advantages for the compact view itself:
> > 1) people who are interested in working on it would have a single place to
> > do that work.
> 
> Can there be a more single place than core? An extension is (mostly) a single
> place for *one* person to work on it, and nothing prevents an interested party
> from submitting patches. Given the amount of work to get it to look ok on all
> platform has been significant, extension authors aren't that likely do it for
> more than their pet platform.

A fair point; you're right that 1) is not a terribly compelling argument.

I'm not going to respond to all of the comments in this bug individually, largely because I can't pretend that moving the compact header to an extension won't be painful to some people, both users and developers.  However, it's my belief that not removing it would be even more painful to more developers and more users.  I can't quantify this, unfortunately, but here's what I mean:

The high order bit here is that this is an economic decision related to focus: we can choose to either have more features in the core at a lower level of design and quality, or fewer features in the core at a higher level of design and quality.  I believe "do fewer things better" is the clear winner.

I'll make the refactoring patch and prototype extension available here shortly.
Group: mozilla-confidential
Group: mozilla-confidential
I'm posting this to show what sort of changes are required.  There are still some rough edges and cleanup that needs to happen.  In particular, moving the ab listener and friends into the XBL directly should make it easier on extension hackers, and it looks like it should be pretty straightforward.

A build made with this patch will be able to use the CompactHeader extension, which is currently available in source form at <http://hg.mozilla.org/users/dmosedale_mozilla.com/CompactHeader/>.  

For those who wish to browse that code, the most substantial bits are here:
<http://hg.mozilla.org/users/dmosedale_mozilla.com/CompactHeader/file/31736b24a3b7/srcExtension/chrome/CompactHeader/content/>
Are this kind of extensions gonna be mantained by tb team for now? [Compact header as much as folder tree columns thing for example (also moved out)] 
Knowing them "inside" tb team might be some sort of a relief to those not in favor of such changes, question of maintenance and accuracy.

Otherwise, as I don't use the compact mode, I tend to agree not many use it :)


I tend not to favor UI extensions as they seam to me to add another level of complexity and maintenance to themes and other extensions. While being prone to be a bit behind other UI developments. Or maybe this is just my resistance to change. And cleaning might be an answer too.
(In reply to comment #14)
> Are this kind of extensions gonna be mantained by tb team for now? [Compact
> header as much as folder tree columns thing for example (also moved out)] 
> Knowing them "inside" tb team might be some sort of a relief to those not in
> favor of such changes, question of maintenance and accuracy.

There is no such intent.  While I agree that that would make some folks happier, it would defeat the main reason to move it out: to allow the core team to devote more focus to fewer things.

> I tend not to favor UI extensions as they seam to me to add another level of
> complexity and maintenance to themes and other extensions. While being prone to
> be a bit behind other UI developments.

You're right that there are disadvantages to doing things in extensions.  There are also advantages, such as the ability to cater to smaller, more specific groups of people as well as the ability to iterate quickly without the more conservative processes in the core getting in the way.  Realistically, extensions are and will be a key part of our strategy: people need to be able to customize Thunderbird in ways that aren't always appropriate for the masses.

> Or maybe this is just my resistance to change. And cleaning might be an answer
> too.

:-)  We're absolutely interested in cleaning the extension point APIs as we go, so that extensions can be done in a way that's both easy and less fragile.  If you see opportunities to do anywhere in the tree, please file bugs proposing changes.
Blocks: 494796
This patch is ready to go, I think.  The latest bits of the CompactHeader extension are at <http://hg.mozilla.org/users/dmosedale_mozilla.com/CompactHeader/file/9850990e5d4c/srcExtension/chrome/CompactHeader/content/>.
Attachment #376803 - Attachment is obsolete: true
Attachment #380552 - Flags: review?(bienvenu)
Attachment #380554 - Flags: ui-review?(clarkbw)
Comment on attachment 380554 [details]
note the lack of a "hide details" button...

now lets concentrate on getting this header to work well.
Attachment #380554 - Flags: ui-review?(clarkbw) → ui-review+
Comment on attachment 380552 [details] [diff] [review]
compact header removal / extension point improvement patch, v2

Still a bunch of css to remove too...
Good point; I'll fix that soon.
Comment on attachment 380552 [details] [diff] [review]
compact header removal / extension point improvement patch, v2

no need for braces here:

+  if (document.getElementById('msgHeaderViewDeck').selectedIndex != 0) {
+    return;
+  }

there's quite a bit of wasted space at the bottom of the header area - I wonder if other actions could be moved up a smidge, and the blank space reduced.
Attachment #380552 - Flags: review?(bienvenu) → review+
New version of the patch that fixes one bug and gets rid of unused CSS and old icons as well.  Reviewing the interdiff should be sufficient, I think.
Attachment #380552 - Attachment is obsolete: true
Attachment #383826 - Flags: ui-review+
Attachment #383826 - Flags: review?(bienvenu)
I've pushed some fixes, and one skin's worth of CSS and an icon to the CompactHeader repo as well.
(In reply to comment #21)
> (From update of attachment 380552 [details] [diff] [review])
> no need for braces here:
> 
> +  if (document.getElementById('msgHeaderViewDeck').selectedIndex != 0) {
> +    return;
> +  }

Tweaked.

> there's quite a bit of wasted space at the bottom of the header area - I wonder
> if other actions could be moved up a smidge, and the blank space reduced.

Good point.  I'd like to get this landed soonish.  How about I spin that off to a polish bug?

Submitted to the try servers also.
> 
> > there's quite a bit of wasted space at the bottom of the header area - I wonder
> > if other actions could be moved up a smidge, and the blank space reduced.
> 
> Good point.  I'd like to get this landed soonish.  How about I spin that off to
> a polish bug?
> 

I think this was one of the major objections to the new message view.
It's more than just "polish" it's a matter of how important content is to the recipient Vs UI options.
Convenient UI options are fine, but when they interfere with content display, how helpful are they.
I think all of the controversy could have been eliminated with the addition of an f11 (fullscreen view) option ala firefox.
I understand that trade offs must happen inre developers time, but this just seems too much like "It's my way , or the highway"
Incidentally, an offer was made to write an f11 view for TB3 if..it would be accepted by the TB dev team. That offer was ignored.(Can't quote a bugref at the moment)
http://morelayoutsforthunderbird.mozdev.org/ works great for TB2
Sorry for spamming this bug, but I think it's important to gather in all the talent potential that's out there, and not have it be ignored.
Could you please wait until the normal header view is improved to not waste so much vertical space before landing this patch?

e.g., you could make this bug "depend" on some bug that reduces the normal header.

The current compact view works OK and doesn't seem to break anything, so there is no hurry to land this unfortunate bug.
(In reply to comment #25)
> I think this was one of the major objections to the new message view.
> It's more than just "polish" it's a matter of how important content is to the
> recipient Vs UI options.

It's worth keeping in mind that the reason we're doing this is to allow us to focus more on the one message header that remains: we will be continuing to iterate on it between now and 3.0 ship time. 

I understand that some folks are very concerned with vertical real estate, and Bryan and I have some ideas about how we can do some optimizations there.  One thing that we would be helpful as far as figuring out how to move forward would be if you (or anyone, really) could put together a page on wiki.mozilla.org 
where folks can brainstorm specific use cases that are harmed by having less screen real estate and exactly what form that harm takes.  It's possible (perhaps even likely) that some of those use cases can be dealt with in other ways.  It will also be very helpful in figuring out how to prioritize this work against all the other work.

> I think all of the controversy could have been eliminated with the addition of
> an f11 (fullscreen view) option ala firefox.

An interesting idea.  Can you file a bug on this, if there's not one already?

> I understand that trade offs must happen inre developers time, but this just
> seems too much like "It's my way , or the highway"

Given the hours I've personally invested in making sure that it's possible (and even reasonably straightforward) to implement the compact header view in an extension, I don't feel like this is a fair characterization of what's happening here at all.

> Incidentally, an offer was made to write an f11 view for TB3 if..it would be
> accepted by the TB dev team. That offer was ignored.(Can't quote a bugref at
> the moment)
> http://morelayoutsforthunderbird.mozdev.org/ works great for TB2
>
> Sorry for spamming this bug, but I think it's important to gather in all the
> talent potential that's out there, and not have it be ignored.

I, at least, am not aware of this offer.  If you can find details and email them to me, that would be helpful.

(In reply to comment #26)
> Could you please wait until the normal header view is improved to not waste so
> much vertical space before landing this patch?

In the current code base, a fair amount of the relevant code is shared, so doing things in that order will slow things down unnecessarily.  I understand that this means some rough edges in the interim, but I still feel like this is the right tradeoff.
Comment on attachment 383826 [details] [diff] [review]
compact header removal / extension point improvement patch, v3

I've seen the "more" indicator appear inappropriately, but I can't reproduce it. I also see it flicker on and off when I switch between folders. Actually, switching folders w/ remember last message turned on causes a bit of fun when it loads a message - you might try that if you haven't. But I suspect it's an artifact of the way we're loading the last displayed message in a folder...so r=me, but I think we're going to need to shake out some issues.
Attachment #383826 - Flags: review?(bienvenu) → review+
I see those switching issues with or without my patch applied, so I think they're a separate bug.  My suspicion is that it's not very noticable in non-debug builds, but I'll file a spinoff bug about that too.
(In reply to comment #27)
> brainstorm specific use cases that are harmed by having less
> screen real estate and exactly what form that harm takes.

You really want someone to explain why having the maximum possible space for the e-mail's text is important? I must be understanding something wrong. :-\
Fix up indentation and tab lossage as well as bit rot.
Attachment #383826 - Attachment is obsolete: true
Attachment #384035 - Flags: ui-review+
Attachment #384035 - Flags: review+
(In reply to comment #30)
>
> You really want someone to explain why having the maximum possible space for
> the e-mail's text is important? I must be understanding something wrong. :-\

As you point out, it's already clear that it has some level of importance to some set of people for some use cases.  However, just knowing that isn't sufficient to triage it against the set of all the other important things that we'd like to do between and now and Tb3.  So I'm hoping that enumerating the use cases will help us achieve a lot more clarity than we have now about how important it is to what use cases which matter to what set of users how often.  This is also likely to have the side effect of helping us see when there other easier ways to support specific use cases.
(In reply to comment #32)
> (In reply to comment #30)
> >
> > You really want someone to explain why having the maximum possible space for
> > the e-mail's text is important? I must be understanding something wrong. :-\
> 
> As you point out, it's already clear that it has some level of importance to
> some set of people for some use cases.  However, just knowing that isn't
> sufficient 

I quite agree. Enumerated list will be helpful and is all that's needed - no long paragraphs, no discussion/talk needed. I'll add my points there as soon as someone creates the wiki as you suggest.
I don't understand what you mean by "enumerate". Is it the number of people who read their e-mail in the preview pane vs. a separate window or tab? The number of people who receive e-mails that are usually taller than 100 pixels? Or is it a "list" of reasons for and against more vertical space? Could you provide an example of an "enumeration" in this context?

Here's my try (I'll copy it to the page wiki.mozilla.org once it's up):

Q: Why do people use an E-MAIL program?
A: Primarily and majorly to read E-MAIL.

Q: What is the most important part about "E-MAIL"?
A: The E-MAIL'S text. (with sender and subject close seconds)

Q: How "tall" are most e-mails?
A: For me, 30% fill the current view-port (e.g., hand-written stuff)
           50% are more than 2 "pages" long (e.g., newsletters, "conversations")
          <20% are between 4 and 10 lines tall

Q: How often do you use the preview pane vs. separate window or tab?
A: preview pane:    99%
   separate window:  1%
   tab:             <1%

It seems all this "enumerating" could take up more time than actually fixing the problem (reducing the extra space above the From line, below the Tags line, and between the From and subject lines). But I also know that fiddling with CSS can be VERY time-consuming (especially for a novice like me).
enumerate "2. to specify one after another : list"

i.e. simply bullet *list* the use cases where, for you, a one line header is desireable:

* bugmail - rationale: don't care about any of the header info, plus bugmail has too much double an triple spaced stuff
* mailing list ...
* newsgroup ...
* small displays ...
I've been using the word "use case" in a fairly specific sense.  I'm CCing faaborg, jboston, and humph, because I know faaborg has an ongoing project to try and bringer crisper design vocabulary to the Mozilla community, and I'm hoping jboston can find bandwidth to write a Mozilla Education mini-document about this particular one.

I've been using use case (hopefully more or less correctly!) to mean a person trying to accomplish a specific goal.  Some examples of use cases the way I'm thinking about them:

* a person who has only ever filed one bug is trying to read the latest update to that bug in their Inbox
* a developer who gets a lot of bug mail is trying to quickly get an overview of all his new bugmail
* an end-user receives an email containing only a bunch of pictures from a family member and wants to get an overview of the pictures without looking at every one in detail
This going to need some documentation about both the APIs as the stand today (for devmo) and the changes since Tb3 (for the relnotes).  Adding dev-doc-needed.  I've added drafting that content to my todo list.
Keywords: dev-doc-needed
(In reply to comment #21)
>
> there's quite a bit of wasted space at the bottom of the header area - I wonder
> if other actions could be moved up a smidge, and the blank space reduced.

Spun off as bug 499410.

(In reply to comment #28)
> (From update of attachment 383826 [details] [diff] [review])
> I've seen the "more" indicator appear inappropriately, but I can't reproduce
> it. I also see it flicker on and off when I switch between folders. Actually,
> switching folders w/ remember last message turned on causes a bit of fun when
> it loads a message - you might try that if you haven't. But I suspect it's an
> artifact of the way we're loading the last displayed message in a folder...

Spun off as bug 499412.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
(In reply to comment #27)
> (In reply to comment #25)

> > I think all of the controversy could have been eliminated with the addition of
> > an f11 (fullscreen view) option ala firefox.
> 
> An interesting idea.  Can you file a bug on this, if there's not one already?
> 

Bug filed
bug 499516

And BTW "My way or the Highway" was not my personal characterization,
just the reflection of a lot of commentary that I've seen.
(In reply to comment #40)
> > An interesting idea.  Can you file a bug on this, if there's not one already?
> > 
> 
> Bug filed
> bug 499516

Thanks!

> And BTW "My way or the Highway" was not my personal characterization,
> just the reflection of a lot of commentary that I've seen.

I'd be curious to know which commentary you're referring to.
Bug 499989 -  Remove "more" indicator from mail header view.
Asking for specific use cases where a compact view is better ignores the fact that some people (such as myself) simply prefer a compact header view, and it was quick and easy whenever you needed to view more headers to just click on the icon to the left rather than finding the appropriate menu item in the view menu.

Its not just a question of more visual real estate. I dislike the added buttons/list box in the new message viewer - I find them distracting since I prefer to use the toolbar at the top of the main window (I use buttons added from the Buttons! add-on etc. and I don't want to have to deal with two locations for buttons)  One nice side effect of having a compact header in Shredder would be if it hid all of the new message viewer elements.

My impression is that most of the changes to the message viewer are designed to make things easier for somebody who reads their email in a separate window. Please don't make things worse for people that read all of their email in the preview pane, in order to do that.
(In reply to comment #43)
> Asking for specific use cases where a compact view is better ignores the fact
> that some people (such as myself) simply prefer a compact header view, and it
> was quick and easy whenever you needed to view more headers to just click on
> the icon to the left rather than finding the appropriate menu item in the view
> menu.

You're right; it does ignore that fact, but not out of malice.  The problem is that Thunderbird has a large enough user base that for any given feature in the core, there is some set of people who will prefer that feature to a proposed alternative.  This means that just knowing that some people like a given feature doesn't help us decide which set of features are the critical ones to ship as part of the core.  So we need to turn to design processes (like looking at use cases) to help use make these sorts of decisions.

The extension system exists specifically to address this dilemma: no matter what we ship in the core, there are things that any given user will wish were different.  Which is why I specifically invested time in making sure that it's still possible to implement the compact header as an extension.
 
> Its not just a question of more visual real estate. I dislike the added
> buttons/list box in the new message viewer - I find them distracting since I
> prefer to use the toolbar at the top of the main window (I use buttons added
> from the Buttons! add-on etc. and I don't want to have to deal with two
> locations for buttons)  One nice side effect of having a compact header in
> Shredder would be if it hid all of the new message viewer elements.

Indeed, having two copies of those buttons is unnecessary, which is why there's a Tb3 blocker bug on file to remove them.  For Tb3, we're going to try very hard to make the new message viewer significantly better.  If it still ends up in a place where you prefer the old one, putting together an extension to re-implement the old one would be the way to address that. 

> My impression is that most of the changes to the message viewer are designed to
> make things easier for somebody who reads their email in a separate window.

I'm not aware of any such intention, and I've been pretty deeply involved in the whole process.

> Please don't make things worse for people that read all of their email in the
> preview pane, in order to do that.

I am one of those people (and I actually suspect this is far and away the most common case), so I'm highly motivated to see us end up in a good place.  You might consider hiding the duplicate toolbar buttons for a while to see if the resultant change in workflow causes the new buttons to grow on you.
(In reply to comment #44)
> Indeed, having two copies of those buttons is unnecessary, which is why there's
> a Tb3 blocker bug on file to remove them. [Bug 474523]

...and there is another blocker (bug 465138) to make the header-pane buttons configurable as a toolbar as well. While I'm not exactly sure where that bug is going, it hopefully won't be necessary to have to create an extension just for the simple purpose of removing the action buttons there and place them onto the main toolbar from the palette there.
Please add your use case(s) of compact message header to https://wiki.mozilla.org/Thunderbird:Compact_Message_Header:Use_Cases
(In reply to comment #46)
> Please add your use case(s) of compact message header to [some wiki]

My experience is that when people ask for "use cases", that it will most often do no good. It seems that no matter how compelling the "use-cases" are, they are never enough (see the horrible tab switcher panel now in Firefox). It seems that asking for use cases is to keep people busy so they don't bother those who've already decided where things are going to go. The Wiki page seems like a black hole to me.

Sorry for being so skeptical, but I'm being open and honest about my impressions.

Nevertheless, I've jumped into the black hole and listed some "use cases" (aka reasons) on the wiki page.
comment #37
>I've been using the word "use case" in a fairly specific sense.  I'm CCing
>faaborg, jboston, and humph, because I know faaborg has an ongoing project to
>try and bringer crisper design vocabulary to the Mozilla community

comment #47
>It seems that asking for use cases is to keep people busy so they don't bother >those who've already decided where things are going to go.

One problem with relying only on use cases is that people who happen to use something differently will argue that they are just as right as everyone else (and as dmose notes, for a large use population there will be plenty of people in this category).  This causes every UI discussion to fall back to customization, and world of "personal preference" where there is no right and wrong. So I would encourage people to debate each side of the argument using generally agreed upon principles of interface design, like these: http://www.useit.com/papers/heuristic/heuristic_list.html (although that is just an example, there are plenty of other lists).  This will ground the discussion in a world where one design can be objectively better than another, and provide a vocabulary for useful debate.
(In reply to comment #48)
> I would encourage people to debate each side of the argument using
> generally agreed upon principles of interface design, like these:
> http://www.useit.com/papers/heuristic/heuristic_list.html

In that light, here are some of the "generally agreed upon principles of interface design" that make it important that the header (a) waste as little (vertical) space as possible (see bug 499410), and/or (b) allow users to minimize the header even further (this bug):

Visibility of system status: 
The users should (always) be able to see the relevant information in the header. (contradicts bug 464309)

User control and freedom:
Users should be able to minimize the header (this bug) and/or add/remove items from it.

Flexibility and efficiency of use:
Users should be able to minimize the header ("flexibility") and it should not waste (vertical) space, thus taking away space for the e-mail's body ("efficiency"). (see bug 499410)

Aesthetic and minimalist design:
Every effort should be made to avoid wasted (vertical) space in the header ("minimalist"). (see bug 499410)

Regarding evaluating how important these bugs are (IOW their priority), it should be remembered that the ability to efficiently and effectively read e-mails is certainly more important than the ability to, say, search all messages or have the common UI buttons hidden in the header (or whatever else developers may be working on).

BTW: I don't think there exists even a *mock-up* of the new (and apparently very large) search UI that supposedly necessitates moving the UI buttons into the header and the whole (space-grabbing) redesign of the header.
this bug is closed, so I believe further discussion needs to move to some other location.
Agreed. I think a developer should suggest *where* this "other location" should be (newsgroup? other bug?), because (a) they are the ones who would most need to follow/conduct the discussion, and (b) doing so would indicate that they are even interested in this important issue. Anyone...?
Keywords: relnote
I will try to provide a suggestion for a simple solution, but first let me explain where I see the problem:
For netbook users with a screen height of 600px, this makes thunderbird quite unuseable: The title, menu and symbol bar and the column headings of the message list eat 114 px, the header (with one of my average mailing list messages) eats another 144px, the attachment list and status bar take another 79. This leaves 263px to divide between the message list and the message preview pane - i. e. less for each pane than the header wastes.

As I am sure your reason is a good one, why not just add another option not to show any headers at all? (All/normal/none) For most messages, the header does not give any important information not already given in the message list. For people with severe space constraints, this would be a welcome workaround. It should not take too much work to implement a feature to hide the whole thing, and the only other "disadvantage" of this is another (sub-)menu entry.
please add cite your issues in https://wiki.mozilla.org/Thunderbird:Compact_Message_Header:Use_Cases - screen shots will also help
Whiteboard: [b3ux] → see comment 44-46
There is an addon to implement a more compact header view:
https://addons.mozilla.org/firefox/addon/13564
http://compactheader.mozdev.org/index.html

There is also Bug 466025 "explore message header tweaks and variants for tb3 [and polish]"
Blocks: 513553
Whiteboard: see comment 44-46 → see comment 44-46, 55
if collapsedHeaderViewButton is removed, then probably also expandedHeaderViewButton can go?
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.