Bug 310919 - Improve and simplify Grouping and Threading UI
Summary: Improve and simplify Grouping and Threading UI
Status: REPORTED
Alias: None
Product: kmail2
Classification: Applications
Component: UI (show other bugs)
Version: 4.10 pre
Platform: Ubuntu Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-30 12:11 UTC by Bernd Oliver Sünderhauf
Modified: 2012-11-30 12:11 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Oliver Sünderhauf 2012-11-30 12:11:13 UTC
The list of Message Aggregating Modes in the main menu is rather long and hard to grasp.
Many people will regularly switch the modes back and forth, between threaded and flat view. This is why Thunderbird even has a prominent switch for this in the header of the messagelist.

Solution 1:
So for power users, it would be good to allow reducing the long and complex list to the most important ones. Deleting any default modes is not possible neither would it be a good idea, given the complex configuration of the modes, so it would be the best solution to allow disabling and reordering it in the configuration dialog.

Solution 2:
For out-of-the-box users the whole concept of Aggregation modes still is too complicated. They want to be able to switch grouping on and off, and they want to be able to switch threading on and off.
So while preserving the flexibility for power users, I'd propose to completely drop the concept of Aggregation Modes, rather to couple grouping with sorting and to make threading a separate, orthogonal concept with a separate advanced UI. This behaviour will in most cases be easier to use.

Now, if someone is willing to implement the first solution as a stop-gap-measure, that's fine. However, I think that is not really worth putting much work into, as it doesn't simplify the out-of-the-box usability.

I'm aware that the second solution would be a rather complex change and needs to be carefully designed and implemented, taking care of most if not all use cases. So this would be a major project for 4.11.
I'm ready and willing to look into this more closely and, if coming up with a convincing solution, to announce it with http://techbase.kde.org/Schedules/KDE4/4.11_Feature_Plan .
In the meantime, please assign this issue to me.

Reproducible: Always