---- Reported by rschroll@gmail.com 2013-04-24 20:19:00 -0700 ----

Original Redmine bug id: 6861
Original URL: http://redmine.yorba.org/issues/6861
Searchable id: yorba-bug-6861
Original author: Robert Schroll
Original description:

It can be a bit frustrating to try to look back through long conversations.
Two things stand out to me:

1) It takes two clicks to view most messages: one to uncompress the old emails
and a second to unhide the email you wish to view.

2) It's hard to navigate through the emails in the hidden, uncompressed state.
They look very similar, so it's hard to find your place after glancing away or
scrolling.

I'm playing around with an alternative approach. It gets rid of the
distinction between the hidden and compressed states. Hidden emails appear as
10px tall slivers, as in the current compressed state, but when you hover over
them, they pop to the top in their hidden state. Thus, you can navigate
through many old emails just by sliding your mouse up and down. A single click
opens the email in question.

I have a prototype working in pure CSS. Just stick the code below in your
user-message.css. It's not perfect, since the compressed state still exists --
you have to click on the stack once before you get the desired behavior.

    
    /* Disable compressed state */
    .email.compressed {
        margin-top: 16px;
        height: inherit;
    }
    .email.compressed + .email {
        margin-top: 16px;
    }
    .compressed + .compressed + .compressed + .compressed + .compressed + .compressed + .compressed + .compressed + .compressed {
        display: inline-block;
    }
    .email .compressed_note {
        display: none;
    }
    
    /* Enable scrubbing */
    .email {
        position: relative;  /* Need this to set width of .compressed_note */
    }
    .email .header_container:before {
        content: "";
        position: absolute;
        display: block;
        top: 0;
        width: 100%;
        height: 10px;
        z-index: 2;  /* On top, so gets :hover focus for parent */
    }
    .email.hide + .email {
        margin-top: -53px;
    }
    .email.hide {
        -webkit-transition: box-shadow 0s ease; /* Undo animation while scrubbing */
    }
    .email.hide:hover {
        z-index: 1;
        position: relative;
        box-shadow: 0 3px 11px rgba(0,0,0,0.67);
    }

  
The approach will have the added bonus of reducing the number of possible
states of an email from three to two, which will allow some simplifications in
our display code. It would probably solve #6561.

I can see some downsides, though:

  * This first message of the conversation isn't visible by default, as it is now. This could be added in pretty easily, but frankly I don't miss this.
  * The message right before an open message isn't visible by default. This one does bother me, and I initial did have it visible. The problem is that this required a message to move downwards when you clicked to open it, so that the previous one would be visible. But this moved it away from the focus of your eyes, leaving you looking at the message before the one you wanted. (If you want to see this behavior, change `.email.hide + .email` to `.email.hide + .email.hide`.) Perhaps we could get around this with some fancy scrolling, but I'm not convinced this would be any better.
  * There is no maximum length to the old email stack, as there is now. You'll need a whole lot of email to make this bothersome, but it could happen. This could be worked around by automatically scrolling down (though this was controversial before) or only loading the last n emails and providing a link to load the previous ones (though this destroys some of the simplicity of this approach).

Anyway, if you think this could be a worthwhile approach, let me know and I'll
code up a proper patch.



---- Additional Comments From geary-maint@gnome.bugs 2013-08-14 14:31:00 -0700 ----

### History

####

#1

Updated by Robert Schroll 7 months ago

  * **Description** updated (diff)

One thing that I find interesting about this is that you can get a variety of
appearances just by adjusting the margin-top value:

`16px` -- The current fully-expanded appearance.

`-1px` -- A nice compact view that still shows everything

`-30px` -- Shows just the sender and the top half of the gravatar. I kinda
like this.

We could also set the margin-top value programmatically, which could allow:

  * Different overlaps for differently-sized conversations. With only a few emails, all the hidden emails are visible, but with more, they start folding up further and further.
  * Overlaps that depend on the age of the email. Recent read emails are mostly showing, but older ones are mostly covered.
  * User-adjustable overlaps. Imagine hooking the margin-top up to Shift+Mousewheel. The user can compress the read emails when she wants to look at the unread ones and decompress them when looking back through the conversation.
Instead of having the hovered email pop forward, we could have them shift up
and down. Replace the second half of the CSS above with this to see it in
action:

    
    /* Enable scrubbing */
    .email.hide + .email {
        margin-top: -30px;
        /*-webkit-transition: margin-top 0.1s linear;*/
    }
    .email.hide:hover + .email {
        margin-top: -1px;
    }
    .email.read {
        box-shadow: 0 0 11px rgba(0,0,0,0.5);
    }

  
I think this is pretty nifty, myself. Two issues:

  * You need a darker shadow in order to give depth to the list of read messages. This messes with the dark shadow to show unread messages, but this can be tweaked.
  * If you uncomment the transition line, you get animated folding and unfolding, which is super nifty. But the animations of one email increasing and the other decreasing don't quite match up, causing jiggling in the remainder of the document. A pity.

Please give it a try and let me know what you think.

####

#2

Updated by Jim Nelson 7 months ago

  * **Target version** set to _0.4.0_

Robert, why don't you submit a patch with this configured the way you'd like
to see it. If there's some small problems, we'll work through them or ticket
them for later. I'm certainly interested and it does sound like these changes
could improve the experience. Now that we have full conversations, I'm seeing
many of the things you're noticing, so some new approaches are worth
considering.

####

#3

Updated by Robert Schroll 7 months ago

Will do. I just didn't want to spend a lot of time ripping stuff apart and
then trying to reassemble it if everyone was happy with how things are now.

####

#4

Updated by Robert Schroll 7 months ago

  * **File** 0001-New-behavior-for-hidden-emails.patch added
  * **Status** changed from _Open_ to _Review_

Here's a patch that implements something like the second option. Instead of
adjusting the margin-top, I adjust the height, to avoid overlapping drop
shadows.

As I mentioned before, we could imagine adjusting the height of the hidden
emails in response to the number of emails in the conversation, the position
of an email in the conversation, and/or user input. In this patch, it's just
fixed.

####

#5

Updated by Robert Schroll 7 months ago

  * **File** 0001-New-behavior-for-hidden-emails.patch added

The new CSS shouldn't apply to nested emails.

####

#6

Updated by Jim Nelson 7 months ago

  * **Status** changed from _Review_ to _Open_

Robert, we took a look at this and discussed the problems you described in the
ticket description. We agree that the current implenentation isn't the most
attractive or useful (especially in large conversations) and requires a few
clicks to get to what you're looking for. We do think that Ctrl+F search
(#6199) will help the situation by reducing the need to hunt by clicking.

Some of the problems mentioned include that part of the text and the controls
on the right edge are cut off in the collapsed messages, making it look like a
bug. The jumpiness of the topmost message shifting downward was also
mentioned. (We were looking at your last patch without the variants you've
mentioned.)

We looked at how Gmail expands a compressed group of images and thought there
might be some take-away there. It displays the collapsed messages much as
conversations are displayed in its conversation list: name on left, preview,
date on right, with the star and attachment icons in the mix. We're wondering
if that would help alleviate the second problem you identified in your
description, that all the collapsed messages look alike. If more emphasis was
placed on the preview and the name, that might make it easier to scan throught
the messages and find the one you're looking for.

And we do think the compressed messages blob is useful, as we're seeing
conversations with 20+ messages now that full conversations is implemented.
Compressing all the read messages is useful in that situation, so we'd like to
keep that too. But there's still room to better present the collapsed
uncompressed messages, and that's where I think your patch could help. Right
now each collapsed message is a thick block with a thick divider separating
each of them. Let's try narrowing the collapsed message to a line, even
fetching a smaller avatar. Then, as you're doing there, reduce the whitespace
between the messages. Using the hover to pop open the collapsed message is
something we weren't wild about, although perhaps something else could be
considered. (Shift+click? Shift+Mousewheel as you suggested?)

I don't have all the answers here, but I feel like you do have a start for
cleaning up the conversation view. I'd like it if the collapsed messages were
a line high and the space between them was reduced, even if it meant no blank
space and just line dividers. I do like the idea of "popping" up the old two-
line preview with a user event (don't know how hard that might bn).

We can answer any questions you have or any points I forgot to write up here.

####

#7

Updated by Robert Schroll 7 months ago

Jim Nelson wrote:

> Some of the problems mentioned include that part of the text and the
controls on the right edge are cut off in the collapsed messages, making it
look like a bug.

This indicates a failure of my design. It is supposed to look like each hidden
email is behind the one after it, and is exposed by the following email moving
down and out of the way. I was trying to indicate this merely by the drop
shadows, but it sounds like this wasn't enough. As I mentioned, adding CSS
animation really helps the illusion, but I couldn't get the opening and
closing animations synchronized well enough to avoid jitters elsewhere.

> The jumpiness of the topmost message shifting downward was also mentioned.
(We were looking at your last patch without the variants you've mentioned.)

This bothered me too. I'm trying to figure out how to make the :hover email
slide upwards. But I need it to remain in position when you open it, so I
don't think this is going to work.

The first bit of CSS I posted just moved the :hover email forward, so there's
no vertical motion. I didn't think that was as skeuomorphically sensible, but
it may be worth a look.

> We looked at how Gmail expands a compressed group of images and thought
there might be some take-away there. It displays the collapsed messages much
as conversations are displayed in its conversation list: name on left,
preview, date on right, with the star and attachment icons in the mix. We're
wondering if that would help alleviate the second problem you identified in
your description, that all the collapsed messages look alike.

My suspicion is no, at least for me. When I'm looking through past messages,
I'm searching for a bit of text in my head (whether name, date, subject, or
content). I don't want to use another piece of text to remember my position;
it really has to be something purely visual. This leaves us with form, color,
and location. The gravatars help when they're different, but we can't count on
that. Since we don't want to adjust the form and color of the previews [1], we
have to rely on location. Since this is broken by scrolling, we need as many
emails on screen at a time, which was the impetus for my design here.

Decreasing collapsed email to a single line, as you suggest, would help in
increasing the density, so I don't mean to reject this out-of-hand. I'm just
saying that additional text isn't going to help, IMO.

> I don't have all the answers here, but I feel like you do have a start for
cleaning up the conversation view. I'd like it if the collapsed messages were
a line high and the space between them was reduced, even if it meant no blank
space and just line dividers. I do like the idea of "popping" up the old two-
line preview with a user event (don't know how hard that might bn).

One of my motivations for this was to decrease the number of states for emails
to be in, from the current 3 (open/collapsed/compressed) to 2
(open/collapsed). This not only helps us by simplifying the implementation,
but it helps the user get the right mental model what's going on. (I do have
the the hover state, but that's supposed be revealing more of the collapsed
state.) This approach would give us 4
(open/collapsed/collapsed:hover/compressed), which I feel is the wrong
direction. (I know it's the wrong language, but I still respect the Zen of
Python: "If the implementation is hard to explain, it's a bad idea.")

I'm going to leave my name on this but put it on the back burner for a while.
I suspect there's a better solution, so I'm going to let it bounce around my
brain for a while and see what happens. If someone else has a good idea,
please say so or claim claim the bug for yourself.

[1] Or do we? I could imagine hashing each message to produce a pastel color
to use as that email's background. Not only would this help you keep track of
location, it could help you find specific emails you refer to often. You might
remember that a particular email was light pink without really thinking about
it.

I suspect that in practice this would look silly, though.

####

#8

Updated by Robert Schroll 5 months ago

  * **File** hidden-idea.png added

This has been bouncing around in my head for a little. One of the problems
with the previous approach, I think, was that it wasn't clear that there was
more info (specifically the preview) hidden for the hover state to reveal. So
I started to wonder if I could get the preview up into the top half.

This mockup adjusts both the email address and preview to be two lines. The
name and first line of preview are shown in the top half. Hovering over one
(I'm doing that with that email in the middle) brings it forward so you can
see the email addresss and the rest of the preview. Combined with coloring the
sent messages, I think this would give us a view that's as good as the current
"hidden" view while not taking up much more room than the "compressed" view.

If you want to play with it in action, I can post the CSS I used. But it's
pretty ugly -- I'm using absolute positioning to shove the preview to where I
want it. A better solution would be to rearrange the HTML a bit to put the
preview in a better location. I'd need to do some work to get overflows to
happen correctly. We might also reduce the padding of the hidden emails to get
slightly higher density.

We still probably need to do something when loading a conversation with 20+
emails in it. I'm still a fan of loading everything and then scrolling down to
the relevant email, but this behavior wasn't appreciated before. Another
option would be to put a link at the top of the conversation saying "Load _n_
earlier emails". This might also be triggered by scrolling upwards against the
top, although we'd want to heuristics to distinguish between scrolling to the
top and scrolling "past" the top.

Let me know if y'all like this approach or not. If so, I'll try to code it up
more correctly.

####

#9

Updated by Avi Levy 5 months ago

Wow, this approach seems pretty innovative. One tiny suggestion: in the
screenshot, there is a thin sliver below the currently focused message. I
think things may look cleaner if the sliver was removed (if I understand
correctly, that would mean the height of a focused message should be exactly
twice the height of an unfocused message). Hopefully this ends up in Geary!

####

#10

Updated by Robert Schroll 5 months ago

Avi Levy wrote:

> One tiny suggestion: in the screenshot, there is a thin sliver below the
currently focused message. I think things may look cleaner if the sliver was
removed

This is one of several spacing issues to work out if we go this way. I'm not
sure whether it's better to have it line up exactly to look clean, or miss by
a lot to clearly show that the focused one is hiding others. But the thin
sliver is clearly wrong.

You're also welcome to try out the older CSS I posted to see if that gives you
any other ideas here.

####

#11

Updated by Jim Nelson 5 months ago

Robert, I've been thinking about this approach, your mockup, and
collapsed/compressed messages in general. Just to make sure we're talking
about the same thing:

  * This approach would eliminate collapsed messages, replacing them with this overlapping approach.
  * When the user visits a conversation with a lot of read messages, it will still scroll to the first unread message.
  * If the user hovers the mouse over one of the overlapped messages, it "pops" to the top. There's no mouse click involved in either bringing it up or send it back into the stack.
  * A mouse click will uncollapse the message, causing the read messages before and after it to remain stacked.

Some questions:

  * Would this approach also eliminate compressed messages as we have them today -- that is, even two collapsed messages would be stacked like in your mockup?
  * Is there a delay before a hovered message pops to the fore, or is it instant?

Also:

> I'm still a fan of loading everything and then scrolling down to the
relevant email, but this behavior wasn't appreciated before.

I'm confused -- isn't this the current behavior?

I have to admit, I've become less and less inured to the collapsed message
approach we have today, mostly because if I'm going back to older email in a
conversation, I'm usually looking for (a) who is in this conversation, (b) a
starred message, or (c) a message with an attachment, all of which is lost
with compression. This approach, on the other hand, keeps that available.

I'd be interested in seeing a patch!

####

#12

Updated by Robert Schroll 5 months ago

Jim Nelson wrote:

>   * This approach would eliminate collapsed messages, replacing them with
this overlapping approach.

Yep.

>   * When the user visits a conversation with a lot of read messages, it will
still scroll to the first unread message.

In the current conversation viewer, there's no scrolling done. We don't need
it because the compressed view ensures a maximum distance (2 hidden + 8
compressed) to the first open email.

We will need to do something about this with this approach, I think, because
we can't guarantee a maximum here. Three ideas:

- Scroll to the first unread email.  
- Only load a few read emails, with a link to add more.  
- Only load a few read emails, and load more when the user scrolls upwards against the top. (This is sort of an average of the first two.)

>   * If the user hovers the mouse over one of the overlapped messages, it
"pops" to the top. There's no mouse click involved in either bringing it up or
send it back into the stack.

Yep. I'm trying to cut down on clicks.

>   * A mouse click will uncollapse the message, causing the read messages
before and after it to remain stacked.

Yep. This means that the user positively sets the state of all messages, and
we won't have that confusion about what state emails should be in when we load
more messages into the the view.

>   * Would this approach also eliminate compressed messages as we have them
today -- that is, even two collapsed messages would be stacked like in your
mockup?

Yep. It may not be necessary for space, but I think it is for consistency.

>   * Is there a delay before a hovered message pops to the fore, or is it
instant?

It's instant right now, since I'm doing it with CSS. I think this is the right
way to do, since it allows "scrubbing" through the emails. But in truth I
haven't considered this before.

> > I'm still a fan of loading everything and then scrolling down to the
relevant email, but this behavior wasn't appreciated before.

>

> I'm confused -- isn't this the current behavior?

As mentioned before, no -- there's no scrolling currently. We had some before
we introduced the compressed emails.

> I'd be interested in seeing a patch!

I'll try to throw something together. In the meantime, I'm happy to see
mockups or vague ideas from others.

####

#13

Updated by Jim Nelson 3 months ago

  * **Target version** changed from _0.4.0_ to _0.5.0_



--- Bug imported by chaz@yorba.org 2013-11-21 20:26 UTC  ---

This bug was previously known as _bug_ 6861 at http://redmine.yorba.org/show_bug.cgi?id=6861
Imported an attachment (id=260995)
Imported an attachment (id=260996)
Imported an attachment (id=260997)

Unknown milestone "unknown in product geary. 
   Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
Resolution set on an open status.
   Dropping resolution