What you describe seems very similar to what Labels/Folders already offer. Or I'm missing something? (well, labels are better, more efficient, but supported only by Gmail AFAIK)

Current limitation of Geary is that you cannot create or edit labels/folders in Geary. You have to do it on your server/webmail. But this is another issue: Bug 714216 - Create/delete/rename folder.

I'm setting this as NEEDINFO, as it's not clear what should be done here.

Folders serve a different purpose – you normally do a quite raw grouping by using folders. But this doesn’t help you, when you search (or want an overview of) all the mails within that folder, relating to a specific topic (since they’re most-probably spread across the whole folder). And you won’t create hundreds of subfolders for hundreds of topics with only a small number of conversations each. So rather think about “lightweight folders”.

Example: I had a problem with my flat, so I contacted the house management and they in turn introduced a conversation between me and a technician. This one problem resulted in about 15 conversations over the years (conversation = mails already grouped by subject). But the problem here is, that I had several problems, which each led to a lot of mails. So in my “Flat”-folder, all these mails are crowded. Creating a folder for every topic would be overkill, if you ask me – so I thought that groups could be useful for grouping a small amount of mails.

Another example:
I have folders for each project at work, with subfolders for raw sub-categories. But along every year, there are really a lot of issues which get covered by mails. If I’d create a folder for each issue, I’d have (a) an incredible amount of folders; and (b) folders containing just one mail, if I do this strictly.


This would also scale smoothly:
Because you could at first add a (second) mail to an already existing mail easily, which would form a group in the first place – and you then would add more mails from time to time as new subjects are introduced, which but relate to the same group (e.g. my technician always creates new subjects and doesn’t reply to my previous mails).

Folders don’t scale that good:
You create them not until you feel like having too much mails about one topic and want to sort that out. You then also have to search for all relating mails and put them into that folder, for avoiding crowded mails. And if you don’t get this feeling at all, the mails would just lie in that folder totally crowded.


A design could be:
• Groups shown like mails in the mail list (but a bit more outstanding).
• The widget would not contain sender + subject + first bit of text, but rather things like:
    – The number of contained mails,
    – meta-information about that group (for example a short sum-up of the topic), and
    – maybe the first (or latest) mail-topics.
• This widget should be expandable, which would enlarge that widget vertically (to the bottom side) by a box frame. Inside this frame, all contained conversations should be shown. So this frame points out, that these mails aren’t independent mail, like all the other mails in the mail list.

This would also solve problems like wrong/inappropriate subject (like when someone replies to a previous mail, but writes about a completely different topic); or mail-subjects, which aren’t clear – because you then can self-define a fitting group name (which could make lookup easier).

Tags:
You would be able to either self-define subject-like tags (like: “[Urgent][Problem][QA][<COMPONENT>] <SUBJECT>”), because if this should be done, not everybody always sticks to that. Or you could implement tags as meta-objects of that widget! :)

Created attachment 366152 [details]
Mock-up

I quickly sectched this up.

And it would be cool, if groups could be transformed to folders and vice-versa. Question then is: What should be done with the summary text? Could that be added to folders as meta data?

I can understand the usefulness of this on traditional IMAP servers, where mailboxes are somewhat heavyweight and adding many may have an impact on both performance and storage. This is one way in which GMail's underlying storage model is superior to IMAP's — labels are in fact lightweight, but since we access GMail via IMAP, we're left in the same position anyway.

So I'd tentatively be interested in adding support for something along these lines in Geary, especially if there was already some consensus in other mail clients about what IMAP flags to use for such a thing so that this grouping also shows up in other clients, and if a decent, discoverable user experience can be worked out for it.

However, showing groups in the conversation list and multiple conversations in the conversation viewer would require quite a lot of architectural re-work, so isn't likely to happen any time soon unless someone contributes patches. It also adds a level of complexity to the UI which to be honest I would rather avoid.

I wonder if a tagging mechanism would work well though, especially if tags were easily searchable, and integrated into the conversation viewer and composer. This might re-use the existing UI much better without needing to add many additional elements. One approach along these lines might be:

 - Add support for searching by tag by typing "#tag-name" into the search box, which would display all conversations with that tag in the conversation list as if they were in a folder
 - Display tags for the currently displayed conversation in the conversation viewer, and make them clickable so that when clicked it invokes a search for that tag
 - When new mail arrives as part of an existing tagged conversation, automatically tag it with the same tags
 - When composing a message for a new conversation, if a specific tag is being shown, then automatically add that tag to the new message

These could potentially be integrated with subject line tags, both when new mail arrives and when composing new mail.

Thoughts?

My proposal was more like „one additional abstraction layer, which is kind of integrated“. I.e. it doesn’t require cumbersome switching (through a directory structure) but rather mixes groups with regular mails, and easily allows specific groups to be expanded (and shown somewhat „next to each other“). So you can search through a directory, while having lone-standing mails loose and related mails grouped (and group-details abstracted away).


Before having to work out the IMAP flags, you could do that just locally as a first step. So that we just have a local database, which groups related mails at opening a folder / showing the content of it. This shouldn’t affecto anything on the server side, because you need to take care about other mail programs not implementing this. Then external changes just need to be taken care of at every sync and everything should be fine.

Regarding the view, the mail view entries then’d need to get replaced by a mail-meta-object, which can hold either a regular mail or a mail-group-object (which in turn holds it’s own GUI and several standard mail objects as children). Doesn’t sound that complicated to me… but of course, I don’t know anything about the internals.


Having a tag sidebar hides the order, in which order mails mix with groups, and it may not show different groups at the same time…? But I can’t imagine that good enough – could you also draw a quick mock-up?

(In reply to Frank from comment #5)
> My proposal was more like „one additional abstraction layer, which is kind
> of integrated“.

Yep, I understand both what you're suggesting and how to go about implementing it, but as I mentioned, it's not that simple.

There's a polynomial number of corner cases already in both the UI and the implementation due to the current model (lists of lists of messages), so if you add a second option to the model (lists of lists of lists of messages) then you're going to get an exponential blow up in the number of corner cases in both the UI and the implementation that need to be dealt with. That will make an already complex mental and implementation model much more complex.

Rather than that kind of complexity blow up I'd very much prefer a linear increase in complexity for both the UI and implementation, which is why I suggested a "tag and search" approach — it re-uses the existing model and hence is easy to learn, and would need somewhat straight-forward additions to the UI for discoverability and to backend to implement.

Ok, but just for me understanding this – could you please explain, why there already are “lists of lists of messages”? I just recognize a first-order list implementation… or is this how multiple postboxes are implemented?

A folder is a list of conversations (the first list), a conversation is a list of messages (the second list).

IMAP's model only supports mailboxes that contain messages, so a conversation is a purely abstract concept that Geary implements, so we're already doing a lot of extra work just to support conversations.

After letting this sit for a (long) while, I'm going to mark this as wontfix, sorry. It's a nice idea, but since it has a lot of overlap with existing folders/labels and because of the complexity I mentioned above, the overhead is outweighed by the befit. And to be honest, it would be at best a low priority, and at the current rate I don't think it will ever get done unless someone from the community provides an implementation anyway.

An alternate approach would be to look into making using folders as easy as what you were thinking. One possible way to do this would be to indicate what labels a conversation already has, and if clicked on, would load all conversations with that label. There's probably other ways as well though.

Please do keep other feature suggestions coming though!