Thanks for this detailed report. You’re missing the main goals of this warning dialog, but your complains highlight some prossible improvements of the current implementation.

(In reply to Stephen from comment #0)
> * dconf should be lower-case
> * "configuration" should be singular
> * "option" should be plural

The last one is corrected in 3.20.1, I keep the two others in mind for now (they are changing the meaning a little, so translations would have to be synced).

(Selecting and reordering your points for the answer.)
> * Having a ticked "Show this dialog next time" checkbox requires two clicks
> if the user wants to permanently dismiss the dialogue box.

That’s probably your main problem with the current implementation: you hate being warned (as you consider you know what you’re doing), so you want to dismiss any warning you see in one click (you accept there’s one for people who don’t know what they’re doing), and never see it again when dismissed. And you think most people should be like you, that’s why you suggest having a hateful warning in red poluting the view of the application with a permanent info bar until dismissed.

One thing that could be done here is to have a clickable label (GtkLink ?) that closes the dialog, instead of a checkbox. But it needs the good wording, and need to not be too visible (see explained goals after).

> * "Thanks for using" messages are normally the domain of commercial
> applications and don't help the user. In this case it also detracts from the
> more important warning.

The goal of this dialog is not to ensure the user knows it could do something bad with this application, making it the only responsible when something really goes wrong. The goal of this warning is to remind users that they should act carefully with this application. That’s why this warning is displayed at the beginning only, that’s also why it’s friendly (no need to hurt, we should be happy to be warned on dangerous things), and why it’s not really important to have the warning as the main text (it’s just giving a time to the user to think twice).

I don’t react to the “commercial application” thing, as I don’t see how that makes a difference: dconf-editor is not installed in any default desktop (for what I know) and probably shouldn’t, so it will always be an “external application”; and then, it looks like a good thing to thank users to have installed it. But one interesting thing is that these messages usually “don’t help the user”: should the wording be changed because of that ?

> * The wording/UI comes across as a bit parental in tone to me - "Don't
> forget"/"so be careful", and it insists on the user clicking (i.e. making
> them "say") "I'll be careful".

You say “parental”, I say “friendly”, but that’s the same idea. Do you see any better text here, knowing the use of this dialog ?

> [red info bar solution]
> This:
> * Doesn't get in the way of using the application on first run.

Interesting note. The warning should probably be displayed in the main window instead of in an “overlay” dialog, so it will be obvious that it is an important part of the application.

Another related improvement path is to delay the warning until the user knows it wants to change something (letting it explore the keys before), but that have to be carefully designed: it shouldn’t interrupt the user in its workflow. One idea is to have an “unlock” button, that conforts the user it couldn’t do something bad until it clicks it, and permits to warn just before something dangerous could be done.

---

An other possible improvement could be to never warn again in a given timing.

On the language items:

* dconf should be lower-case (see the actual application title, man pages, the GNOME wiki page on dconf etc.), I don't know if you're saying it shouldn't or just that it needs to be delayed to allow for translation work etc.?
* I believe you may be using "configurations" when the suitable word in English would be "settings"? Each single item is a setting or "configuration item", and the entire set is "settings" or "configuration".
"Configurations" is ordinarily only used when referring to comparable sets, e.g. "the user tried using the application with several different configurations".

In relation to the message delivery method, the idea of using an info bar instead of a modal dialogue is that it delivers an important message without blocking the use of the application, and I think you agreed above with the use of an info bar in principle? Also, from the GNOME HIG (https://developer.gnome.org/hig/stable/design-principles.html.en):

    "...always avoid spontaneously popping up dialogs without user intent, and avoid disruptive feedback mechanisms like message dialogs."

In terms of colour, red was only an example colour suggested to draw the most attention to the info bar and make sure the message isn't missed, since it is non-blocking. It could also be orange, yellow etc.

In terms of text, the only change in my suggested wording that increases the intensity of the message is from "careful" to "warning", which isn't "hateful" in any case. "Warning" could also be replaced with "Caution".

Re. my perspective on the "thanks for using" message, it is also supported generally I think by the GNOME HIG (https://developer.gnome.org/hig/stable/design-principles.html.en):

    "When adding a new control or piece of information, always take a moment to question whether it is necessary."

In terms of the text itself, I completely understand that the intent is not to absolve the developers/distributors etc. of responsibility but instead to help the user avoid breaking things.

I am a fan of straight-forward wording, but in any case, with the current wording, the difference between what I see as potentially coming across as parental in a negative sense, and what you see as friendly might be that the current phrasing is imperative:

"Don't forget", "so be careful" - commands;

vs. for example:

"Please don't forget", "so please be careful - requests.

And additionally at present the user has to "promise obedience" - "I'll be careful" - before being able to proceed, hence my suggestion of "OK" instead. "Understood", "I understand", or "Got it" would also avoid the potential for negative connotation.

Some modified alternatives:

    Careful: changing configuration using dconf Editor may break things. [Understood]

    Changing some options may break applications/GNOME, so please be careful. [Got it]

The unlock mechanism is an interesting idea, but I think you're right that it would be a difficult one to get right without interrupting the user. In addition, the "Unlock" pattern is always used for privilege escalation (PolicyKit) where I've seen it, so using it in this case would risk diluting that use of the "Unlock" pattern.

Also, I'm sure it wasn't your intention, but I think "you think most people should be like you" and "you suggest having a hateful warning" are not fair characterisations. Though it hasn't put me off, I think there's a risk that other users might be deterred from filing useful bugs if they were characterised similarly.

That said, your response is much appreciated!

(In reply to Stephen from comment #2)
> Also, I'm sure it wasn't your intention, but I think "you think most people
> should be like you" and "you suggest having a hateful warning" are not fair
> characterisations. Though it hasn't put me off, I think there's a risk that
> other users might be deterred from filing useful bugs if they were
> characterised similarly.

Sorry for these words, I should have made clear that I was presenting (the worst) comments that could be made in a real situation implying such an UI. That’s an important thing for me, finding a design that cannot be harschly commented, so I tend to forgot to talk about it.

> * dconf should be lower-case (see the actual application title, man pages,
> the GNOME wiki page on dconf etc.), I don't know if you're saying it
> shouldn't or just that it needs to be delayed to allow for translation work
> etc.?

I’m not happy with the (historical) “dconf Editor” typography, as it quite lost its meaning: this program is mainly a “GSettings editor” already, and other changes could even happen in a near future (for the “xdg-app transition”). The correct fix will be to rename the app’, but for 3.20, I’m hesitating because of the translations that has been based on the “Dconf Editor” typography.

> * I believe you may be using "configurations" when the suitable word in
> English would be "settings"? Each single item is a setting or "configuration
> item", and the entire set is "settings" or "configuration".
> "Configurations" is ordinarily only used when referring to comparable sets,
> e.g. "the user tried using the application with several different
> configurations".

I see. I switched to “settings”, it will be available in 3.20.2 if there’s a need for such a release.

> In relation to the message delivery method, the idea of using an info bar
> instead of a modal dialogue is that it delivers an important message without
> blocking the use of the application, and I think you agreed above with the
> use of an info bar in principle?

Info bars are for explaining the state of the view, not for delivering all warning messages. It would be adapted for warnings like:
  “dconf database is read-only, no writes can be done [×]”,
  “dconf database is read-only [give me super power] [×]”,
  “unable to connect to the dconf service, only using gsettings [×]”,
  “dconf looks unused, you’re probably using another GSettings backend [disable dconf forever] [×]”,
but not:
  for displaying a general warning about the dangerousness of the application,
  for thanking the user for using the app’,
  for explaining there’s a help hidden somewhere about gsettings.

> Also, from the GNOME HIG
> (https://developer.gnome.org/hig/stable/design-principles.html.en):
> 
>     "...always avoid spontaneously popping up dialogs without user intent,
> and avoid disruptive feedback mechanisms like message dialogs."

The dialog is not “popping up”, it is not “interupting the user”, it’s present at the opening of the window. Yes, it’s using a widget for something that is not its perfect role. A full-window message is planed for someday (3.22?), but for 3.20 it looked bad when transitionning with the paned-layout content (and is not going to change now).

> Re. my perspective on the "thanks for using" message, it is also supported
> generally I think by the GNOME HIG
> (https://developer.gnome.org/hig/stable/design-principles.html.en):
> 
>     "When adding a new control or piece of information, always take a moment
> to question whether it is necessary."

Thanking the user is not really necessary, but is used here to make a (necessary) warning look friendly, even as the first contact with the application. Instead of a thank, an informative text might also fit there.

  Registry is designed for editing the settings in a direct way.

  It knows about settings stored by your system or installed applications
  using either dconf or the standard gsettings backend of your session.

  Please don’t forget that some options may break applications, so be careful.
  
  -------------------
  | I’ll be careful |
  -------------------

Would that be better? (including here a potential app’ renaming and a less imperative tone.)

> And additionally at present the user has to "promise obedience" - "I'll be
> careful" - before being able to proceed, hence my suggestion of "OK"
> instead. "Understood", "I understand", or "Got it" would also avoid the
> potential for negative connotation.

People who already know about this dialog won’t reread it completely, but (if not using the keyboard…) they will take time to reread the content of the button. That’s why it’s important in my mind to keep warning in the button, like does the current text (it’s even simplier than what Firefox does on its about:config page…), or like would an “Enter danger zone” for example (but such messages either play with a physical metaphor or look too negative). “Understood” or “Got it” do not keep that property.

> The unlock mechanism is an interesting idea, but I think you're right that
> it would be a difficult one to get right without interrupting the user. In
> addition, the "Unlock" pattern is always used for privilege escalation
> (PolicyKit) where I've seen it, so using it in this case would risk diluting
> that use of the "Unlock" pattern.

I agree. The good way of doing thing would be to have polkit protect the writing in schemas not belonging to the app… but that’s an other story.

(In reply to Arnaud B. from comment #3)
> I’m not happy with the (historical) “dconf Editor” typography, as it quite
> lost its meaning: this program is mainly a “GSettings editor” already, and
> other changes could even happen in a near future (for the “xdg-app
> transition”). The correct fix will be to rename the app’, but for 3.20, I’m
> hesitating because of the translations that has been based on the “Dconf
> Editor” typography.

Fair enough. In the meantime IMO the capitalisation of Dconf will look inconsistent/like a mistake, but if it's a pain to lower-case it then that's life ;)

> Info bars are for explaining the state of the view, not for delivering all
> warning messages. It would be adapted for warnings like:
>   “dconf database is read-only, no writes can be done [×]”,
>   “dconf database is read-only [give me super power] [×]”,
>   “unable to connect to the dconf service, only using gsettings [×]”,
>   “dconf looks unused, you’re probably using another GSettings backend
> [disable dconf forever] [×]”,
> but not:
>   for displaying a general warning about the dangerousness of the
> application,
>   for thanking the user for using the app’,
>   for explaining there’s a help hidden somewhere about gsettings.

That's one of the uses mentioned in the HIG, but another is "they can also be used to present supplementary information, such as user guidance."
 
> The dialog is not “popping up”, it is not “interupting the user”, it’s
> present at the opening of the window. Yes, it’s using a widget for something
> that is not its perfect role. A full-window message is planed for someday
> (3.22?), but for 3.20 it looked bad when transitionning with the
> paned-layout content (and is not going to change now).

It's interrupting the user in the sense that it interrupts the launch application -> edit settings flow, which was the driver for my suggestion of the info bar as an alternative. Is there a disadvantage you see to using a non-blocking message given the downsides I've mentioned to the modal dialogue approach?
 
> Thanking the user is not really necessary, but is used here to make a
> (necessary) warning look friendly, even as the first contact with the
> application. Instead of a thank, an informative text might also fit there.
>
>   Registry is designed for editing the settings in a direct way.
> 
>   It knows about settings stored by your system or installed applications
>   using either dconf or the standard gsettings backend of your session.
> 
>   Please don’t forget that some options may break applications, so be
> careful.
>   
>   -------------------
>   | I’ll be careful |
>   -------------------
> 
> Would that be better? (including here a potential app’ renaming and a less
> imperative tone.)

Haha, whatever you do, don't rename it "registry", you'll give Windows refugees flashbacks and nightmares ;) ;)

I think making the message even longer is a mistake - it will decrease the likelihood that the user will read it at all. Regardless of the delivery method, conciseness will increase the message's effectiveness.

The secondary information (what dconf Editor does etc.) could be linked-to content.



> > And additionally at present the user has to "promise obedience" - "I'll be
> > careful" - before being able to proceed, hence my suggestion of "OK"
> > instead. "Understood", "I understand", or "Got it" would also avoid the
> > potential for negative connotation.
> 
> People who already know about this dialog won’t reread it completely, but
> (if not using the keyboard…) they will take time to reread the content of
> the button. That’s why it’s important in my mind to keep warning in the
> button, like does the current text (it’s even simplier than what Firefox
> does on its about:config page…), or like would an “Enter danger zone” for
> example (but such messages either play with a physical metaphor or look too
> negative). “Understood” or “Got it” do not keep that property.

I see your point about button wording that's meaningful in isolation (a long-standing and sensible GNOME HIG item). "I understand the danger" or similar would meet this requirement without the obedience connotation. Actually, the Firefox about:config warning has the same "obedience promise" problem, I noticed that a long time ago when they introduced that ;)

So to try and bring together everything so far, I'd suggest:

* An info bar
    * HIG seems to support the use under "user guidance"
    * Can be very visible and persists until the user acknowledges it (like the dialogue box)
    * But doesn't get in the way of editing (for seasoned users)
    * Needs zero clicks to have it show next time, and only one click to permanently dismiss (less clicking)
* A short message - increases the chance the user will read the important bit
* A link to further info about dconf Editor
* A meaningful button message, without an "obedience promise" and the possibility of that negative connotation

Something like an orange or yellow bar as follows:

    Welcome to dconf Editor. Changing some options here may break your system, so please be careful! __More info__ [I understand the danger!]

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/dconf-editor/issues/17.