Some of the issues w/ Ambiance are being or have been addressed: bug #746171, bug #746172.

Technically, the only widget addition to the top bar is that the conversation subject and participants are shown there.  Robert and I have been discussing updating/streamlining the conversation viewer (which won't happen in 0.10, but perhaps in the future) and we hoped we could eliminate displaying the Subject: line for each email if it's the same as the conversation.  Placing it in the top bar is a natural way to "title" the conversation.

If that was removed, the new headerbar would actually be less crowded than before, because the Search box has been replaced by a simple button.

Other advantages of this new layout are that the reply/forward buttons are aligned with the conversation viewer, placing them closer to where the user's attention is when reading mail.  This is something we discussed back when we were working on 0.1.  (I even recall the group discussing ways to coerce GtkToolbar to align them with the conversation viewer.)

Also, when composing a new email the composers headerbar now "melds" with the top bar, meaning more real estate for the editor.  It makes the inline composer look more integrated in the main window rather than sitting separated in the conversation viewer.  The new Save/Discard buttons in the header also go toward eliminating the "Do you want to save or discard?" dialog that we had to pop-up.

I guess I'm looking for a middle path here, as I think a lot of these changes make a real difference in the UX.  For example, would eliminating the Subject in the right headerbar alleviate your concerns about crowding?  That and working around some of Ambiance's theme issues with GtkHeaderBar?

One of the things making Geary feel unbalanced in that screenshot is the long subject as the title in the right hand side.  I expect that if you choose a conversation with a short title, it will look less lopsided.  (It does for me anyway.)  We've already added a little bit of padding around that subject, and that did wonders to improve the feel.  We could add significantly more padding, which would help the balance, I think, at the cost of causing more text to be ellipsized.

Other than this and a few niggles we're working on, I see two main problems with the layout in that screenshot.

The first is that the titlebar + headerbar looks bad in the Ambiance theme.  (In contrast, Adwaita specifically styles non-titlebar headerbars differently, to avoid this double-gradient look.)  But this isn't new to this design, and there's essentially nothing we can do to fix it.

The second is that the density along the headerbar varies quite a lot.  Previously, the density was highest at the two ends and lowest in the middle.  As long as we kept the two ends somewhat balanced, the whole headerbar felt balanced.  Now, there's another peak in the density around the separator, and the density on either side is not guaranteed to be equal (see my opening point).  This makes it feel uneven and unbalanced.  However, this effect is very dependent on your window geometry.  Right now, I'm using a narrow, two-pane layout, which gives much less space on the left-hand side and a much more balanced feel.

This is the essential problem with the split-headerbar layout: we give up significant amounts of control of the layout, which can cause it to become unbalanced.  I think the benefits that Jim outlined make up for this problem, but that's a judgment call we have to make.

Robert, I spoke with Adam today about some of his UI issues with current master.  The short of it is, he's concerned that the amount of text in the headerbars looks busy, especially under Unity / Ambiance w/ its top bar (the chrome).  Talking it through, I see the issues he's mentioning.

For now, I'm thinking we should eliminate the text in the right-hand headerbar.  Adam wondered if the problem might be ameliorated by removing the participants' list.  Over the past week, I've noticed that the subject line is ellipsized more than I expected.  The tooltip helps, of course, but the real value in the text there is to see the full subject.

This close to ship, I think the best solution is to simply remove all the text in the right-hand headerbar.  Since the Subject and participants are available elsewhere in the UI, we're okay.

Adam has also asked that the search box be returned to the headerbar (the right-hand one, I believe).  That's less of a concern for me, but with the subject text gone the space does open up.  My question before proceeding there is, is this much of a change/revert?  If we do move it back, this is a change I'd like to keep in a branch somewhere, as me may revisit it after the release.

Removing the subject and participants is okay with me.

Moving the search bar back shouldn't be a big hassle (it got moved in one go in 5162914), but this change touched a bit more than you might expect, and thus lead to conflicts.  It's nothing that couldn't be solved, I'm sure.

However, I'm concerned about moving it back into the header.  I like to keep my conversation viewer fairly narrow (aiming for that 2.5 alphabets width), and I think if you put the search bar in there, the right-hand headerbar would be chock full of widgets.  Besides looking bad, it would reduce the amount of area available to drag significantly.

Let's remove the subject/participants for now and see how it goes.  We still have time for more tweaks if need be.

Created attachment 299634 [details] [review]
Remove subject and participants from headerbar

I've reverted the relevant commits and then squashed them together.

Review of attachment 299634 [details] [review]:

Commit!

Comment on attachment 299634 [details] [review]
Remove subject and participants from headerbar

Should we close this bug, or leave it open?

Attachment 299634 [details] pushed as c5b2b5a - Remove subject and participants from headerbar

Let's leave it open for now, giving Adam a chance to use it and see if this is sufficient for him.

Thanks for listening to my comments and attempting to improve the situation.  It's now less crowded and hence a bit better, but regrettably I think that on Unity the header bar still looks a bit worse than it did before the big change landed.  Some of the issues are that

- I still think the double row of text ("home" over "Inbox") doesn't look great with an empty title bar above it, unless it's at the very center of the window.

- I think the header bar now looks somewhat unbalanced overall: there's text on the left side ("home" / "Inbox") but a large empty space on the right side.

- As Jim mentioned I might still prefer to have a search box in the header: I think it's a major usability win / convenience and also can play a counterbalancing role.

Of course, I know that UI design is hard; we wrestle with it ever day at my web startup here in Cambridge.  I do agree that the new layout is more logical: all the buttons that operate on messages are at the right, above the messages themselves, and there's something to be said for that.

Basically I think our options are

1) Keep the new layout.  In this case I think I'd still advocate eliminating the double row of text ("home" over "Inbox") on Unity at least.  It could just say "Inbox" and the account would be implied by what's selected in the left column.

-or-

2) Revert to the old.

I can certainly live with either path forward.

A few comments, in no particular order:

- Eventually Unity will support client-side decorations (perhaps? we hope? when pigs fly?), so the current double bar configuration is just a stop-gap until that fabled day.  We shouldn't spend too much time optimizing a configuration that we hope is going to disappear soon.

- The main benefit from the split headerbar is not aesthetic, but functional.  It moves the reply buttons closer to the messages being replied to.  It allows the new composer to take up as much space as possible.  It hides useless toolbar buttons when the new composer is up.  If it looks a bit worse than the previous, that's fine with me.  The functional gains outweight the aesthetic loss, in my opinion.

- I've attached (or, will attach, since Bugzilla makes that into a separate step) a mockup of what search in the split header might look like.  I think this makes the header too busy.  It also severely reduces the amount of space available for dragging the window, at least at the window size I tend to use.  I'm not sure what the usability advantage of having the search bar in the header is.  Right now, you can click the search button, or press Ctrl-S, and start typing.  With it in the headerbar, you can click the entry, or press Ctrl-S, and start typing.

- If we're considering changing the text visible under Unity, perhaps we should remove all the text in the headerbar in Unity, and put it in the titlebar instead.

Created attachment 299756 [details]
Mockup of split headerbar with search entry

I feel like there's a bit of an impedence mismatch in design/functionality goal that's near the core of the issue here.  It's exacerbated by Ubuntu's theme issues and lack of CSD support as well as monitor size/dimensions use cases.  When Adam and I talked we did discuss making some of these changes Unity-only, which I think might the way out here.

Here's my proposal:

* On Unity, place the left headerbar text in the main window title (as Robert suggested) and leave it in place otherwise.  Since it's now one line of text I propose this:

Geary - Home - Inbox (14)

* The Search box I'm less inclined to alter at runtime based on the environment.  That's a larger set of code paths to maintain with that in place.  As Robert pointed out, the number of clicks / shortcut keys are exactly the same, it's merely an issue of widget placement.

We've had a number of complaints related to monitor sizes (portrait-mode monitors as well as netbooks, i.e. our Accounts dialog being too big) and I've been concerned for some time that our toolbar was not collapsible enough horizontally.  Putting the search box in a revealer goes a long way toward freeing horizontal space.  (It's also a trend within the GNOME world, and I think it's only going to continue.)

I'd like to keep the search box as it is and see how it pans out.  I for one have gotten used to it (as well as the composer improvements) and really don't want to throw out the baby with the bathwater.

Created attachment 299911 [details] [review]
Set information in titlebar under Unity

This moves the account and folder names into the titlebar from the 
headerbar when running under Unity.  It raises a few other questions.

- Should we always set the title like this?  It shows up in the overview 
in Gnome Shell, for example.

- Should we consider reinstating the conversation subject and 
particpants when not under Unity?  I think it helps with balance.

- Should we be displaying the subject in the headerbar when composing 
new messages under Unity?  See also bug 746502.

(In reply to Robert Schroll from comment #14)
> - Should we always set the title like this?  It shows up in the overview 
> in Gnome Shell, for example.

I thought about that, but I leaned away from barring an HIG guideline from GNOME stating that apps should do that.  More practically, I'm attempting to limit the scope of changes this close to ship.

> - Should we consider reinstating the conversation subject and 
> particpants when not under Unity?  I think it helps with balance.

I think displaying the subject/participants in the right-side headerbar needs to be re-thought.  As I mentioned earlier, too many times the subject was ellipsized, which isn't terribly pleasing.  My current thinking is to use a custom widget for the center of the headerbar which wordwraps and uses a smaller font size.  This might mean not displaying the participants.

Again, this close to ship is not a good time to be in design mode, so I want to wait on this as well.

> - Should we be displaying the subject in the headerbar when composing 
> new messages under Unity?  See also bug 746502.

Only if the composer is detached, and even in that case, only if we're already doing that.

Review of attachment 299911 [details] [review]:

Commit!

Comment on attachment 299911 [details] [review]
Set information in titlebar under Unity

Leaving this open to remove the header titles in the composer.

Attachment 299911 [details] pushed as 577b5fd - Set information in titlebar under Unity

Created attachment 300006 [details] [review]
Don't set composer title when inline new

This takes care of the composer.

Review of attachment 300006 [details] [review]:

Thanks.

Adam, once Robert has pushed these commits could you pull from master and see how they look to you?

Comment on attachment 300006 [details] [review]
Don't set composer title when inline new

Leaving open for discussion

Attachment 300006 [details] pushed as 72b2648 - Don't set composer title when inline new

Thanks for the attention to this and for your latest changes.  I just built from master to try out the latest and greatest.

This is starting to look reasonable on Unity.  Just a couple of points:

1. The order of the items in the title bar is different than in other GNOME applications, where the application name typically comes last in the title bar.  Currently in Geary the title bar looks like this:

    Geary - home - Inbox

But in applications such as gedit, the title bar looks like this (at least in gedit 3.10.4, which ships with Ubuntu Vivid):

   foo (~/Desktop) - gedit

So for consistency with other GNOME apps, perhaps the Geary title bar should look like this:

   Inbox (home) - Geary

2. I still think it looks a bit strange to have a large empty area in the toolbar on the left, along with a Find button that opens up a search box that appears directly under that empty area.  In an ideal world for me the search box would be visible all the time in that area.  Given your comments above, however, I know it might be awkward to implement this only under Unity.  If it's not easy to change this, I can live with this the way it is.

Created attachment 300166 [details] [review]
Change format of unity title

This implements the suggested change.  Note that if there are unread messages in the folder, you get a title like:

  Inbox (2) (home) - Geary

This is a little bit odd, but not terrible.

Robert, thanks for the patch.  In my opinion a title like this just looks too complex:

Drafts (484) (home) - Geary

I'd suggest skipping the number, and displaying either

Drafts (home) - Geary

or

Drafts - home - Geary

Created attachment 300320 [details] [review]
Change format of unity title

To avoid critical warnings on startup, we have to check whether current_folder is null or not.  Since we're doing this, we also check main_toolbar.account.  I don't think these will actually come up in every day use.

This is producing a GLib warning on startup (when using unity):

    (geary:2504): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.40.2/./gobject/gbinding.c:903: The source object of type MainWindow has no property called 'current-folder'

I don't know what's this is about, since the MainWindow definitely has that property.

Robert, the issue is that current_folder is a instance member of MainWindow, not a property per se.  To do that, it would need to be declared like so:

public Geary.Folder? current_folder { get; private set; default = null }

The string was getting hairy with the embedded variables and double-quotes and ternary operators, so I broke it up a little and use sprintf.

In the interests of time, I went ahead and made these changes and landed them in master: commit ae6171e

I guess my final question is, can we close this ticket?  If so, I'll go ahead and cut the 0.10 release.

I'm not sure if you're asking Adam or me, but I'm go for release.

I'm asking everyone involved, so, happy to hear you're good with this.

Fine with me!