After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 214238 - Indicate unread emails in closed tree subfolders
Indicate unread emails in closed tree subfolders
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.2.x (obsolete)
Other All
: Normal enhancement
: Future
Assigned To: Milan Crha
Evolution QA team
: 569917 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2001-11-01 13:08 UTC by Johann Glaser
Modified: 2009-12-29 10:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed evo patch (4.42 KB, patch)
2008-04-01 13:46 UTC, Milan Crha
reviewed Details | Review
proposed evo patch ][ (2.36 KB, patch)
2009-06-25 11:46 UTC, Milan Crha
committed Details | Review

Description Johann Glaser 2001-11-01 13:09:12 UTC
Package: Evolution
Priority: Minor
Version: 0.16.99
Synopsis: unread emails in closed tree branches
Bugzilla-Product: Evolution
Bugzilla-Component: Mailer

Description:
I have lots of local mail boxes all organized in a tree. Most time I
have several (unimportant) branches closed.

When an email arrives and is moved to one of the invisible mailboxes
(because the branch is closed) then all parent nodes are drawn bold.

If one of these parent nodes contains an unread email itself there is no
difference if a child mail box contains an unread mail or not.

To be able to recognize an unread email in a closed mailbox branch I
would like to have the parents drawn italic. if the parent contains an
unread email itself it should be bold. So nodes with unread emails and
child mail boxes with unread emails too are in bold and italic.


Comment 1 Jeffrey Stedfast 2001-11-20 19:06:43 UTC
feature = future
Comment 2 André Klapper 2005-04-18 19:29:06 UTC
still valid in 2.2.1.
Comment 3 Calum Benson 2005-07-28 10:38:06 UTC
Apologies for any spam... cc'ing usability-maint on all Evolution usability
bugs. Filter on EVO-USABILITY-SPAM to ignore.
Comment 4 Harm Hilvers 2006-12-20 21:04:14 UTC
I was thinking about filing a new bug about a different aproach to the problem mentioned in the summary of this bug, but since this bug is already in Bugzilla I deceided to just post my comment here.

I think it would be a better idea if the number of unread emails in the parent folder would be raised with the number of unread emails in the collapsed sub folders. This way, you still can count the total number of unread emails. That's not possible when you make the folder name italic, since you still have no idea how many emails actually are in there.

I use a search folder to keep track of the number of unread emails. At the moment it says there are 3 three unread emails, but when I count the numbers in the tree there are only 2, since the third one is in a collapsed sub folder and therefore not findable for me when quick scanning the folder tree.
Comment 5 Milan Crha 2008-04-01 13:46:00 UTC
Created attachment 108415 [details] [review]
proposed evo patch

for evolution;

This is something between, with this patch you can see "folder (A/B)" for collapsed folders, where A is number of unread messages in that folder, and B is a sum of all unread messages in subfolders. It will stay "folder (A)" in case there is no unread message in any subfolder.
Comment 6 Srinivasa Ragavan 2008-04-02 11:04:41 UTC
The patch seems fine. I think we need some UI experts thoughts on this. I think it may be confusing to show what this means. Unless Milan you gonna tell that B is the sub folder unread count, I dont think users can figure it themselves.
Comment 7 Milan Crha 2008-04-02 11:18:22 UTC
It's too long to make there a prefix or something in the tree. Lets make a note in a documentation and enjoy?
Comment 8 Calum Benson 2008-08-15 01:16:23 UTC
It's an interesting problem... probably one best addressed to an information designer, but I don't know if we have any of those lurking here...

In general, I'd probably advise against the use of italic or bold+italic fonts for this (as suggested by the reporter).  Italics just aren't always very legible on the screen, and not every typeface even has a bold+italic variant.

The (A/B) notation has potential, I just worry about how much wider it will make the labels in some cases.  It's certainly not unusual for me to have >100 unread emails in a folder, and >100 unread emails in its subfolders-- that would make the unread count alone 10 characters wide, for that collapsed folder.  Personally, I'd hate to have to keep my sidebar wide enough to accommodate that much extra information.

The only other idea I can think of right now is to use some sort of fixed symbol instead of the "/B" part... a plus sign for example:

Collapsed:        Expanded:

> folder1 (12+)   v folder1 (12)
                      folder2 (5)

One problem with that is what to show when *only* the subfolders have new mail... you could show (0+), or just (+).  Or you could show only the total subfolder count, but don't show the name or count of the collapsed parent in bold text as it contains no unread messages of its own.

> folder1 (+)    <-- all bold, as usual
> folder1 (0+)   <-- all bold, as usual
> folder1 (15)   <-- not bold

Whatever solution we choose to implement (if any), I'd suggest we'd want to try out paper prototypes or screenshots with a good number of users first, to see if they understood what we were trying to tell them.
Comment 9 Matthew Paul Thomas (mpt) 2008-08-22 21:05:51 UTC
Thunderbird, like Netscape Mail before it, uses underlining to show that a collapsed message thread's top-level message has been read but that other messages in the thread are unread.

If Evolution adopted that styling for message threads, it could use exactly the same styling for folders. A collapsed folder with an underlined name would mean that all messages at the folder's top level have been read, but there are unread messages in subfolders.
Comment 10 Milan Crha 2009-04-08 16:39:36 UTC
I wonder whether such font change would be useful at all. We have the caption bold already, in case of unread message in any subfolder of it, regardless collapsed/expanded state, thus adding underline or italic might not change anything here, I'm afraid. You can recognize the state of "all read here" by missing "(X)" at the end of the name too.

Anything else I can do here?
Comment 11 Johann Glaser 2009-06-17 15:52:48 UTC
Its the other way round: Currently for collapsed directories with mails in them  its not visible, whether sub-directories have mails too or the top directory is the only one.

Expanded:

  - University (12)
  \-- Course A (1)
  \-- Course B

vs. the collapsed case:

 + University (12)

So, you don't see wheter sub-directories of "University" have unread mails or not.

 * Print every directory in bold, if it or its sub-directories has mails (here: "University" and "Course A"; thats the current behavior)
 * Plus: Print every directory in bold italic, if it has unread mails _and_ at least one of its sub-directories has unread mails too (here: print "University" bold italic because "Course A" has unread mails).
Comment 12 Matthew Barnes 2009-06-17 16:31:38 UTC
I'm in favor of Calum's suggestion in comment #8:

    Expanded              Collapsed
    --------              ---------

    v UNIVERSITY (12)     > UNIVERSITY (12+)
        COURSE A (1)
        Course B          (CAPS indicate bold text)


I think that's the most legible approach.  Any more font styles or emblems on the folders and we're gonna have to start supplying a key to decipher it all.

For the case were only a subfolder has unread messages, I'd say leave it alone.  The bold folder name still conveys that information.

    Expanded              Collapsed
    --------              ---------

    v UNIVERSITY          > UNIVERSITY
        COURSE A (1)
        Course B
Comment 13 Johann Glaser 2009-06-17 16:37:49 UTC
Good suggestion, Matthew. I vote for this.
Comment 14 Milan Crha 2009-06-25 11:46:57 UTC
Created attachment 137361 [details] [review]
proposed evo patch ][

for evolution;

Yup, sounds good here too. The patch is even simpler.
Comment 15 Matthew Barnes 2009-07-14 14:52:23 UTC
Patch looks good.  Go ahead and commit.
Comment 16 Milan Crha 2009-07-14 18:04:35 UTC
Created commit 563a164 in evo master (2.27.5+)
Comment 17 Matthew Barnes 2009-07-14 18:17:09 UTC
(In reply to comment #16)
> Created commit 563a164 in evo master (2.27.5+)
                                              ^ Nice pun for this bug.  :)

Comment 18 André Klapper 2009-07-14 18:46:20 UTC
That's really cool stuff. Maybe even worth mentioning in the release notes.
Comment 19 Akhil Laddha 2009-12-29 10:58:47 UTC
*** Bug 569917 has been marked as a duplicate of this bug. ***