GNOME Bugzilla – Bug 730682
Refine the conversation list
Last modified: 2021-07-05 13:28:12 UTC
Created attachment 277109 [details] screenshot and mockup Apologies if any of this has been reported already. The message list in 0.6 uses a lot of space, and isn't particularly easy to read. Contributing factors include using three lines of text, irregular line spacing, variation of text size, as well as some icon alignment issues. The separator lines are also too tall. I've attached a screenshot, along with a mockup for how these issues could be overcome. This attempts to make the list more efficient in terms of space usage and ease of reading. Changes include: * Have a row separator that is 1px tall (rather than 2px). * Indicate when a message is unread by making the sender and title bold (as opposed to using an icon). * Run the message body on from the title, rather than starting it on a new line. * Always show the star (whether unstarred or starred) - this creates stable visual repetition, and avoids visual noise when moving the pointer over the list (when you see the star appear only on hover). This is a quick effort and I'm sure I've missed a few things. I'm happy to update the mockup if you have any comments.
A few comments: - The separator width may be theme dependent. For me (using Ubuntu's Ambiance), it's only 1px thick. - Your conversation list is about twice as wide as I keep mine. Most subjects take up the full width (or more), so this would effectively reduce the preview from two lines to one. (Which may be a good idea....) - Have you tried disabling the previews in Preferences? It'll give you a more compact view, at the cost of displaying less information.
(In reply to comment #1) > A few comments: > > - The separator width may be theme dependent. For me (using Ubuntu's > Ambiance), it's only 1px thick. I'm using Adwaita on GNOME 3.12. I haven't seen any other separators like this with that theme. > - Your conversation list is about twice as wide as I keep mine. Most subjects > take up the full width (or more), so this would effectively reduce the preview > from two lines to one. (Which may be a good idea....) Yeah, I think that would be fine. > - Have you tried disabling the previews in Preferences? It'll give you a more > compact view, at the cost of displaying less information. I have now. :) That helps a bit, although it would obviously be good to refine the list with the previews turned on.
(In reply to comment #0) > Apologies if any of this has been reported already. This is an ongoing subject of discussion. (We call the middle pane the conversation list and I've changed your title as such.) We've made some refinements in the past and were hampered making others due to the design of GtkTreeView et al. In particular, see bug #714972 and bug #713081. Ultimately I would like to move the conversation list to GtkListBox (bug #720850) but was waiting for multiple selection support, which landed in the last week or so. > * Have a row separator that is 1px tall (rather than 2px). This is worth consideration. I think it dovetails with the work we've tried in bug #714972. > * Indicate when a message is unread by making the sender and title bold (as > opposed to using an icon). This is how it works today (in addition to the icon), are you not seeing that? The icon serves a second purpose: it allows for the user to mark a conversation as read/unread with a single click. I find this very handy and would push back on removing it. > * Run the message body on from the title, rather than starting it on a new > line. I think this is a good idea, but it introduces other questions. First, we currently ellipsize the subject line; under this approach, should it run on multiple lines? Long subject lines are more common than you might think. We initially ran with a single preview line, but we saw over time that that wasn't particularly useful, since it was often filled by salutations, dates, or quoted text. We've gotten better over the years filtering out cruft from preview text, but it's not perfect. > * Always show the star (whether unstarred or starred) - this creates stable > visual repetition, and avoids visual noise when moving the pointer over the > list (when you see the star appear only on hover). This was originally how Geary presented the star, but we received complaints that it was too much visual clutter, even when it was faded. We decided to go the direction we did for the same reason as the read icon: to show it when it was activated (when it's important and not the general rule) and to hide it when off. I'm happy to reconsider all of our design decision, but please understand that they were not capricious and came out of years of both work and dogfooding. I would love to overhaul the conversation list design. I was hoping to do that when we moved to GtkListBox. Please keep throwing mockups and suggestions our way, we're happy to get them!
(Restricting my replies to things that need discussion.) (In reply to comment #3) ... > > * Indicate when a message is unread by making the sender and title bold (as > > opposed to using an icon). > > This is how it works today (in addition to the icon), are you not seeing that? Yes I do. I should have been clearer here - I meant that unread status should only be indicated with bold text, and not with the icon also. The duplication of how unread is indicated is part of the issue here. > The icon serves a second purpose: it allows for the user to mark a conversation > as read/unread with a single click. I find this very handy and would push back > on removing it. Honestly, I think mark as read/unread would be better served by a header bar button and a keyboard shortcut. It's pretty unusual for an email client to provide a button for marking read/unread on each mail (the Gmail web interface certainly doesn't provide it), and I think that's probably because it's just not interesting enough in most cases. The read/unread icon introduces a lot of visual noise and reproduces the bold text. I'm not a fan of showing controls on hover like this, since it makes the UI feel busy and unstable. > > * Run the message body on from the title, rather than starting it on a new > > line. > > I think this is a good idea, but it introduces other questions. First, we > currently ellipsize the subject line; under this approach, should it run on > multiple lines? Long subject lines are more common than you might think. > > We initially ran with a single preview line, but we saw over time that that > wasn't particularly useful, since it was often filled by salutations, dates, or > quoted text. We've gotten better over the years filtering out cruft from > preview text, but it's not perfect. To me the preview line is a bonus, to be displayed where possible but not to the detriment of other information. As such, my suggestion would be to let the title run over the two lines, and to only follow on with the preview when there is space. > > * Always show the star (whether unstarred or starred) - this creates stable > > visual repetition, and avoids visual noise when moving the pointer over the > > list (when you see the star appear only on hover). > > This was originally how Geary presented the star, but we received complaints > that it was too much visual clutter, even when it was faded. We decided to go > the direction we did for the same reason as the read icon: to show it when it > was activated (when it's important and not the general rule) and to hide it > when off. > > I'm happy to reconsider all of our design decision, but please understand that > they were not capricious and came out of years of both work and dogfooding. I > would love to overhaul the conversation list design. I was hoping to do that > when we moved to GtkListBox. This might well depend on how the star is positioned/coloured. A good many email clients have a permanent star, and it hasn't felt distracting in the ones that I've tried. If you have a screenshot of the Geary version that included a permanent star that could help. I'd personally argue that showing elements on hover is more distracting that having subtle permanent elements in the list. > Please keep throwing mockups and suggestions our way, we're happy to get them! Don't worry, I will. :)
(In reply to comment #4) > Honestly, I think mark as read/unread would be better served by a header bar > button and a keyboard shortcut. It's pretty unusual for an email client to > provide a button for marking read/unread on each mail (the Gmail web interface > certainly doesn't provide it), and I think that's probably because it's just > not interesting enough in most cases. Apple Mail provides a similar interface as Geary's unread icon (I believe they use a dot). I vaguely recall Sparrow offering something like it too, but it's been so long since I looked at, I might be wrong. Gmail doesn't offer a direct "Mark Unread" button, but they do offer a direct "Mark Important" button, which strikes me as backwards, unless I was selling advertising based on direct machine examination of a user's email to determine what was important to them. Even if no other client worked this way, does that really disqualify the feature? If we go with a button in the toolbar, it needs to deal with an indeterminate state (i.e. the user selecting multiple conversations, some read, some unread). Or would there be two buttons? We already have these options in a header bar button drop-down menu, but the impetus for offering Mark Read/Unread in the conversation list was to make it more easily available for the user, that is, a single click on the conversation itself, just like starring. (In fact, I suspect read/unread is a more common operation that starring for most people, unless the person absolutely never marks a conversation as unread after reading it.) > The read/unread icon introduces a lot of visual noise and reproduces the bold > text. I'm not a fan of showing controls on hover like this, since it makes the > UI feel busy and unstable. It also makes a very common operation immediately available to the user. I feel any solution we come up with needs to keep this in mind. > To me the preview line is a bonus, to be displayed where possible but not to > the detriment of other information. As such, my suggestion would be to let the > title run over the two lines, and to only follow on with the preview when there > is space. That's fine, I can see that. > This might well depend on how the star is positioned/coloured. A good many > email clients have a permanent star, and it hasn't felt distracting in the ones > that I've tried. If you have a screenshot of the Geary version that included a > permanent star that could help. I don't have a screenshot handy, but older versions of Geary worked this way (with the permanent star) using one that was lightly colored against the background. > I'd personally argue that showing elements on hover is more distracting that > having subtle permanent elements in the list. I think, like so many things in UI design, that depends on many factors, including how the user interacts with that portion of the application and what information and/or functionality is being conveyed.
(In reply to comment #5) ... > Even if no other client worked this way, does that really disqualify the > feature? Of course not. My point was that there's a reason why it isn't a typical feature - probably because it's not relevant enough to warrant a prominent piece of UI. ... > > I'd personally argue that showing elements on hover is more distracting that > > having subtle permanent elements in the list. > > I think, like so many things in UI design, that depends on many factors, > including how the user interacts with that portion of the application and what > information and/or functionality is being conveyed. In this case it really does feel distracting - the hover behaviour detracts from the experience.
*** Bug 741239 has been marked as a duplicate of this bug. ***
*** Bug 720850 has been marked as a duplicate of this bug. ***
A WIP for this using GtkListBox is going up in wip/730682-refine-convo-list, but it would probably be much smoother sailing if Bug 779116 and possibly Bug 766133 landed first, so I'm going to mark those as dependencies and get back to this once they have landed.
What about using underline for the sender and/or italic for the title?
(In reply to Frédéric Parrenin from comment #10) > What about using underline for the sender and/or italic for the title? Well, taking advice from the HIG (https://developer.gnome.org/hig/stable/typography.html.en), heavier or darker text is preferably to draw attention to important text, and italic (and presumably other variants like underscored?) text should be avoided. However since we already are using bold to indicate unread messages and senders, we can't really use that for subjects or senders in general. I'm pretty happy with the current (re)design - a good slab of white space now separates individual messages, so the eye fall right on the sender(s)'s names as it scans down over each conversation in the list. I'll attach an actually screenshot of the current work-in-progress branch so you can have a look, perhaps give it a try once it lands on master and let me know what you think then? Alan, I feel like there's a question of whether the sender(s) should be the first line for each item in the list or if the subject should. I'm inclined to think the latter since it's easier to remember a sender's name and hence search for it rather than a random subject, which people might not remember. Do you have any opinion on this?
Created attachment 365671 [details] Current screenshot from WIP branch
Hi Michael, The screenshot looks good indeed. A further suggestion would be to use a small indent for the sender, so as to differentiate it from the title. Regarding the order, I would keep sender first because this is where the date lies.
BTW, I am not sure I agree with the removal of the horizontal lines between the conversation. It helps to differentiate the conversation without taking too much vertical space.
Created attachment 365699 [details] Google Inbox UI (for comparison) (In reply to Michael Gratton from comment #11) > However since we already are using bold to indicate unread messages and > senders, we can't really use that for subjects or senders in general. Maybe we can use the background to indicate unreaded messages. Something like: Gray background, lighter text → readed White background, normal text → unreaded Another option is to think inversely: continue using bold to indicate unread state, and unbold + reduce font size + lighten the font color of the subjects. (These are just ideas that popped out of my mind - I didn't test them, and have no idea how well they'd work in real life) > I'm pretty happy with the current (re)design - a good slab of white space > now separates individual messages, so the eye fall right on the sender(s)'s > names as it scans down over each conversation in the list. I'll attach an > actually screenshot of the current work-in-progress branch so you can have a > look, perhaps give it a try once it lands on master and let me know what you > think then? The redesign indeed looks great, but I'm afraid it looks "heavier" than Allan's suggested mockup. I'm attaching the current Google Inbox UI for read and unread emails, for comparison. IMO it doesn't work very well, because of the following points: * When my inbox is full of emails, it gets ~really~ hard to detect which ones are readed and which ones are not. I can't state how annoying it is. * The unified layout sometimes gets in the way, specially when I'm reading a long thread. I have to scroll a lot to get out of the current message without closing the thread. * When there is no avatar associated with a given account, Inbox shows a colored background with the first letter. It's distracting and definitely doesn't help. On the other hand, I think some ideas there work well: * The avatars, when available, end up helping figuring emails out. * The grouped messages are really handy. This ended up being a wall of text, but hopefully these point may help us figure out a better layout for the conversation list.
(In reply to Frédéric Parrenin from comment #13) > A further suggestion would be to use a small indent for the sender, so as to > differentiate it from the title. Yup, it does need a bit of tweaking still. Per Allan's mockup I'm going to add in some space between sender and subject. (In reply to Frédéric Parrenin from comment #14) > BTW, I am not sure I agree with the removal of the horizontal lines between > the conversation. It helps to differentiate the conversation without taking > too much vertical space. Rules lines are useful when you have long, narrow rows, and especially when there is substantial white space between columns, such as Naulilus' list view or GMail's Inbox (e.g. attachment 365699 [details] above), so that the eye doesn't lose its place when scanning across the row. Neither of those are usually true for the conversation list however, since it typically only occupies between 1/4 to 1/3 the width of a screen, and especially since the preview text is usually long enough to span the entire width - it essentially performs the same task as the ruled lines. So I'm inclined to keep the ruled lines out to reduce the visual clutter, but recognise there might be an issue for people with large monitors who disable showing the preview text however. I'll ah, keep an eye on it? :) (In reply to Georges Basile Stavracas Neto from comment #15) > Created attachment 365699 [details] > > Maybe we can use the background to indicate unreaded messages. Something > like: > > Gray background, lighter text → readed > White background, normal text → unreaded Unfortunately GtkListBox already plays around with the background colour a lot, as can be seen in the screenshot I posted: Selected is blue, and the mouse-over pre-light is light grey (under Adwaita anyway). So I am hesitant to use background colour since we would need three variations for each, giving six total background colours, which is way too many to be able to learn and quickly establish what the state of a row is by simply glancing at it. > Another option is to think inversely: continue using bold to indicate unread > state, and unbold + reduce font size + lighten the font color of the > subjects. > > [snip] > > The redesign indeed looks great, but I'm afraid it looks "heavier" than > Allan's suggested mockup. Yeah, know what you mean. We could simply use a less heavy variant than straight-up bold (semi-bold perhaps?), and as above after adding some whitespace between the subject and sender might also lighten it up. I'll have a play around with it. Note also that the screeshot is probably showing up as 2x actual size, since I'm running a high DPI display here, so if you zoom out it might look a lot less scary. :) > I'm attaching the current Google Inbox UI for read and unread emails, for > comparison. > [snip] > On the other hand, I think some ideas there work well: > > * The avatars, when available, end up helping figuring emails out. > * The grouped messages are really handy. Yeah I don't mind having avatars in the conversation list, although that will probably want to be done as a new feature request. How does GMail show avatars when there are multiple people in a conversation? Also, how does that grouping work in GMail? There's been a feature request for something sounding similar over in Bug 792066, or is it more like Bug 766357?
Bump tickets to 0.14 that aren't going to make 0.13.
*** Bug 749932 has been marked as a duplicate of this bug. ***
Another wanted feature would be highlighting participated-in threads¹. It's mainly useful for peoples participating in mailing lists, which is a popular way of communication on many projects. The current problem is, when you reply to many discussions, you don't usually remember ones you participated in, so when such thread gets bumped you don't know whether it's worth looking at the update. 1: https://gitlab.gnome.org/GNOME/geary/issues/349
I was asked to move discussion about highlighting participated-in threads here, so small recap: 1. Since Geary currently shows "Me" in the list of participants of a participated-in conversation, I suggested that this can be exploited by: α. coloring "Me" in, say, blue, and β. always showing "Me" the first (otherwise names appear in chronological order, and "Me" may be beyond visible part of the list) 2. Michael said that α is a bad solution because themes are a thing, and also there are people with color blindness; and for β that he don't want to break chronological order; however the β can be worked around by writing names as either "Me & Bob, Alice, …" or "Bob, Alice, … & Me." I'd vote for "Me & Bob, Alice, …" since "Me" here is more visible, and I also think it's easier to implement. If nobody opposed, I could send a patch. 1 still needs a solution though. I don't know much about GTK interaction with themes, and can't really comment anything because the only solution I can think of that would satisfy both themes and color-blindness is painting "Me" in bold. But "bold" is already used in the list to highlight senders of unread mails, so this may introduce confusion. Italic may be a thing though — gotta test it. Or, how about inverting background and foreground colors of "Me", does the widget support that?
Another suggestion: right now number of mails is shown as a white number inside a big gray circle. This is confusing, this looks like a number of new mails. How about following changes: 1. For read conversations show a usual number, without the circle. 2. For unread conversations use the number in circle. I imagine there's a space for further improvements (e.g. showing separate numbers, or maybe differences), but I think the suggested change should improve the situation right away.
Btw, I should note that the "number in circle" already is used to show a number of new mails — over the panel with inbox, sent, etc.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/geary/-/issues/ Thank you for your understanding and your help.