Element-web: Flairs for subgroups vs groups/communities

[denyeo]

Description

I wonder if flairs would actually be more suitable for indicating subgroups rather than groups (as they seem to be now). In the context of a private community, differentiating between subgroups of users certainly seems essential. This applies equally to interest groups and private companies - to any organisation that has subgroups/teams and wants to deploy Matrix for communication purposes.

For the use-case of a community with multiple subgroups of users (say a language-learning community with a few hundred users), flairs would be very helpful to identify who falls into which subgroup. For example, some users would be marked as native speakers and others as advanced learners, so other learners could identify them at a glance as people whose input should be given extra weight.

For reference, here is the way Discord handles roles (equivalent to Matrix subgroups?):

The profile box (shown above) lists all roles of a user in Discord. Roles have priorities and colours, and the highest-priority role of a user (in this case, Challenge/Quiz admin) determines the colour of their username. This username colouring makes for a handy reference system (e.g. in this case, learners of Japanese can tell at a glance which users are native speakers or advanced learners of the language). In Matrix, displaying Subgroup flairs next to usernames would be the equivalent.

I'm not sure whether flairs could be displayed for subgroups as I've proposed above, since it would be confusing if they were also displayed for groups. Maybe someone can share what the current ideas are? For reference: the Community (Group) Use Cases design document, which covers flairs.

[denyeo]

A compromise approach might be:

• Display top-level Group affiliations in the user profile.
• Within a room associated with a Group, display Subgroup affiliations as flairs next to the username.

This way, flairs show the Subgroup(s) for the current Group that a user is chatting in, but other Group memberships would still be visible on the user's profile. This is more practical for intra-organisation chat without sacrificing the ability to show other Group memberships.

[turt2live]

Related: https://github.com/vector-im/riot-web/issues/5259

[lampholder]

Using flair to help navigate to the "right person" to talk to in a room/group is a key part of its utility, so I certainly like the idea of our being able to reproduce the 'native/non-native Japanese speaker' use case in Riot.im.

Obviously (I think) this experience _could_ be implemented today with multiple groups (_+languages:matrix.org_ and _+languages.native.japanese:matrix.org_) at the cost of some increasingly fiddly group admin work (if somebody needed kicking they'd have to be booted from all of the associated groups). Maybe this is where groupception could be applicable :P

[lukebarnard1]

The intention here is to use the Role of a user in a group to give the user more specific flair. For the first cut of groups (being released in v0.13.0) we decided to not provide UI for the Roles feature.