Channel Grouping

This describes a tentative future UI feature.

As people join more and more channels, it becomes difficult to observe and manage presence in all of them. This is a problem in the web UI, but our terminal-based client has even tighter restrictions which puts screen real estate at even more of a premium.

One way of alleviating this would be to introduce a manual notion of channel "grouping": in this system, a user could create named "groups" of channels: this could allow grouped channels to be collapsed in some situations and expanded in others, allowing conceptually related channels to share screen space. These would be manually named and managed channels.

Example

Consider a user who is a member of five channels, three of which are about different programming languages. A user might presently have a channel list that looks like

----Channels----
~golang
~haskell
~off-topic
~scheme
~town-square

but this user could then decide to group the three programming language channels above into a single "group" named programming. This would change the appearance of their UI: when ~town-square is selected, the user's channel list would collapse those channels into a single entry, so it would look like this:

----Channels----
~off-topic
[programming]
~town-square

when one of the channels grouped under programming was selected, however, that channel grouping would expand out, making the channel listing look like this:

----Channels----
~off-topic
[programming]
 ~golang
 ~haskell
 ~scheme
~town-square

For the purposes of notification details, the collapsed channel group would appear to have notifications if any of the contained channels had notifications, and would show a number of mentions equal to the sum of the mentions in the channels.

For the purposes of navigation, the groupings could be invisible: it does not make sense to "select" a group, so the channel select mode would still select individual channels. Interaction with next-channel and prev-channel is TBD, but presumably the ordering would now reflect the new ordering (i.e. next-channel would move through group order, not overall alphabetic order).

Pros:

• This would allow workflows that significantly declutter channel management, especially for Mattermost workflows that involve several low-volume channels.
• Channel groups would always be manual, so this should not complicate usage for users who do not want to use them

Cons:

• This is a synthetic idea that does not have any implementation in the Mattermost web UI
• Storage of group details would have to be local, as the server does not know about it, and consequently this information could fall out of sync with changes made elsewhere