BUG: 190369
Details
Details
Diff Detail
Diff Detail
- Repository
- R119 Plasma Desktop
- Branch
- accesbility_dialog_improvement
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 6029 Build 6047: arc lint + arc unit
| kaccess/kaccess.cpp | ||
|---|---|---|
| 720 | can we choose another role here? | |
Comment Actions
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. | |
Comment Actions
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".
Comment Actions
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?"
Comment Actions
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).
Comment Actions
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:
Comment Actions
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.
| kaccess/kaccess.cpp | ||
|---|---|---|
| 870 | Let's use xi18nc() for this: xi18nc("@info", "<emphasis strong='true'>%1"</emphasis>, question) | |
| 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.... | |
Comment Actions
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. | |
Comment Actions
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. | |
Comment Actions
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? | |
Comment Actions
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.
Comment Actions
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.
Comment Actions
@amantia, if you would like to continue with this, could you move it to invent.kde.org? as a merge request for plasma-desktop? Thanks!