Group-Members Usability Enhancement

[d3xter]

Hey guys,

So I started using mumble lately and I found a rather strange usability issue.

For example:

I'm not really sure if d3xter is now a member of the group or not without asking someone or reading through the source code.

So here is an idea of how i would design the Group-Members UI:

On the left side, all current members of the group are listed and on the right side only members who are not yet inside this group. . If the user wants to add a new member to the group, he just have to select him in the right list and press the "<< Add" button. The user will be removed from the right list and appended to the left list. Removing a member from the group is as simple as selecting the user on the left list and pressing "Remove >>".

What do you guys think about that?

[Lucatir]

+1

[fwaggle]

I think this is missing the functionality of the "remove" section?

I haven't really played with it, so forgive me if my impressions are wrong... but it's my understanding that you can say, add user d3xter to the group in the root channel by putting them in the "Members" box of the root channel, and set it to propogate to subchannels. Then further down in a subchannel, you can add them to the "Excluded" box and those group permissions will not apply in that channel.

I'm not really sure what the behaviour is if the user is in the "Members" and the "Excluded" box at the same time, that would certainly want clearing up.

[d3xter]

As seen in my second screenshot, we could distinguish between "d3xter (inherited)" (Which will be removed from the group members, when it gets removed from the parent channels group), and the user "d3xter" (Which wont be removed by any change from any of the parent channels).

A good idea would be to link them together, so if either one gets added to the group, both get removed from the right side.

[hacst]

This design omits some functionality present in the original one e.g.:

• Cannot disable/enable inheritance as a whole anymore for the group
• Cannot explicitly exclude someone which might later become an inherited member
• Cannot explicitly add someone which might later no longer be inherited

Also the available member design would definitely need to have a filter option as it would have to display all registered users on the server which might be quite a lot. I'm not a big fan of those move from left to right designs but I agree that the current design isn't exactly great....

[hacst]

As talked about in IRC here a potential alternative design:

Design goals:

• More intuitive
• Not bigger in h and v
• Better suited for bigger groups

[fwaggle]

Is the italics to show a user is inherited?

[hacst]

Yeah. Hardly ideal though. Don't have a better idea though.

[d3xter]

How cumbersome is it to change the background/font-color of a list entry in Qt?

What should happen if Flubber is inherited, but added manually afterwards too? Should the inherited Member be replaced? Do we show both in the left list?

Should it be possible to move an inherited member from "Members" -> "Potential Members" or only from "Members" -> "Excluded"?

[hacst]

• Changing the background/font is trivial. However we usually try to avoid using hard-coded color as you have to be pretty careful not to break system and mumble themes. We can use what's in the system palette though.
• I'd say explicit adding replaces the italic entry (if we can think of a visual signal telling the user that this is also inherited that would be helpful. Maybe make it bold? Mew). If you then remove the explicitly added one the italic entry re-appears.
• The remove button should be disabled for the inherited members and they should still be available as "Potential members" for explicit adding and exclusion (the mockup doesn't correctly show that).

Another display issue exists with exclusions. If we have an inherited entry in members what happens to it when an exclusion for it is added. Imho removing the inherited entry in members might send the wrong signal. I think a strike-through font to indicate its exclusion would work.