Mark user as fiend / jerk / toxic

[promi]

Currently you can mark a user as a friend which is nice, especially if you meet them on another server.

It works like a favorite or bookmark function, but you can not choose whether the bookmarked user is your friend or someone who is causing trouble.

So the idea is that you can set a type of bookmark, either a friend with a heart or a jerk with something like the poo emoji and maybe a third option like a neutral bookmark.

[promi]

One use case is this: When a new user enters the root channel, you don't have to go there when you already marked that user as bad.

[Krzmbrzl]

I don't think this is necessary. Besides it comes at a loss of seriosity if you are able to assign poo emojis to clients...

#3967 seems like a much better approach to this by letting you assign a nickname to any user. That way you'd still see your set nickname even if the user changes its name.

I'll leave the ticket open for now to see if someone else thinks this is an important addition, but as I said: I'm not convinced.

[toby63]

🤔 Well most programs offer some kind of blocking mechanism instead.
In our case this could involve auto-mute and auto-block messages, maybe also block from marking as friend and block access to channels the user created (temporary channels).
Nonetheless some kind of label would be needed, otherwise you might wonder why someone is blocked, as you maybe don't remember blocking them.
But that should not involve something vulgar like a poo symbole.

[promi]

Of course the poo emoji was just an example … A sad face or a stop sign would be fine as well.

[Krzmbrzl]

Good point with the blocking-feature. I think that'd make more sense in my eyes 👍

Auto-muting and auto-ignoring of text messages sounds good. Blocking from marking as a friend is unnecessary imo as that's an action of the user and blocking is usually meant to be a protection of the user from someone else.
The blocking of channel-access likewise is not really needed imo. Furthermore access-blocking would have to be done on the server and thus it can't be done locally anymore ☝️

[TerryGeng]

So, to summarize, what is worthwhile to implement is to add two menu items:

1. Block This User: a dialog will show up with a set of checkboxes includes "Mute him locally" (maybe move the "Local Mute" option here), "Ignore text messages from him"
2. Mark This User As... (which will replace the current Add Friend option): a dialog will show up with a list of emoji or icons like heart, sad face, etc. which users can choose to mark the selected user and a "Nickname" text box.

Is there anything I left?

[toby63]

2. Mark This User As... (which will replace the current Add Friend option)

I would like to see two options:

• add as friend (or something similar, see below)
• give nickname

Or in case you only want one option, I would only take the "add friend"-option and just add the nickname-option inside it.
To make the title of the option more neutral, we could change it to add user to list/favorites (or something better 😉).

Regarding the naming and marking:
I would just let the user choose between Friend, Colleague (maybe more "standard values") or a custom value (this way everyone can decide for themselves what categories they want).
For those who want to use emoticons, they could be available in an optional virtual keyboard.

Regarding the labels for favorite users in the UI, I would prefer special user colours, Tags or something similar, but thats a question of taste.
Either way I would like to avoid having to use (more) emoticons (I am ok with the heart emoticon, but I don't like it so much).

[promi]

The reason I was asking for an icon of some kind was accessibility. I am actually asking for a user who is not very good with reading and writing, but is very fast with recognizing images.

[TerryGeng]

I agree with @promi. Using icons is just a trend, if I may say so. I think it is also a possibility if we can combine the text descriptor (like a tag) and the icon together.

Color is also something that can be considered. But I tend to make a choice between icon/tag and different colors since they are alike judged by their functions.

BTW I'm self-assigned to this issue and am going to work on it in the next few days.

[Krzmbrzl]

We could use a hybrid solution: Display a big image on the button but also add some text underneath it.

[Krzmbrzl]

In regards to being able to set a nickname for someone: That's #3967
You may of course still implement this all together. But if you do, we can close the linked issue as well :)

And please let's not use emojis for the icons. I think using emojis by default makes it a bit hard to get the application into a serious environment (e.g. a company). Instead we can create new icons in the theme and use those.

Block This User: a dialog will show up with a set of checkboxes includes "Mute him locally" (maybe move the "Local Mute" option here), "Ignore text messages from him"

I think for the different choices a sub-menu is more convenient than a popup. That'd mean that I'd hover over Block this user (or what I think might be more fitting: Modify user or something similar) and then the menu item expands to the different choices (local mute, local ignore, block)

Do you know what I want to express with that?

[toby63]

Regarding icons, we can use icons but as @Krzmbrzl said, no emoticons (imo).

I think for the different choices a sub-menu is more convenient than a popup

If I understand it correctly, I disagree.

1. Sub-Menus are always imprecise and annoying imo (I would avoid them whenever possible).
2. Users might want to choose two or all options at once (For example block audio and block text together).

[TerryGeng]

IMO menu itself is bad, I hate the menu bar of mumble. However, a new popup is also bad for me. I hate opening an individual window every time I want to do something. Especially I have two monitors and the new window always appear in the wrong monitor.

In this case, I prefer the sub-menu. And as you can tell in the following image

You can see, it is possible to "check" a menu item.

[Krzmbrzl]

Yeah I was thinking about something your screenshot @TerryGeng

[toby63]

I still dislike that a lot and believe me many other people will also.
This is far from being intuitive and good UI-design.

Longterm I favor a redesign with buttons (like my design concept in #3608 (comment) (see picture three especially)), so everything is shorter, better visible etc.
Shortterm I favor opening a new window.
Many programs I know will open a new window in such cases, also because they want to clearly ask the user whether they "really" want to block someone etc.

Especially I have two monitors and the new window always appear in the wrong monitor.

I am sorry for that, but:

1. thats a thing that will concern only very few users
2. aren't there solutions for that? I would think that the window opens on the screen you are currently using with your mouse, or always on the primary screen in case the desktop is "stretched"?

[Krzmbrzl]

@toby63

I guess it will be hard for me to find public available studies on that (but I will try).

My main point wasn't that you always need to present studies. I was only confused that I got a "believe me" answer to a request for an explanation/justification for which I expected some arguments to be presented instead (as you did with your last post) ☝️
(Though if you find some, please link them - I'd be interested 👀)

But as an alternative, maybe we don't need to seperate the options?

I think Terry has already illustrated that these options do have a right to exist on their own :)

I think that it's best to have most options directly visible, instead of "hiding" them inside something else.

To some extent this is definitely true. However at a certain point the list becomes so long that it does no ,longer provide a good overview.

And as I already said, a redesign with buttons could make this situation better.

While this could be true, I think we should focus on how we can integrate this feature into the current UI for now as a UI overhaul is not something that's just around the corner yet.

Well, we wanted to add a specific label to show that the user is blocked.
And yes it should apply everywhere all the time.

Ah yes indeed.

---

@TerryGeng

But if it goes beyond 1-layer I think I will go against it.

Yes, I definitely agree with that 👍

But based on the arguments above that only two options (block audio and block text message) are presented, I think we can just create two options in the right-click menu without creating a sub-menu. Does this idea make sense to your guys?

We already have these 2 options in the menu.

Maybe we should recap what new entries we want to add before continue the debate of where to but them ^^

If I understand this request correctly, we want

1. A Block user entry
2. A Mark user as... entry

I guess 1) is pretty straight forward, but what exactly do we need for 2)? We already have the mark as friend option and given that we already have the blocking of a user as a separate entry (or rather: "will have") I'm not sure what we need this separate entry for.

From the discussions so far I take it that what is actually wanted is to be able to set a local nickname for someone, which is strictly speaking a separate feature request. But even if it was to be implemented all at once, I don't think that a Mark user as... entry is really needed.

And to me it doesn't seem like there are more use-cases than marking as friend, blocking and changing the nickname 🤔

[toby63]

Well my concept would be this:

1. Keep mute user and block text from user (or whatever it is called correctly) as seperate and directly available options, because people already use that regularly.
   These options are now temporary (afaik).

2. Add a block the user option, which contains (and combines) both mute and block text and adds a label blocked to the user.
   This would be permanent until the user decides to remove it.

3. Regarding mark user as...:
   While I agree that setting a nickname would be very convenient, I think that technically the user has to be "remembered", just like the members of the friends list.
   So I would combine both options, add a user to a list and give a user a nickname(optional).
   This way we could add a nickname when we add someone to the list, or add/edit a nickname later in the friends list menu.

   • In addition I proposed to allow different custom groups/categories in the friends list, so I can sort people into groups like colleagues, friends, gaming etc.

I also added two thoughts about the set nickname option, in:
#3967 (comment)

[TerryGeng]

... I'm sorry that I didn't notice there is already an option to dismiss text messages from a user. So now it seems to me that I don't have to add a blocking user menu at all. I'm not sure if @toby63's idea of an individual option "block this user" (which is essentially a combination of the two) will be useful. Now if you block the audio/text message, an icon will appear to the right of that user and I think this is kind of a "blocked" label. I'm afraid a new "block this user" entry will unnecessarily confuse some people.

People may argue that most chat apps have some "blacklist" option. If we indeed would like to honor this tradition, I think to put these two options in a "block this user" sub-menu is the best way.

As for the "mark user as" option, based on the discussion above, I think people have agreed that we use icons to tag/category a user (just like currently we use a heart icon to mark a friend) instead of literal labels. Personally I think mumble now is wordy enough and I don't think it is good to put more pressure on users' minds by requesting them to read things.

As for a user whose nickname has been set locally, I think I will display the nickname on the user list instead of its original user name, but in a different color (like blue) or in italics. What's your idea?

[toby63]

I'm not sure if @toby63's idea of an individual option "block this user" (which is essentially a combination of the two) will be useful.

As I said the difference is the duration, block this user would be permanent, while the already implemented options are temporary.

People may argue that most chat apps have some "blacklist" option. If we indeed would like to honor this tradition, I think to put these two options in a "block this user" sub-menu is the best way.

What do mean by this exactly?
Because I would like to keep the already implemented options (mute and block text) the way they are and in place.

As for the "mark user as" option, based on the discussion above, I think people have agreed that we use icons to tag/category a user (just like currently we use a heart icon to mark a friend) instead of literal labels. Personally I think mumble now is wordy enough and I don't think it is good to put more pressure on users' minds by requesting them to read things.

Well then it will be "harder" to implement more groups like I proposed.
I see it like this:
If people don't use groups they will not see the labels.
Two other points:

• at least @Krzmbrzl and I are against using more emoticons, so what other Icons do you suggest?
• As an alternative I could agree on a color label.

As for a user whose nickname has been set locally, I think I will display the nickname on the user list instead of its original user name, [...]

I agree on this, but some users might want to see both names.
If you would implement it, I would make it like this:
Option 1: Just nickname like: Nickname
Option 2: Nickname + Original Name like: Nickname (Originalname)

[...] but in a different color (like blue) or in italics. What's your idea?

🤔 Yes a different colour seems to be the way most programs handle it.
But we might need to check whether this interferes with other functions.
At least it interferes with some ideas like #3538.

Labels might interfere with #1632 .

---

In general we would need to get some information about the functionality:

• Friends list: It seems to me that it is only visible when you connect to a server, so is it even stored locally?
  In case you (or someone else) extend(s) it, it should be visible all the time imo.
• Identification (for nicknames, lists and blocking): As I said in Possibility to set a local nickname for users #3967 (comment) using the regular user-certificate might be the wrong option, so we should talk about alternatives imo.

[Krzmbrzl]

As I said the difference is the duration, block this user would be permanent, while the already implemented options are temporary.

That's wrong. Local mutes and text-message ignores should be permanent provided the respective user has a certificate (they are saved in the client's DB). And if the client in question doesn't have a certificate there is nothing we can do anyways.

Option 2: Nickname + Original Name like: Nickname (Originalname)

I think this is probably best as this minimizes the chances of 2 users on a single server ending up being displayed with the same name.

Yes a different colour seems to be the way most programs handle it.

I'm not sure I like that. This could easily lead to Mumble becoming a confetti party. I don't think any additional highlighting is necessary if we choose option 2 (see above) for the naming.

so I can sort people into groups like colleagues, friends, gaming etc.

@toby63 what would this actually be useful for? I think this is not necessary.
If you need to group users, I think #1632 is the better approach.

Friends list: It seems to me that it is only visible when you connect to a server, so is it even stored locally?

I think it's also stored in the client's database

---

All in all I think though that we should continue discussing the nickname feature in #3967
The only issue that remains here is: Do we need a functionality to mark a user in some way (that is different from #1632)

[toby63]

That's wrong. Local mutes and text-message ignores should be permanent provided the respective user has a certificate (they are saved in the client's DB). And if the client in question doesn't have a certificate there is nothing we can do anyways.

Very interesting. I didn't know that.
Still I think it would be useful to have something (Terry called more fitting) like a "blacklist", so that we really have a list of people that we blocked permanently.
Also a "real" blocked label in the UI would be good, though I can't remember what the already implemented solution looks like now.

This could easily lead to Mumble becoming a confetti party. I don't think any additional highlighting is necessary if we choose option 2 (see above) for the naming.

Well if we (like I) don't want option 2 (though it should be implemented as one of the options of couse), it would be good to have some kind of "marker".
And one colour is not a confetti party; also I guess you are then against all the other feature requests with colours?

what would this actually be useful for? I think this is not necessary.
If you need to group users, I think #1632 is the better approach.

🤔 Well grouping of lists is always a useful feature imo (especially for larger lists), but it's of course low priority.
And #1632 is a completely different case, its about groups on servers not local groups only I can see.
Though I already mentioned that this might interfere with each other, but there could be solutions to that.

Also just to mention it, the original request in this issue is, to be able to create a list of people the user doesn't like and mark them as such.

[Krzmbrzl]

Also a "real" blocked label in the UI would be good, though I can't remember what the already implemented solution looks like now.

Right now we have a more fine grained indication in the UI. We have a label for local muting and I think local textmessage ignore has also a custom icon.
Not sure we need additional icons 🤔

And one colour is not a confetti party; also I guess you are then against all the other feature requests with colours?

One is indeed not. But if you are using multiple categories (as was suggested somewhere above), then you'll get different colors for each group and then it'll be too much (imo).

And #1632 is a completely different case, its about groups on servers not local groups only I can see.

Good point

So I guess the discussion is then down to how to represent users of a given group ☝️

[toby63]

Not sure we need additional icons thinking

Well my point is only about a more clear presentation.
For example if someone wants to block someone and searches for it, they might not realize that it can be done with the mute and text-block features permanently.
So a seperate block option with a blocked label or icon might be an idea.

One is indeed not. But if you are using multiple categories (as was suggested somewhere above), then you'll get different colors for each group and then it'll be too much (imo).

🤔 Yeah I guess that's debatable. I can't say for sure, whether I would be bothered.
But as I already said, it would only be visible for people who activate it, so it doesn't matter for everyone else.
In addition we could make the label optional, so that the users can create groups but don't need to label them.

So I guess the discussion is then down to how to represent users of a given group ☝️

If that is implemented, yes.
A less extensive alternative would be to just implement two groups, people you like (friends) and people you don't like (blocked or a third group of fiends (or a better name)), as that would fullfil the request in this issue.

[TerryGeng]

If I have to make a choice between colors and icons, I will definitely choose icons because improper choices of colors will easily make texts indistinguishable and not fit in the rest of the theme of our GUI. On the other hand, icons won't damage the text, so I think is pretty much a good choice.

As for

So a seperate block option with a blocked label or icon might be an idea.
My opinion is blocking audio/message will both display very visible icons(IMO they are highly visible). Did you try these two options and see the icons they displays? @toby63

Anyway I'd like to implement the "blacklist" feature, just to honor the tradition of chat apps. What I plan to do is adding a "Block this user" sub-menu, with the following options:

• Mute him locally,
• Ignore his text message,
• (a horizontal line),
• Block all activities from him.

With the last option selected, the two previous options will be automatically displayed as checked, and a special block 🚫 icon will be displayed instead of two separate icons.

[toby63]

@TerryGeng

If I have to make a choice between colors and icons, I will definitely choose icons because improper choices of colors will easily make texts indistinguishable and not fit in the rest of the theme of our GUI. On the other hand, icons won't damage the text, so I think is pretty much a good choice.

While in theory I would agree, the problem is:
What icons exactly?
And how many of them?

I think Labels would be far easier and customizable.

What I plan to do is adding a "Block this user" sub-menu

I mostly agree, but I would still just combine both options, without the choices, because if I blacklist somebody, I don't want any communication.
If someone wants that, they can still use the usual options with mute and block text.
And as a result I would always show the block icon.

---

Ok to summarize it (correct me if I am wrong):
We keep:

• mute option (as it is)
• block text option (as it is)

You would implement:

• Blacklist feature (including block icon)
• Groups in Friendslist with icons
• User Nicknames, with two options:
  • Option 1 (default): Nickname (Originalname)
  • Option 2: Nickname - just the Nickname

Open Questions are still:

• Should the blacklist feature include seperate choices for mute and block text?
• What should Group Icons look like? (or should they be labels)?
• Should the Nickname option be included in the friendslist(-option), or be a seperate option?

[Krzmbrzl]

I mostly agree, but I would still just combine both options, without the choices, because if I blacklist somebody, I don't want any communication.

I think Terry wants to move the currently existing local mute and ignore text messages entries into the block submenu and in addition to that this will then also contain a "block user" button.

[toby63]

I think Terry wants to move the currently existing local mute and ignore text messages entries into the block submenu and in addition to that this will then also contain a "block user" button.

Ok, I understand, but I would not do that.
I suppose many people use the function to mute people very quickly.
Adding one step will make some people "angry".

[Krzmbrzl]

For real quick access I think we can provide shortcuts (if we don't have them already - not sure atm).
On the other hand I don't really expect people to be in such a hurry that they can't afford to open a single submenu 🤷

[TerryGeng]

Sorry for the guys who are watching this PR. I haven't made much progress since I was working on v7.1 of https://github.com/azlux/botamusique this week.

I'm going to start this weekend and hopefully will show people the result before next week.

@toby63
I'm sure that any change in the UI would irk some people. I know... this is how things work and people should get used to it.

[toby63]

For real quick access I think we can provide shortcuts (if we don't have them already - not sure atm).
On the other hand I don't really expect people to be in such a hurry that they can't afford to open a single submenu shrug

I'm sure that any change in the UI would irk some people. I know... this is how things work and people should get used to it.

We shouldn't make steps backwards.
Especially if they are unnecessary.