thunderbird-android icon indicating copy to clipboard operation
thunderbird-android copied to clipboard

Remove folder classes

Open cketti opened this issue 8 years ago • 5 comments

The current system of folder classes has proven to be quite confusing to our users. I'd like to replace it with something that is easier to understand/use. How exactly that could look like is up for discussion.

Quick suggestions:

  1. Allow users to create "folder groups" and have sync and notification settings per folder group.
  2. Per folder sync and notification settings and a bulk editing UI to make it easy to change those settings for a bunch of folders at once.

I doubt the display class is used by many people to switch between different views of the folder list. So I'd just get rid of that feature. It can be replaced by a simpler mechanism to hide selected folders.

cketti avatar Aug 08 '17 09:08 cketti

The above suggestions sound good. I'd like to add a third one that is more evolutionary. It would, for example, conserve the current "class inheritance" (display -> sync -> push -> notification).

IMHO the most confusing aspect of the current class system is that, depending on particular account settings, "2nd class" can have higher priority than "no class", or it can be the other way around.

For example, if an account is configured to display only "1st and 2nd class", "no class" are the lowest priority. If, on the other hand, all folders are displayed "except 2nd class", "2nd class" is the lowest priority.

It seems to me that this choice has been made so that classes can work both as a whitelist and as a blacklist. With no class assigned by default, displaying "1st and 2nd class" corresponds to a whitelist approach, and displaying "all except 2nd class" corresponds to a blacklist approach.

I believe that all the nice features of the current system can be conserved while making it more simple. In the following I use the example of display class, but I mean any class, i.e. also "sync class".

  • Rename 1st -> A, 2nd -> C, "no class" -> B. Each folder thus belongs to a class. (The new classes A, B & C are just placeholders for names that are yet to be decided).
  • Only allow to display folders according to a fixed class hierarchy: "display A", "display A & B" , "display all, i.e. A, B & C". The crucial difference to the current class system is: there's no longer the option "display 1st and 2nd". This option would correspond to "display A and C" after the rename.

The current "1st and 2nd" behavior is a two-level whitelist (it makes it possible to switch between displaying "1st only" and "1st and 2nd"). If this behavior is deemed important enough, it can be implemented in a less confusing way by making the default class of new folders configurable. Then a user can choose C as the default class and thus obtain a two-level whitelist behavior. There could be also functionality to bulk-assign a class (perhaps to all folders, or to all folders that already have some other class).

Another problem that should be tackled at the same time is that currently the default display class for new folders ist "no class", while the default push class for new folders is "2nd". IMHO it's preferable to only set the display class by default.

grothesque avatar Aug 08 '17 13:08 grothesque

I think the whole folder class system is very confusing while it is not adding any functionality or usability.

what i would prefer, is a simple List of all folders in that particular account with checkboxes for subscribed, synch, push, searchable, move target.

With checkbboxes the user has a binary decision between two very distinct a clear options: yes or no. with classes you have a ternary decision (1st class, 2nd class, None) while the meaning of these options depend heavily on other settings. But the user only get's the functionality of e.g. synching: yes or no.

I think the class-system has 2 levels of indirection too many.

If classes were meant for a fast switch between "show me all", "show me, what i need" and "do not disturb or distract me", one might achieve this with to have multiple versions of this above list of folder settings. e.g. a "do not disturb"-version, a "at work"-Version a.s.o.

I think, even the suggested folder groups are a bit too much. in IMAP you can have folders within folders so grouping is already in existence. you can automatically apply all settings of a folder to all it's subfolders, unless the user specifies it otherwise.

mattiscb avatar Apr 18 '18 12:04 mattiscb

I agree that the class system is cumbersome.

  • It is not possible to have an overall view of the status of all folders for a specific action (Display, Sync and Push).
  • It is not possible to reset/change those classes in bulk.

Each folder can have four different class:

  • Display Class o None o Class 1 o Class 2
  • Sync Class o None o Class 1 o Class 2 o Same as Display
  • Push Class o None o Class 1 o Class 2 o Same as Display
  • Notification Class o None o Class 1 o Class 2 o Same as Display

For the each accounts, there is five different class system, which can all be configure differently:

  • Display o All o Class 1 only o Class 1 & 2 o All but Class 2
  • Copy/Paste Destination o All o Class 1 only o Class 1 & 2 o All but Class 2
  • Sync o All o Class 1 only o Class 1 & 2 o All but Class 2 o None
  • Push o All o Class 1 only o Class 1 & 2 o All but Class 2 o None
  • Notification o All o Class 1 only o Class 1 & 2 o All but Class 2 o None

It seem ideal to hide the class property of each folder in the UI and allow a way to list/edit each class system and their member in one single place. I mean, a dedicated UI for each list (display, sync, push, notification, c/p destination) in which we can see all the folders and they status in that list (enable, disable) and a way to enable/disable them all at once.
The class system can still be what is it use in the background, but I do not think it should be visible at all in the UI.

SilentBob999 avatar Feb 24 '20 19:02 SilentBob999

I think the notion of letting people define folder groups, letting people put folders into a (single) group, and having the group control the behavior is good. That does make people define everything as a group, but I think that is actually what 99.9% want.

Personally, I want:

a very small number of folders that do push (and are polled on connect), and for which I get notifications

the rest of the folders not to be updated via push or poll, not to be queried on the server on any periodiic basis, and not to notify me

I can see someone wanting push/poll but not to be notified as a third option, and I can see someone wanting no push and occasional poll, with or without notification.

Beyond that, I wonder if there is a real need for any more complexity.

gdt avatar Feb 24 '20 20:02 gdt

By the way, there is a confusing terminology: in the settings of folder push class, there is an option same as sync class, while there is no sync class setting - I guess that it should be modified as same as poll class. Using different terminologies to name the same thing in a software is pretty confusing.

Iey4iej3 avatar Mar 02 '20 17:03 Iey4iej3