Too much borders
It is not uncommon to find dialogs which contains tabs, which themselves contain groups, which contain other groups. That’s quite a lot of borders… Not only does it look crowded, it also eats valuable content space. There are a few easy tricks you can use to avoid this issue.
- Maybe you can use fixed-height spacers and labels to replace some of your group boxes, especially if your group box is the only element in the dialog.
- If you use a QTabWidget (or its KDE descendant, KTabWidget), try setting the “documentMode” property to true. When this property is set, the tab widget does not draw a border around its content, it only draws the top bar. Here is a before/after screenshot of KMix to illustrate:
Double margins
This problem seems to be less common lately, but I still encounter it regularly, especially in configuration dialogs. The bookmark editor demonstrates this problem quite well:
Oxygen tends to hide the problem a bit, it is much more visible with the the Plastique style, as you can see on this annotated screenshot:
The change is very simple to do. Here is what it looks like now:
Note that I only removed the top and left part of the inner double margin: I first tried removing margins from all sides, but the line edits looked cramped when squashed against the window borders.
Widgets aligned on borders
Sometimes widgets are aligned to the right border of their container, and their labels are aligned to the left border. It looks like this:
This is wrong because the eye has a lot of work to do to associate the widget with its label. For this reason, the KDE HIG suggests using right-aligned labels and left-aligned widgets in the Dialogs page.
The easiest way to get the correct layout is to use the QFormLayout (which comes with the added bonus of adjusting label alignment according to the platform, so one gets left-aligned labels when running on GNOME). QFormLayout is sometimes painful though and in this case you have to use the more generic QGridLayout. If you do this, be sure to right-align your labels.
Reversed check boxes
Now… this one is probably going to be controversial, so keep in mind this is just my opinion.
From time to time we see check boxes with labels on the left. For example, reversed checkboxes appeared in KSnapshot:
It is my understanding that this change was made so that all labels are on the left and clickable elements on the right. It certainly looks nice and balanced in KSnapshot, but the idea of reversed checkboxes is still wrong for at least two reasons:
- Small mouse target: in a normal checkbox, both the box and its text are clickable. With reversed checkboxes there is only a box, so you get a much smaller mouse target.
- Inconsistency: having both normal and reversed checkboxes is inconsistent. This can’t be fixed easily because we have to take checkable group boxes into account. Look at this screenshot of KGet configuration dialog to understand what I mean:
I agree the problem reversed checkboxes tries to address is valid, though: checkboxes sometimes break the visual alignment of widgets in a dialog. However I suggest a different fix: try to figure out a label for your checkboxes. For example, KSnapshot could be changed to look like this:
The KDE HIG actually mentions this checkbox issue in Form_Label_Alignment and suggests a similar, but more generic, fix: Put the description of your checkbox in a QLabel on the left of the checkbox and set the checkbox text to a generic word like “On” or “Enabled”.
Advertisement
Like this:
Be the first to like this post.
identi.ca
Pingback: Tweets that mention ubuntu #linux Aurélien Gâteau: Common user interface mistakes in KDE applications, part 2: Dialog layouts: Too ... -- Topsy.com
Great work!
Good article.
I’d add that the first KSnapshoot feels unbalanced: I’d expect something on the right, but I see only empty space.
Also there is no explanation on what the checkboxes do; ok the do “include” but the explanation should be on the right, so maybe I’d reverse the order of the strings. This way the status of the checkbox gets associated to an action to do or not. IMHO.
there are lots of places that checkboxes will always be on the left (e.g. menus). that isn’t the point. consistency here is a losing battle because people don’t get confused or work slower due to the checkbox location being different in different contexts. what matters is that they are well associated visually.
the target size can be address in a few different ways: linking a clicked() signal on the text label or by allowing the checkbox widget to grow instead of remain constrained.
so what is gained by this? well, studies i’ve read that have done real world experiments show that this is the fastest and most eye-pleasing arrangement possible. here’s one such a study:
http://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php
obviously putting labels above widgets isn’t an option. so keeping a clean central trough between “what i’m controling” and “what i use to control it” with a consistent left-right orientation is useful.
with the example of ksnapshot, the mouse checkbox ends up just hanging out there in the middle of nowhere, and this gets increasingly bad with dialogs with a few of these in them.
for configuration dialogs with a number of checkboxes in them, having everything on the left makes scanning for the features very easy and efficient.
i don’t think this should happen everywhere in the UI, but in form-only UIs like configuration dialogs, i think it makes a lot of sense.
> there are lots of places that checkboxes will always be on the left (e.g. menus). that isn’t the point.
I couldn’t disagree more. Consistency matters a lot.
> the target size can be address in a few different ways: linking a clicked() signal on the text label or by allowing the checkbox widget to grow instead of remain constrained.
Making description labels clickable would mean items on the left side would suddenly become active whereas before the whole left column was only descriptive. This is bad, surprising and inconsistent. As for allowing the checkbox widget to grow, I don’t see how this would look, and I don’t think it would work with all styles.
> so what is gained by this? well, studies i’ve read that have done real world experiments show that this is the fastest and most eye-pleasing arrangement possible. here’s one such a study:
> http://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php
That’s a very interesting article, but it does not prove your point. One of the conclusions it reaches is when one uses a two-column layout, descriptive labels from the left column should be right aligned, which I think is not the subject of the discussion. It does not mention checkboxes at all. The solution the HIG suggests or the one I suggest both support right-aligned descriptive widgets.
Imagine for a moment that the two “include” checkboxes from KSnapshot where mutually exclusive. You would then use radio buttons. Would you also put the description of the radio buttons to the left side? I hope not. The difference here is that usually radio buttons have a separate description label. This is exactly what I am suggesting here. Keep a clickable text on the right of the checkbox and add a descriptive label on the left.
Very good article. I liked the KSnapshot example. Keep posting like this.
Another common error is removing the margin around content of tab pages. Oxygen style hides this problem, but with all other styles it looks bad. For an example, check rekonq “Network” configuration dialog pages.
I think these posts are great! Please keep them coming. I have a fairly strong background in computer science and software engineering, but not so much in UI design — I’m learning a lot from your posts and think you are doing a really nice job. Knowing even the different perspectives of where to place checkboxes with respect to their labels, as described by both you and Aaron Seigo (in the post above), are helpful.
Thank you.
Months ago (IIRC before 4.5) I tried to do exactly the same with checkboxes in the config window of the taskbar plasmoid. The problem I encountered was that Qt Creator’s Designer was totally braindead (at least back then — don’t know about today). I couldn’t get it to align the widgets properly. Maybe it’s just me and everybody else has no troubles with Designer. I many other people have the same problems with Designer as I have, I really don’t blame them for less than perfect GUIs.
After — no kidding — an hour or so of fighting Designer over only a tiny window, I at very least could get align all text labels of checkboxes within the window on the same side, reduce wasted window space, and align the widgets to a common center: http://kamikazow.wordpress.com/?attachment_id=70
Not that I’m happy with the final result — I’m just less annoyed when I see the window now…
Oh, just saw in the SVN log it wasn’t me who did that layout. I rearranged it and a while later Aaron center-aligned it (guess I wanted to center it but didn’t win against Designer…)
I really dislike the new layout:
- it makes inconsistent use of colons (some labels are followed with columns other are not)
- it is much less visible that the “Only when the taskbar is full” option depends on the grouping combobox
- and of course the checkboxes are super small
I like that you are fixing and talking about the user interface problems. Keep up the good work
Great work! I hope you will also be consistent as the interface you promote and will finish the work!
Good luck and Merry Christmas!
I too am very grateful for these post and for the work you’re doing. I think this kind of attention to consistency and polish is sorely needed in KDE software in general. Keep up the good work!
Very cool! Thanks sooooo, soooo much for looking at AND blogging about this stuff. Like many others have said, this is definitely an area that KDE could use some welcome effort. It is especially nice to see the tangible ways we can work to improve things.
It would be cool if we could raise a small team of ui contributors (especially since much of this isn’t about coding): Dedicated to finding areas to improve like you’ve done, blogging about it, and updating the HIG as required. Review requests interested in the UI feedback could include this team on the review request.
Anyway, thanks much for sharing.
cher Aurélien,
your work is the one of the winners..!
Oh my, a great battle between Auerelien and Aaron… let’s see who wins, because the issue has been plaguing us for years if not decades. Let’s finally fix it and decide on an approach, make it official and fix everything that does not fit. It’s time to do that, already. Don’t you think? Consistency is good, but peace and agreement between developers is even more important that that.
Awesome, this post explains perfectly my feelings about my thoughts during these months
)
I’ve also added a review request for a (I don’t like to commit code belonging to others, even if it’s a one-line fix
Anyway, great article
Just approved it!
Pingback: Top Posts — WordPress.com
> Consistency matters a lot.
it does, up until the point that the consistency introduces inefficiencies. the point of consistency is to allow predictability and lowering surprise. when it fails to add value in that form, then it’s not worth chasing after.
another example of this is toolbutton order and contents in the file manager versus the file dialog.
this is very much about “making sure that usability improvements equate to real world benefit” versus “sticking to rules without bending because rules are there for a reason”.
> Imagine for a moment that the two “include” checkboxes from KSnapshot
> where mutually exclusive.
they aren’t, so it’s not particularly relevant to the question of checkboxes, as checkboxes aren’t radio buttons
> You would then use radio buttons. Would you also put the description of the radio buttons to the
> left side?
no, and here’s why: the left is the “topic”, the right is the control. in radio buttons, the control is in part contextual (so belongs with the radio) but the topic is shared and goes on the left. a checkbox is a “special” case where there is only one boolean choice. adding more context is irrelevant, the topic remains on the left.
if you wish to press for consistency, press for it _within the same interface_ where the topic is on the left and the control is on the right. trying to make things consistent globally resulting in locally inconsistencies seems to miss the point imho.
i also haven’t yet found a person who is confused by the naked checkboxes on the right, though it provides a more visually pleasing layout and is easily scannable. which to me says that this kind of change is one of those “theoretically better” changes with no real world benefit, as in “making the user better at using the interface or more satisfied with how it looks”. (in general terms; aesthetics are variable between individuals, yadda yadda
a pet peeve of mine are theoretically better changes that are devoid of real value. i gave a presentation about 5 years ago at akademy about usability and this was one of the things i presented about. look up “cargo cults” on google
> this is very much about “making sure that usability improvements equate to real world benefit” versus “sticking to rules without bending because rules are there for a reason”.
I fail to see how drastically reducing the clickable size of a widget is a real word benefit. I am sure people with difficulties moving a mouse, such as people suffering from fine motor skill disorders dislike this idea as well.
> no, and here’s why: the left is the “topic”, the right is the control. in radio buttons, the control is in part contextual (so belongs with the radio) but the topic is shared and goes on the left. a checkbox is a “special” case where there is only one boolean choice. adding more context is irrelevant, the topic remains on the left.
I agree, but I don’t see how it goes against my proposal. In my mockup, “Include:” is the shared topic, “Mouse buttons” and “Window decorations” are part of the control. What’s wrong with this?
> i also haven’t yet found a person who is confused by the naked checkboxes on the right
You are having an argument with one, and others are commenting on this post.
While I’m sure there is a point to be made about taking usability guidelines and making them rules, it is incredibly difficult for me or others to see how the changes here make things worse or, for that matter, contradict anything you are talking about.
Obviously, if blindly following a set of guidelines makes for a worse experience then it is entirely appropriate to identify a different solution. That can hardly be said to be the case here. However, if in our zeal to highlight what is admittedly a pet-peeve, we make the unfortunate implication that there is little or no value in following some set of guidelines, or providing some UI consistency – which I don’t think was you intent – then we end up with a lot of opportunities for improvement like we do today.
We have certainly and unequivocally come a long ways in the UI department in KDE. But I’m pretty sure there is universal agreement that we can do better, and I’m grateful for articles like this that help us all work towards that improvement. Thanks Aurélien!
I like these posts about usability. They are useful for anyone trying to make his/her application look good and behave consistently.
By the way these problems may not be specific to KDE. They may be present in GNOME as well. I would love to see a series about GNOME as well.
About the checkboxes:
1) small mouse target: this is an issue, but highlights more what i think is a problem in Qt: i really do think in case of clickable elements the buddy should pass clicks. perhaps not easily implementable and don’t think would be accepted upstram since introduces a behavioural change, but would really make sense there
2) consistency: depends on what. in the ksnapshot example i see the first version, where i have description:input control for all the elements there, versus having the last two widget with the description swapped for no apparent reason.
As in general left vs right: is not really an easy topic since in some cases, like this ksnapshot example is easy to semantically group multiple checkboxes: in this case, what we want to include in the screenshot? chose between two items, so it can be interpreted in a way not much different from radio buttons and it is possible to have a more general topic on the left.
for many other cases, the checkboxes are really stand alone, or grouping with the nearby ones makes a really too big logic stretch, so they lose any similarity with radio buttons and become more similar to other widgets, like lineedits or combo boxes, where is natural to have description: input widget
I disagree: it would make part of the left column active whereas it is only descriptive right now. This would be inconsistent and difficult to discover.
You get it, in this case the checkboxes can be grouped, just like one would do with radio buttons.
In these cases you can either:
- Be creative and come up with a descriptive label. For example, this is what I did in Gwenview configuration dialog: http://simplest-image-hosting.net/jpg-0-plasmoidviewerc30475
- Follow KDE HIG and use a generic label for your checkbox, something like “On” or “Enabled”.
If you really want checkboxes to work without labels you should do something similar to the UISwitch control provided by iOS: http://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/UIElementGuidelines/UIElementGuidelines.html#//apple_ref/doc/uid/TP40006556-CH13-SW14 or use two horizontally-aligned radio buttons
I think that your solution for what you did in Gwenview is nice.
Even though Qt Designer drove me nuts, I remember seeing an option to configure where to put the text label: Left or right.
In the task bar config window didn’t use the feature, though. I tried but Designer’s auto-aligning was so bad, it simply didn’t even work.
Hmmm…maybe I’ll retry with the current Designer release. Maybe it works now….
I assume you refer to turning the widget in left-to-right mode. That would be wrong as it would force the direction regardless of the system direction. It would also not help much here since the label would still be in the right column.
Thanks a lot for the nice work and this series of blog posts you’ve been doing, I do really enjoy reading them and seeing the changes in action.
Just wanted to hop in and say that removal of the borders (in this case with documentMode) fixes really annoying usability problem when applications are run in maximized mode. Basically you can not just drag your mouse to the edge of the screen and use the wheel to scroll around because of that border.
So everyone who is using the QTabWidget layouted to the edge of the window, please switch it on.
Congrats’ Julien for such modifications, it’s really annoying to see these little simple-to-fix things everywhere in KDE.
Thanks, but… mmm… my first name is Aurélien
Pingback: thinkMoult - The kde-www war: part 2
What about this? http://simplest-image-hosting.net/png-0-sysset
Let’s think about small screens..
It would be great if KDE would set up a group of specialist to polish these UI consistencies methodically, application after application..
I agree, it’s quite a waste of space.