Make the button's purpose more clear
Needs ReviewPublic

Authored by amantia on Dec 12 2018, 11:15 AM.

Details

Summary

BUG: 190369

Diff Detail

Repository
R119 Plasma Desktop
Branch
accesbility_dialog_improvement
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 6104
Build 6122: arc lint + arc unit
amantia created this revision.Dec 12 2018, 11:15 AM
Restricted Application added a project: Plasma. · View Herald TranscriptDec 12 2018, 11:15 AM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
amantia requested review of this revision.Dec 12 2018, 11:15 AM
kaccess/kaccess.cpp
720

can we choose another role here?

amantia planned changes to this revision.Dec 12 2018, 12:54 PM

Will have to rework, I missed some cases(the dialog might as to activate. deactivate or "activate some, deactivate others"), it is not as simple as I thought.

kaccess/kaccess.cpp
720

Oops.

amantia updated this revision to Diff 47441.Dec 12 2018, 1:06 PM

Reworked, by reshuffling the dialog text, instead of renaming the buttons

How it looked before:


How it looks now:

ngraham requested changes to this revision.Dec 14 2018, 2:18 PM
ngraham retitled this revision from Make the button's purprose more clear to Make the button's purpose more clear.
ngraham added a subscriber: ngraham.

While we're here, let's change yes to Accept and No to Cancel. Also, the dialog's title should probably be something more descriptive than "Warning".

This revision now requires changes to proceed.Dec 14 2018, 2:19 PM

You can't change to Yes/No (that was my first try), as the question might be one of the following:

  • "Activate foo ?"
  • "Deactivate foo?"
  • "Activate foo and deactivate bar?"
amantia updated this revision to Diff 47590.Dec 14 2018, 8:03 PM

Improve dialog title as well

You can't change to Yes/No (that was my first try), as the question might be one of the following:

  • "Activate foo ?"
  • "Deactivate foo?"
  • "Activate foo and deactivate bar?"

In that case, OK/Cancel would at least be better than Yes/No.

I'm not a native speaker, but I don't see how OK/Cancel is better. The dialog shows a question that can be answered with Yes or No.
See also the HIG https://hig.kde.org/components/assistance/message.html

  • Apply confirmation button labels when further interaction is required:

    Use buttons which match the type of statement or question made in the warning or error message. For example, do no ask a Yes/No question but then provide OK/Cancel buttons.
  • Apply confirmation button labels when the user must choose between two actions to continue:

    Use descriptive button labels instead of standard Yes/No or OK/Cancel buttons. For example, if the user must choose to continue or stop an action, provide the buttons “Continue” and “Cancel”.

I cannot easily do the second (and don't want to with this patch).

All dialogs ask a question that can be answered with a yes or a no. The problem is that most users don't read dialog box text--especially very long text, like the kind presented here. They do generally read the dialog box button labels though, which is why it's so important that the labels indicate what the buttons do. I can understand if you don't want to do that in this patch though.

IMHO we should work towards allowing the button labels to be customized alongside the dialog box text. As is, this patch doesn't really improve much because the text is already so long that nobody will read it, no matter which order the strings are presented in. If there's no way to simplify the text, perhaps we could should use bold text for the important part? This is what we do for Dolphin's "permanently delete this file" dialog:

amantia updated this revision to Diff 47661.Dec 16 2018, 11:56 AM

Make the question text bold

Yes, most questions can be answered with Yes/No, and still I'd say it is better to use Yes/No, instead of OK/Cancel. OK/Cancel is rather useless, although widely used, I know...
I made the question text bold now, and unfortunately as I said I don't want to spend more on this. The whole dialog is problematic as it poses both a question (activate/do not activate) and a side question (turn off gestures or not).
This is confusing by default, and for the users it was unclear what the dialog buttons do, as the original question was at the beginning and between the question and the action buttons there was the large explanation with the secondary action.
At least (IMO) now it is clear that the Yes/No buttons refer to the activate/deactivate question.

ngraham added inline comments.Dec 16 2018, 8:37 PM
kaccess/kaccess.cpp
870

Let's use xi18nc() for this:

xi18nc("@info", "<emphasis strong='true'>%1"</emphasis>, question)

amantia abandoned this revision.Dec 16 2018, 9:35 PM
amantia added inline comments.
kaccess/kaccess.cpp
870

That looks weird., as it creates a translatable string for no reason. Obviously best would be to update all strings to have the bold text in it, but that creates lots of new strings for no good reason....

amantia reclaimed this revision.Dec 16 2018, 9:38 PM

I also find the text rather confusing (thank you for working on this!).
What is AccessX? And why should I care as a user? I need the feature...

On the other hand, this patch is simple, self-contained, and in my opinion a clear improvement, so I'd vote for taking in this change and in parallel making further improvements on top of it.

kaccess/kaccess.cpp
870

I'd say updating all strings is good. Translators should have support from their tools (translation memory) and we will eventually have to move forward.

amantia updated this revision to Diff 47712.Dec 17 2018, 10:18 AM

Change the individual texts

I perfectly agree with Frederik. There is room for improvement, but my intention was not to completely change it, just to make it slightly more clear what this is about. The rest can be fixed in a separate commit, if anyone is interested to do it. :)

kaccess/kaccess.cpp
870

I did, although disagree, as it makes the change not easily backportable. I also couldn't test/trigger all cases.

pino added a subscriber: pino.Dec 17 2018, 10:32 AM

Regarding the use of bold: please note that using bold in some languages (usually eastern ones) either is not possible, or it does not make sense. So please do not solely rely on it to convey anything.

kaccess/kaccess.cpp
671

Since you are changing this string: can you please use Title Capitalization as described in the HIG?
Also, adding a context like "@title:window" will help distinguish this as title.

amantia updated this revision to Diff 47714.Dec 17 2018, 10:47 AM

Use title case

Ping? I'll push this if there are no strong objections.

pino added a comment.Jan 7 2019, 10:47 AM

I'm personally still not convinced about the usage of the bold for questions, as I wrote in an earlier comment.
The rest is not up to me.

I understand that, of course. I think the question is: is this an improvement or not? I think it is (not perfect, has problems, but an improvement), but if considered to be not, I will just abandon it, no hard feelings.