Hi,
I'd like to suggest to reconsider departure from a widely known checkbox symbol:



All operating systems' default checkbox look is the tick mark or an x-mark. See eg. http://qt-project.org/doc/qt-4.8/qcheckbox.html http://developer.android.com/design/bui ... tches.html

As the old saying goes, we can be as smart as possible, but not smarter. So *I am* really surprised now, after looking at real-world context such as todays' http://www.proli.net/2014/10/02/porting ... ver-to-kf5. I had to think twice to understand meaning of the Software Updates window.

For unsure fans of usability I'd suggest usability test on a focus group, most probably results would at least as practical as checking if users understand a "save" icon

If we manage to get this right, a bonus is to design visuals of the third state of the checkbox: http://qt-project.org/doc/qt-4.8/qcheck ... state-prop

TIA!

I've noticed that while seeing the Breeze theme in action, too, and I've already notified Andrew. He's thinking about bringing some sort of cross or tickmark back.

Thanks for asking about this jstaniek!

The checkbox design along with all the other UI controls designs were completed in a forum thread here. During the design cycle the question about the recognizability of the checkbox as distinct from a radio button came up and some impromptu tests were run to determine if they're recognizable as checkboxes. All reported success. Additionally, examples of other platforms using squares as checkboxes were also produced, which helped to inform us of the novelty of the design approach. To be clear, there is certainly the possibility of test-specific and design specific deficiencies that might lead to over confidence in the result.

For now, the expectation is to get greater exposure with these designs over the 5.1 cycle. If the results there contradict the results of the early tests we'll simply revisit the designs for the 5.2 release.

Hope this helps!

Thanks @colomar and @alake, are there online resources, links? (to the test, methodology, results, and the other platforms that use squares by default - rarely )

"by default" - is a key here for me. We're developing default theme (and giving advices for others to follow, advices reasonable). Default theme goes the common denominator way, choosing novelty when it does not harm.

Non-default themes can go here and there with novelty and time will test them.

Obvious issues are as follows:
1. it's possible to confuse "On check box" with "focused Off check box",
2. it's possible to confuse "On check box" with "On radio button" - for users with even slight vision impairment.

In both cases a simple test could involve presenting the two boxes side by side.

PS: Per parallel to software engineering, if the "design feature" gets marked as mistake, maybe it would get qualified as a bug to be fixed in a minor release. I hope nobody is going to use a "it's too late, approved" argument. Test in on fresh eyes who have never the breeze before.

PS2: Despite me having seen the breeze before quite a lot and doing some design of apps using the mockup toolkit too, I consistently considered the blue box as a focused Off box, not an On box. Thus there's my surprise

PS3: It's my 21st year of working with point&click UIs as an engineer.

jstaniek wrote:Thanks @colomar and @alake, are there online resources, links? (to the test, methodology, results, and the other platforms that use squares by default - rarely )

"by default" - is a key here for me. We're developing default theme (and giving advices for others to follow, advices reasonable). Default theme goes the common denominator way, choosing novelty when it does not harm.

Non-default themes can go here and there with novelty and time will test them.

Obvious issues are as follows:
1. it's possible to confuse "On check box" with "focused Off check box",
2. it's possible to confuse "On check box" with "On radio button" - for users with even slight vision impairment.

In both cases a simple test could involve presenting the two boxes side by side.

PS: Per parallel to software engineering, if the "design feature" gets marked as mistake, maybe it would get qualified as a bug to be fixed in a minor release. I hope nobody is going to use a "it's too late, approved" argument. Test in on fresh eyes who have never the breeze before.

PS2: Despite me having seen the breeze before quite a lot and doing some design of apps using the mockup toolkit too, I consistently considered the blue box as a focused Off box, not an On box. Thus there's my surprise

PS3: It's my 21st year of working with point&click UIs as an engineer.

Just a quick response jstaniek. I think you raise perfectly reasonable questions. The tests were almost entirely impromptu and ad-hoc as I mentioned. For the ones I conducted they involved presenting the checkbox designs alongside a set of other sample controls, including radio buttons to several people. They were far from formal or terribly structured so there is likely some variability and credible room to question the conclusion. I'll try to dig up the design thread. I have no doubt though that these questions you raise are perfectly legitimate and reasonable and, speaking for myself, I certainly welcome them. (I'd welcome them regardless of your experience)

In fact, I tend to agree with your observation that the focused versus non-focus states could be confusing if the checkboxes and radio buttons (sans labels) are used as shown in the mockup toolkit. In the actual implementation, both in the Breeze QWidgets style and the QtQuickControls style, the checkboxes are accompanied by a label (per the HIG) which exhibits the controls focus effect. The mockup toolkit unfortunately doesn't capture this and should be updated. But that doesn't mean that I think there's nothing more that needs to be done with the design to make it better - including potentially a design so that the control itself, even without the label, can communicate its focus state. Based on your input here alone, I'm inclined that we revisit some of the design decisions to perform a more rigorous validation after the 5.1 release. I would personally have no objections to whatever necessary changes being addressed in a minor release.

alake wrote:In fact, I tend to agree with your observation that the focused versus non-focus states could be confusing if the checkboxes and radio buttons (sans labels) are used as shown in the mockup toolkit. In the actual implementation, both in the Breeze QWidgets style and the QtQuickControls style, the checkboxes are accompanied by a label (per the HIG) which exhibits the controls focus effect.

In most cases yes, there is a label. However, there is the occasional situation such as this one
where there isn't really a label as such.

The mockup toolkit unfortunately doesn't capture this and should be updated. But that doesn't mean that I think there's nothing more that needs to be done with the design to make it better - including potentially a design so that the control itself, even without the label, can communicate its focus state. Based on your input here alone, I'm inclined that we revisit some of the design decisions to perform a more rigorous validation after the 5.1 release. I would personally have no objections to whatever necessary changes being addressed in a minor release.

I agree. Should this checkbox design turn out to be a usability bug, we can fix it in a bugfix release just like any other bug (especially since I don't see the risk of introducing technical regressions by changing the design of a control).

colomar wrote:In most cases yes, there is a label. However, there is the occasional situation such as this one...where there isn't really a label as such.

BTW, how does the intermediate state of checkboxes looks like? "Intermediate" applies to the superior checkbox when a subordinate collection has a mixed status.

Thanks a lot for the prompt reaction, actually much faster than the industry standard

Quite a few about check boxes is mentioned here: http://www.nngroup.com/articles/checkbo ... o-buttons/

And yes, the question about the intermediate state of a checkbox remains. Interestingly, for XP the state is expressed using a box: https://en.wikipedia.org/wiki/Checkbox. I think it could be possible to come up with better solution.
In Kexi tabular views and reports a question mark is used to indicate "intermediate" "unsure" state. It's quite good to show the value is neither true nor false:


Tristate checkboxes are extensively discussed here http://guijournal.com/2011/05/gui-desig ... heckboxes/

The checkbox design actually accounts for tri-state. Again, unfortunately, not included in the mockup toolkit. I'm collecting a list of things to add to the mockup toolkit.

In lieu of the updates to the mockup toolkit, the reference Breeze UI controls design is captured in QML in the Breeze KDE project repo. It is really easy to see and evaluate the reference design: just clone or get a tarball of the repo, change to the qtquickcontrols directory and the run "qmlscene Breeze.qml". All of the controls are live and clickable and was used to directly to capture and help evaluate design decisions during the design cycle. There you can see the tristate design as well.

Also you can evaluate it in everyday use via the project neon builds of plasma 5 (either the ppa's or the iso).

Hope this helps!

Oh and I also wanted to mention, that there are already a few changes in the pipeline from the testing done so far using the QWidget/KStyle implementation of the design during the 5.1 development cycle. Many of those have already been posted here via the threads Hugo has participated in - who's working on the QWidget implementation. Most of those changes are already in for the 5.1 release.

Thanks for the great feedback!

alake wrote:The checkbox design actually accounts for tri-state.

Ah... nice.

Heiko Tietze wrote:

alake wrote:The checkbox design actually accounts for tri-state.

Ah... nice.

Thanks for pasting this. Just some research below, will be happy if it helps.

A number of questions:
* Don't you think it's really close to the On / Yes state...? it would be easy to user-test that
* The contour 'strikes out' the box what can be understood as Off / No
* Or it looks a bit graphically-richer, like an arbitrary icon (non-clickable), not so much like a button that can be actually clicked.

I wonder if it can be like: form follows function?

If the principle of least astonishment shall be used, how about a dash? A couple of other styles too as well. Why not to harmonize with that?
* GNOME's default: http://gallery.dpcdn.pl/imgc/News/58117 ... 3302_0.png
* QtCurve uses it
* GTK+ and thus GTK-Qt by default: http://wstaw.org/m/2014/10/06/plasma-desktopaW1939.png
* Balsamiq http://balsamiqmu.wpengine.netdna-cdn.c ... minate.png
* Sometimes used on Mac OS X (probably with setAlternateImage) http://i.stack.imgur.com/UlpJ8.png, web browsers use images too, and Chrome: http://stackoverflow.com/questions/2167 ... e-checkbox

PS: This may be unintentional but this indeterminate state looks like coming from the Motif style: http://wstaw.org/m/2014/10/06/plasma-desktopPg1939.png

Question of the day: can you tell what is On, what is Off here?



PS: thanks so much for the style backport of Qt 4!

[x] Backtrace Browser
[x] Build Plugin
[ ] Close Except/Like
[ ] CTags

I don't think the issue here is the square tickmark in particula, but it's the ratio: it's too big to count for a dot.
Here's an even more exotic checkbox:

Yeah, I wanted to show that these two are too close:
[x] Backtrace Browser
[ ] Close Except/Like

If you make the box smaller, it wouldn't help too much: it'll suddently be closer to On radio button. And the story repeats.

The principle is to use shapes, as in breeze icons: they are mostly mono but communicate their meaning through their shapes.

If this is a metrics, I am using the breeze style with Qt4 apps for a while now and it takes *much* more time to figure out what's On, what's Off.
However, the Qt4 backport is surprisingly solid, anyway (testing with Kexi now!).

As for the example from deviantart it ... rather deviates (!) from easy principles (radio is round, checkbox isn't round).

The point is it to make it not looke like a double contrast line:

it'll suddently be closer to On radio button

I just heard someone saying that radios are round ... ;-P

The principle is to use shapes

No offense, but a "square" is just as much a "shape" as an "x" or a "checkmark" - the argument would be "please use the familiar shape" (where the "x" is a bad idea, given that's it's usually used for closing)

example from deviantart it ... rather deviates

Virtuality deviates in pretty much everything. Leaving the common GUI patterns behind was the key idea.
Radiobuttons are btw. like checkboxes but rotated by 90° - the reason is that checkboxes and radios don't differ in their functionality, but only the exclusiveness (and they're round because the circle closes on hover, what would look pretty dull with a square)

Benefit of not operating on the default system is that you can scratch "what we have always done" and just try out different things =)