SEP
6
2006

KDE Dialog Layout

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.

Comments

A question. Will we be seeing more use of bold and larger font sizes in dialogs in KDE4? for group headings etc, like GNOME is doing these days?

(I personally think that it is about time that we made better use of fonts in dialogs than everything always being exactly the same font.)

--
Simon


By simon edwards at Wed, 09/06/2006 - 18:19

I agree with Simon and I think that better use of font sizes and weight is a good thing.

We need to keep it sane, though, but we could learn from newspaper, magazines and even webpages that we could use fonts to make it visual appealing.

Nowadays, nobody uses plain webpages anymore. Everybody likes nice designs and extensible use of stylesheets, let's KDE do the move too.


By gsbarbieri at Thu, 09/07/2006 - 18:44

(Despite some irrational hatered towards MacOS) I must say, with the exception of "enforced centricity" I rather like the Apple's way way of arranging things. Points:
1. Poor Granularity - Excellent choice!
Notice that Mac's dialog has the fewest (il)logical subcategories. The sections are essentially "What, When & More detail". The focus is elevated above widgets' purposes into "task" realm. In my small dabbles with MacOS, what I noticed is exactly that - no matter how many widgets are in the "task" there are no more than 3-4 "well-defined task clusters" per dialog. That helps with focus. The rest of stuff goes into "More...", "Advanced..." etc.
However, that speaks rather for quality of the designer, rather than Guidelines.
2. Mandatory Centering - Not really usefull. Example - Comment box. Eats a lot of side space for rather small gain. I would use "label-entrybox centering" on "per-claster" level when appropriate.

Windows dialog is like that probably because they had some space to the side of DateTime and decided not to waste that - one of the poorest designs from the stand point of accomplishing a task. You have to scan the whole dialog for part, instead of just "reading" it like MacOs's and Gnome's.

KDE's dialog is the most efficient in providing entry space to stuff that matters - Commments and Event info, but one really have to "study" the parts of dialog to use it.

Gnome's arrangement is mess in terms of presentation: No easily detectable "cluster-isation", no visible delineation of elements. It looks as if every piece is important. The widgets for choosing time/date are egregiously overblown. But I like their (corrected by me) grouping of "What, When(including reminder), Who can see this" the best - not something you get from HIG unfortunately.


By suslikreal at Wed, 09/06/2006 - 18:26

Hello,

In this example, I prefer the KDE one:
- everything organises neatly top-down from most used options to less used
- I feel it pleasant to eyes with different zones clearly delimited
- The little "plus" : the Templates buttons that opens a new world of possibilities

Next, and I'm surprised :-) comes the Window's one: its compactness is maybe too much but the zones are also clearly delimited

Third, the MacOS one: neat but I don't like the centering and there is too much entries in each zone.

Finally, the Gnome's one: so sad... so "enterprise", no eye-candy... and the other criticisms in other comments.

Thanks for your survey.
Regards
Kleag


By kleag at Wed, 09/06/2006 - 20:16

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.


By segedunum at Wed, 09/06/2006 - 20:32

The one thing I don't like about the Gnome dialogue are the separate day month and year widgets.

my err.... :-|


By Ellen Reitmayr at Thu, 09/07/2006 - 09:42

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.


By segedunum at Thu, 09/07/2006 - 19:10

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.


By Thomas Zander at Thu, 09/07/2006 - 19:31

I know very well that KDE's date picker has been able to do this. Sadly, those ladies must have been very quick to click on everything (or have been told by someone ;-)), because all KDE's date picker has is a couple of buttons. It's not obvious at all that the month or year are buttons and will yield a list, or a text box in the case of the year, at all.

On the contrary, I have seen countless users go for ages without knowing this, and it's pretty obvious why.


By segedunum at Fri, 09/08/2006 - 19:59

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..


By Thomas Zander at Thu, 09/07/2006 - 09:58

Pages