A few weeks ago, I complained about the possibilities to align and group elements when designing KDE dialogs with Designer. But in order to make Designer better meet our requirements, we first have to define what KDE dialogs should look like: We need to define guidelines.
In a first step, I had a look at dialogs and guidelines of the four major desktops: KDE, Gnome, Mac and Windows.
Comparison of the major existing Dialog Layouts
Status quo: KDE
The new guidelines will have to work with existing KDE dialogs. There are (at least) three aspects we have to consider which hinder us in simply copying other guidelines (even if we wanted..).
- Wide range of provided functionality.
KDE dialogs vary strongly in their provided functionality. There are dialogs pages which provide two or three options only, while there are others which look bloated. A general dialog layout should be able to handle the whole range. - Nested pages.
Some KDE dialogs have up to four levels of navigation (left bar + sublevels + tabs). The number of tabs and the existence of a left sidebar affects the size of the window, and thereby the layout. - Orphaned options.
There is a high number of options which is not directly related to others, so they can't be grouped in meaningful clusters.
How do the other layouts look in Qt?
I applied the other desktops' guidelines to Kontacts "New Event" dialog. Even if they do not correspond 100% to each other and to the guidelines, I think you can see a difference:
[image:2322 width=500 class=showonplanet align=center]
KDE. Basic characteristics of the dialog are the five tabs and four "orphaned" options which are not grouped with others: Busy, Public, Comment, Categories.
This is not the best-designed KDE dialog out there, and there have been several attempts to redesign it. None of them was too successful - possibly because of the missing guidelines. So let's see if the others can help!
[image:2323 width=450 class=showonplanet align=center]
Gnome Simulation. Gnome has a very clear layout that shows is very easy to understand and to implement (straight top-to-down approach). It requires to create meaningful groups - you can see that the orphaned options are grouped logically with other elements.
Disadvantages of this approach are the missing scalability in width - if there are more tabs, ui elements either will have to be stretched or there is a lot of empty space on the right. Also, the strict placement of options below each other limits the maximum number of options on a page (the dialog becomes simply too long).
[image:2324 width=500 class=showonplanet align=center]
Mac Simulation. Due to the center-equalisation, this layout also works when the dialog becomes broader. It simply recenters.
However, this layout is not so easy to understand and implement as the Apple HIG is very complex with regard to dialog layout. Also, the look is less clean than in the Gnome layout as there are more visual axes.
[image:2325 width=500 class=showonplanet align=center]
Windows Simulation. The advantage of this layout is that it is very compact and many options fit onto a relatively small page.
However, the layout is not so easy to implement as there are various options how to arrange the single groups and options. The developer has to spend more thoughts in it which unnecessarily costs time. Also, some elements have to be stretched (e.g. the line edit) to fit the overall layout.
What options do we have?
To find the optimal layout for KDE, we will have to combine the advantages of different layouts and probe carefully if they fit with our existing dialogs. Before I post my suggestions, I'd be happy to read your opinions here.
Syndicate Blogs
Vertical is better than horizontal
One thing that the human mind is good in is to scan lists from top
to bottom. Given this aspect, the best layouts are the Gnome and Mac
versions; KDE's is worst after Windows's.
Tabs
IMHO there should never be more than five (maybe six) tabs in a dialog window-- if there are so many tabs that the tabwidget breaks layout; then the dialog needs to be split up.
I think one major thing to take into account when looking at the GNOME and Macintosh guidelines in the presence of expander widgets; something that I would love to see in KDE.
Layouts and alignmens.
Using the center-align that Mac wants is impossible in Qts layouters. We'd need to write a new layout manager to handle proper baseline alignment and action-button widths. (I've done that before, just never for Qt).
For the ones that don't see what I mean; open the mac mockup and see how "Public Information" does not line up with the stuff right of it.
I'd hope we are going more for horizontal layouts (where I'd call the gnome a vertical one) due to the LCD screens being sold in increasingly widescreen types. That probably is the biggest reason I don't like the gnome one.
For KDE I'd say we want to allow multiple (short) checkboxes and comboboxes to be on one line.
A better date-widget would be nice. The 'editable' combobox for the date is useless. The majority of the people find editing that cumbersome and will always opt for the popup. Which means that its too hard to use (since the popup button got really small) for them.
Just make it a normal combobox or button.
For grouping I have always hated the QGroupBox due to its indenting nature. Something which most layouts f*sk up and end up with much to much margin.
I'd love to have a new widget that has a bold label like the gnome layout to separate them. But no indenting of the items below that.
This new widget (instead of a simple label) would span the full width and can be themed to simply show a line right of it, or a nice gradient like in: this image
Just some random thoughts..
I'd hope we are going more
I'd hope we are going more for horizontal layouts (where I'd call the gnome a vertical one) due to the LCD screens being sold in increasingly widescreen types.
I really don't see that as being a good reason for going for increasingly horizontal layouts. The vast majority of screens in the world today are not widescreen, and many will continue not to be, like laptops. You can't just assume screens you run your applications on will be of a widescreen layout.
horizontal
The common resolutions today are all already wider then they are high. Menubars, taskbars etc eat even more vertical space.
Looking at the amount of space available we have been on widescreen for ages. And its only getting more so due to the new standards for screens.
There's a difference between
There's a difference between that and widescreen. The resolutions that we have today, even the higher ones, are not going to significantly change at all and neither are the monitor sizes or the sizes of the monitors tht already exist. Designing for widescreen monitors is simply a mistake. Making things more resolution independent is probably a safer bet.
And its only getting more so due to the new standards for screens.
New standards? Please.
The one thing I don't like
The one thing I don't like about the Gnome dialogue are the separate day month and year widgets. You need a decent all in one date picker. Although it doesn mean that you can individually pick the day, month and year this isn't as important as something like a file day, month and year search.
The Windows layout is a bit too horizontal. It's nice to have a layout where you can work through what you need, in order, top to bottom.
separate day month year
The one thing I don't like about the Gnome dialogue are the separate day month and year widgets.
my err.... :-|
There's actually nothing
There's actually nothing wrong with separate day, month and year pickers. The problem with a date picker is that you start at today's date, and you generally have to scroll back through the months and years to get to the date you want. This is important in things like file searches, where you may search historcial files or data in databases.
With something like an appointment dialogue it's less important, because the date won't be in the past and it invariably won't be many days or weeks in front of today's date.
date dialog
In some tool I created for internal use some years ago we used a data picker exclusively. And those ladies were very fast to find out that you can click on the month or the year and immediately jump there. Like its been possible in KDE for ages already.