Hi,

the new Plasma 5 design looks clean and pleasant. However, I noticed a usability issue with how checkboxes are presented in combination with a row selection. Look at the following images individually:







Especially the last one looks - at first, unconcentrated glance - as if there were three deselected items in a row which is not true.

Additionally, the current design seems to conflict a bit with the appearance of a the "tristate/intermediate" state:

(taken from https://en.wikipedia.org/wiki/Checkbox)

Suggestion: use the check mark (as in the screenshot) for the "checked" state.

There's no problem with tristate boxes, you'll get a half filled box in case of a partially checked item.

That's a FRI (frequently reported issue). Conclusion from viewtopic.php?f=285&t=123108
"The design was tested successfully". (Other discussions might have run on the mailing list, don't remember.)
Personally I agree with you. But in fact the problem is somewhat academical. Did you ever had problems to acknowledge the state of a checkbox?

The actual problem identified here is with the appearance of the checkbox when highlighted, for which there already exists a bug report and a proposed solution that does not require changing the design of the checkmark (which, as pointed out, has already been discussed). Still, we're certainly grateful you took the time to consider the issue and propose a solution.

Heiko Tietze wrote:Personally I agree with you. But in fact the problem is somewhat academical. Did you ever had problems to acknowledge the state of a checkbox?

Yes. In form of having to look twice instead of grasping the situation at one glance (especially when all checkboxes in a menu or dialog are "checked" or sometimes in highlighting situations). That's why I thought the issue is worth reporting.

Thanks for the reference (viewtopic.php?f=285&t=123108). For me this reads as if there are indeed some good arguments against the new checkbox design. I am not an expert in UI studies; was the new checkbox also tested directly against the previous checkmark checkbox?

I am missing arguments which explain why the checkmark checkbox was not good enough anymore.

alake wrote:The actual problem identified here is with the appearance of the checkbox when highlighted, for which there already exists a bug report and a proposed solution that does not require changing the design of the checkmark (which, as pointed out, has already been discussed). Still, we're certainly grateful you took the time to consider the issue and propose a solution.

I am curious how this issue is going to be resolved. For me as user the situation currently looks like this:

* Familiar checkmark: recognizable in all situations
* New square solution: there are some situations which have at least discussable usability

I don't know why exactly the checkmark was abandoned, but considering the end result, it seems questionable to me.

Thanks for appreciating the input. Please also note that all things considered I perceive the Breeze theme as an elegant, modern and very likeable theme.

I suppose this has been discussed and arguments rejected, but I'll add my voice to the contrarians:
- Good old check mark is absolutely intuitive i.e., familiar, and there is no question if the box is checked or not.
- This thing looks like a radio button or an empty checkbox with blue background.

For clarity, the problem reported is the readability of the checkmark when highlighted. There are many potential solutions to that problem, one of which is to use a traditional tickmark for the checkmark design. The problem with the readability of the checkmark when its corresponding line item is highlighted has been reported (https://bugs.kde.org/show_bug.cgi?id=343428) and a solution has been proposed.

Changing to a traditional checkmark might be a way to solve the problem but in my view, I'd like to give an opportunity for the currently proposed solution that preserves the current design to be implemented. I totally understand there is a segment of very well-meaning folks that would prefer a traditional tickmark design. But I'd really like to try to solve the specific issues raised within the current design before revisiting the basic design of this control.

gregormi wrote:Thanks for the reference (viewtopic.php?f=285&t=123108). For me this reads as if there are indeed some good arguments against the new checkbox design. I am not an expert in UI studies; was the new checkbox also tested directly against the previous checkmark checkbox?

It was not.

I am missing arguments which explain why the checkmark checkbox was not good enough anymore.

The Breeze checkbox wasn't designed that way because the Oxygen checkbox was "not good". It was a pure aesthetics based decision. The test was only performed to make sure that this aesthetics-based decision would not cause usability problems. The test did not include a scenario with a checkbox in a listbox or tree (the only occasion where the highlight problem can even come up) because that had not even been defined at the point.

Yes, it would have made sense to test that. We forgot. Mistakes happen.

gregormi wrote:

alake wrote:The actual problem identified here is with the appearance of the checkbox when highlighted, for which there already exists a bug report and a proposed solution that does not require changing the design of the checkmark (which, as pointed out, has already been discussed). Still, we're certainly grateful you took the time to consider the issue and propose a solution.

I am curious how this issue is going to be resolved.

The proposed solution (see https://bugs.kde.org/show_bug.cgi?id=343428 ) was to not invert the colors of the radio button when its accompanying line in the tree or list is highlighted. This would solve the problem.

gregormi wrote:New square solution: there are some situations which have at least discussable usability

These situations have to be identified and the designers have to find solutions for them if they want to keep their design.
I tend not to question designers' choices as such. I point out usability problems, and ask them to find solutions to them. As long as they can find solutions to all usability problems I come up with, they can stick with their designs, whether I personally like them or not.

Finding a coherent visual design language is their task. Mine is making sure it does not lead to usability problems. Sometimes, I fail to identify one of these problems immediately. In those cases, all I can hope for is that others find them.

I will boldly rephrase that the issue in the laid out context is that the indicator is too big, what can make the empty space around it look like a frame.

The "familiar" argument is nonsense.
The Breeze design follows the Motif one in matters of shape - that's "familiar" - except of course you meant "familiar for me, because I'm used to the windows look".
In the VDG group should clone what, the Win95 look? Should be the most familiar look around.

Please note that in my arguments I used the word "familiar" in a descriptive sense and not as an argument for the checkmark. Incidently, the checkmark is indeed familiar, but I also find that argumentation with tradition is often misleading, as luebking suggested.

alake, note that - in addtion the initial post - there are other situations where new checkbox design seems to be step back (see viewtopic.php?f=285&t=128946#p344429). I can only speculate about the reason of this perception, here is one possible explanation:

The "new" checkmark (square) has less visual information compared to the "old" checkmark:
"new": I see a square shape and then I have to also check it's color (blue) or it's surrounding square.
"old": I see a checkmark shape and that's it.

The checkbox is a central UI element and deserves closer inspection. Sure, one can get used to anything. I personally would see the optimum here and not only the acceptable. Although, after reading alake's comments in https://bugs.kde.org/show_bug.cgi?id=343428 I got a glimpse of why the new checkbox fits into the overall design idea and why the traditional checkmark is not compatible (as I understood it is because of the color).

alake wrote:Changing to a traditional checkmark might be a way to solve the problem but in my view, I'd like to give an opportunity for the currently proposed solution that preserves the current design to be implemented. I totally understand there is a segment of very well-meaning folks that would prefer a traditional tickmark design. But I'd really like to try to solve the specific issues raised within the current design before revisiting the basic design of this control.

To look forward: is there a release planned which introduces improvements to the current checkbox design?

In Bug 343428, comment #6 says that "on the second screenshot, I think here it is obvious that the selected is unchecked". If you stare at it, yes. If you glance at it, which is what most people will be doing, then not at all. So the proposed solution isn't much of a solution. I don't want to have to stare at a highlighted checkbox longer than needed to know whether it's checked or not. I can think of all sorts of solutions that would fix this issue, including the use of a tickmark, so I don't understand why there's so much reluctance to change the current solution.

The "new" checkmark (square) has less visual information compared to the "old" checkmark:
"new": I see a square shape and then I have to also check it's color (blue) or it's surrounding square.
"old": I see a checkmark shape and that's it.

I tend to agree with this and will (once more claim that this is because the "dot" is too huge, so the remaining container space can easily be mistaken for a doubleframe.

Hi, I propose to move back to the original thread where some points have been already noted.

viewtopic.php?f=285&t=123108

And closing this one. Duplicating topics looks like a waste of time, especially with this forum notification system being inconvenient.