Mumble: Game overlay should be disabled by default

[bindi]

You need to restart your game after disabling the game overlay because it is injected, and that is quite frustrating to each user that doesn't appreciate the game overlay. Thus it should be disabled by default.

[toby63]

As this issue is quite old, I want to ask, what the status of the idea mentioned in this comment in Issue #3573, is?
Short summary of the idea: ask for enabling the overlay in the first setup wizard.
If its already implemented, i am sorry for asking, but as a longterm user, i am not running the setup wizard very often.

Also i would recommend to reconsider the opinion (stated by @Kissaki in this comment), that not many users complain about the default enabling.
Actually in my primary gaming group (>5 people) its the number one complaint.
It is also seen as very invasive, because it affects other applications (of course; even though its just optical) and some people don't realize at first, that it has something to do with mumble and how to disable it.
So I would recommend to disable the overlay by default, until a solution like the above idea is implemented.

[Krzmbrzl]

To my knowledge it hasn't been implemented yet and I also don't know of any work that is currently ongoing in that direction.

I do agree with the idea of disabling the Overlay by default as suggested by this issue and the discussion in the PR of @davidebeatrici.
@Kissaki argued that this way people wouldn't get to know about the Overlay in the first place and thus people won't use it. As it stands right now, this might even be true but in my opinion people should not be taught about a feature by slamming it in their faces. Instead this should be done by good documentation so that users will notice this feature if they just glance at it.

I also highly agree with the fact that the Overlay is certainly not something a user would expect from an application like Mumble and thus it might lead to trouble if it just pops up in a game.

@toby63 if you really have a bunch of people that would like the overlay to be disabled by default, please make them get a GitHub account and give the initial post of this issue their thumbs-up reaction. That way we can see that this is really what a lot of people want and I think it'll increase the likelihood of it actually getting implemented :)

[toby63]

@Krzmbrzl:
Thank you, I am glad that also people from the mumble team support this idea.

please make them get a GitHub account and give [...] thumbs-up reaction

Sadly that is very unlikely to happen and this is also the reason for my post, because I think that a lot of people out there don't like this feature (at least auto enabled), but they don't comment.
If there was a much easier way to participate, for example in some kind of poll (I know of the problems of course: authentification, spam, bots etc.), the participation is more likely, even though getting feedback (especially from a broad userbase) is (in my experience) always difficult.

[Krzmbrzl]

Sadly that is very unlikely to happen

Yeah I know that problem. On the other hand it can't be bothering them that much if they aren't even willing to give their feedback through the official channels which is a matter of like 5 minutes or so :man_shrugging:
If they want something to change, they have to invest those 5 minutes. If they don't then they don't get a say in what and how is being developed.

Don't get me wrong though: We appreciate every feedback we get but sadly a single person commenting that they know a bunch of other people that feel the same is absolutely unverifiable by us and thus we can't really rely on it. Now I don't suggest you're being dishonest but that doesn't change the facts...
(This does read like I'm trying to imply you not being honest, but I'm really not)

[toby63]

@Krzmbrzl:

On the other hand it can't be bothering them that much if they aren't even willing to give their feedback through the official channels which is a matter of like 5 minutes or so man_shrugging

I agree, at least for bigger and well-known platforms like github, but thats what i experience very often (e.g. as an advocate of open source software in my circles).
People are veery lazy and also full of mistrust (like they don't want to share their emailadress on "unknown"(at least to them) websites).
But maybe its just me knowing a lot of "crazy" people :smile: .

We appreciate every feedback we get but sadly a single person commenting that they know a bunch of other people that feel the same is absolutely unverifiable by us

I completely understand that problem.
I maybe also wouldn't believe a statement like mine.
Nonetheless I hope that the arguments are good enough to change something.

[Krzmbrzl]

I assigned myself to push this forward (internally) and to not lose track of the issue. Hopefully we'll be able to find a solution we can all live with :)

[Krzmbrzl]

@ZeroAbility just said on IRC that he also agrees to the overlay being disabled by default :point_up:

[Kissaki]

Personally I would like the onboarding experience to be better regarding this.

We do not generally see issues with the overlay enabled, so for a novice, default user I think having it enabled is not problematic. What that gives us and non-advanced users is discovery of this feature, and being able to use it at all.

If this is a problem, and as we have no better onboarding right now that would describe and offer it disabled within it (what is our welcome wizard right now) I am not (strongly) against disabling it though. If consensus is to disable it I am not objecting beyond that.

[Kissaki]

To address earlier comments more directly:

Also i would recommend to reconsider the opinion (stated by @Kissaki in this comment), that not many users complain about the default enabling.
Actually in my primary gaming group (>5 people) its the number one complaint.

<10 users is not a lot. We should not make big decisions and default experience decisions just from a very specific sub-group and people you can count on two hands.

I can see how users with prevalent ideology and very specific purity/separation ideas can see this as a bad default for them. But I will point to new and non-tech-savy users again. Most users do not care about injected processes as long as it does not produce noticeable slowdowns, graphical, anticheat or other issues.

It is also seen as very invasive, because it affects other applications (of course; even though its just optical) and some people don't realize at first, that it has something to do with mumble and how to disable it.

Did you see problems? Or is this an idealistic issue and concern of separation? We only inject into graphical API rendered applications.

[toby63]

@Kissaki:

<10 users is not a lot. We should not make big decisions and default experience decisions just from a very specific sub-group and people you can count on two hands.

My goal was just to say that there is an opposite position, as you seem to have the oppinion that there are no users complaining at all.
I found it very noticable that 9 out of 10 users I recommended mumble to, complained about this auto-enabling.
And just 1 or 2 users finding it useful, but these 2 would also like to enable (and modify before) it by themselves.

Did you see problems? Or is this an idealistic issue and concern of separation? We only inject into graphical API rendered applications.

As you are a Software Engineer i hope that you don't really think that it is common practice to interfere with other programs.
I hope that the standard approach of every program is, to keep things seperate as best as possible.
And this is not about technological details (like seperation on a technological level), as I already said, I am aware that this is "just" optical.
A user sees that Mumble is interfering with another program and some users don't like that, especially without any asking for permission to do so.

[toby63]

@Kissaki:
How should I interpret the :+1: ?

[Kissaki]

Your arguments make sense. I agree with their validity.

[ZeroAbility]

@ZeroAbility just said on IRC that he also agrees to the overlay being disabled by default ☝️

I would like to provide more context to my statement in IRC. It might be a better idea to offer the choice to the user to enable it or not as part of a welcome process. It could be in the form of a one time configuration on first install. That takes away the need to argue one position or the other and leaves that choice in the hands of the user.

[Krzmbrzl]

I agree to that. Having a first-time-welcome-wizard would probably be best and I guess other things could benefit from it as well :+1:

[toby63]

So I can assume consent that this should be changed?

[Krzmbrzl]

Appears like it.

However after having giving this some more thought I tend towards Kissaki's point of view in that regard as for users that are bothered by it, this is just one click in the preferences to change it.
Thus I think we should only remove it from being the default in combination with integrating that option into a startup wizard (I think we currently don't have one - I only know of the AudioWizard)...

[toby63]

Appears like it.

Sounds good.

However after having giving this some more thought I tend towards Kissaki's point of view in that regard as for users that are bothered by it, this is just one click in the preferences to change it.
Thus I think we should only remove it from being the default in combination with integrating that option into a startup wizard (I think we currently don't have one - I only know of the AudioWizard)...

Well honestly I disagree with that view.
As I have said earlier, this is actually a bigger break with common principles than you might think, I would recommend to either make a wizard rather fast, or disable this option by default in the meatime, till the wizard is implemented.

One thought about the wizard:
Sadly I am not a programmer, but wouldn't it be possible to just "copy" the audio wizard, call that the startup wizard and "simply" add a page with a checkbox for enabling the overlay?
This would set a value to true or false, which would be given to the normal config.

Edit: I want to add two things to the discussion:

1. Disabling it now wouldn't make a difference to old users, because their config should stay the same (?).
   It would only make a difference to new users, who can easily find that option directly in the configuration.
2. As far as I have seen, Teamspeak and others also don't have it autoenabled.

[Krzmbrzl]

I would recommend to either make a wizard rather fast, or disable this option by default in the meatime, till the wizard is implemented.

Well fast is relative. In either case I think this change won't be backported to 1.3 and will probably only be present in 1.4 which doesn't have a planned release date yet.
Perhaps it might also land in something like 1.3.1 or so but these patch releases typically include bug fixes and not changes in existing features.

With that I'm not saying that this can't happen but I think it won't be "fast" either way.

wouldn't it be possible to just "copy" the audio wizard, call that the startup wizard and "simply" add a page with a checkbox for enabling the overlay?

Absolutely. The question is if we could do better to yield something that might become handy in the future as well. Probably we could.
Using the AudioWizard as a starting point will probably be a good idea in any case though.

[toby63]

Well fast is relative. In either case I think this change won't be backported to 1.3 and will probably only be present in 1.4 which doesn't have a planned release date yet.
Perhaps it might also land in something like 1.3.1 or so but these patch releases typically include bug fixes and not changes in existing features.

With that I'm not saying that this can't happen but I think it won't be "fast" either way.

Yeah i already noticed your release "policy"...but thats probably a discussion for a different issue.

The question is if we could do better to yield something that might become handy in the future as well. Probably we could.

Well I might be wrong, but I don't see so much difference, isn't the wizard not "just" a window with buttons and checkboxes (yes i know the audio wizard is more complex than that, but many other things inside a wizard would probably not be so "complex") to set configs, so if you have more options in mind, they could be added with more pages inside the wizard (later).

I want to clarify that this is not meant to push things to hard.
But I think that this could be fixed easier than many other issues and that this should not be burried inside bigger changes (like some kind of completly new wizard).

[toby63]

Would you add a Milestone for this?

While I would prefer an intermediate solution with disabling by default, the mumble team seems to favor a wizard solution.
I took a look at the existing AudioWizard, the UI (AudioWizard.ui) and some code (like AudioWizard.cpp), it should be possible to add a page that adds a setting for the overlay.
The Wizard could even be kept just as it is now (because it is run on first-start of the program anyway).
Only if you want to seperate the re-run of the Audio Wizard from other (potencial) parts of a Startup Wizard, you would need to make an additional wizard (even though that could rely on the existing code as well).
I have to clarify I am not a programmer, so I only have a very basic understanding of this.

[Krzmbrzl]

As the audio wizard can be triggered manually as well, I don't think it really fits in there. I'd favor a general startup wizard for this.