Common user interface mistakes in KDE applications, part 5: Big toolbars

written on Friday, May 11, 2012

It's been a long time since I last wrote about user interface mistakes in KDE applications. Here is a new addition to this series.

Starting with KDE 4.0, KDE applications ship with toolbars containing both icons and texts.

This setup makes it easier to understand the action associated with a toolbar button. Additionally, buttons with icon and text provide bigger mouse targets.

The price to pay for this is toolbars can become quite wide, to the point where they barely fit on 1024 x something screens (think netbooks or video projectors). To make matters worse, translations often increase text widths: French and German translations for example are known for being quite verbose.

If you maintain a KDE (or Qt) application, here are some simple steps you can follow to reduce the width of your toolbars without compromising too much.

Step #1: Do you really need that button?

This first step is quite obvious: go through your toolbars and check if some of the buttons present in the default configuration can be removed. If they are seldom used, maybe it is OK if their action is only reachable from the menubar?

You probably made such decisions while the application was created. Nevertheless it's a good idea to revisit those decisions from time to time, based on your increased knowledge of the way your application is used.

I couldn't come with strong rules to decide whether a button should show text or not. You have to use your gut feeling here. Nevertheless here are some hints to give you an idea of situations where it may make sense to use icon-only buttons.

• The icon is common enough that it does not need text to be understood. Media icons (play, pause, next, previous), print, zoom or trash buttons come to mind. There are probably others.
• The button is part of a button group and works as a radio button, for example the view modes in Dolphin (icon, compact and detailed), the format or alignment buttons in a word processor.
• The action for this button is about manipulating the UI rather than an essential part of the task the user wants to accomplish. For example an action to toggle a sidebar.
• The action is part of a group of two opposed actions. In this case one of the two actions can often come without text, its meaning being defined by the other action. For example: Undo / Redo, Back / Forward.

Remember those are just hints: they may not make sense for your application. Additionally, make sure not to overdo it to the point of having only icon-only buttons!

For the remaining buttons which kept their texts, try to shorten the text to one or two words only, put a longer text in the tooltip. This serves two purposes:

• It reduces the button width
• It brings back value to the tooltip: don't you hate it when you move the mouse hover a button and the tooltip which appears stupidly repeats the button text?

When defining the action text, make use of KUIT: mark the text using "@action:intoolbar", This should give a hint to the translator that this string should be kept short.

When defining the action tooltip, remember the HIG says tooltips should be written using sentence capitalization, not title capitalization. QAction is not being very helpful there: when no tooltip is set, it falls back to using the "text" property as a tooltip, and the "text" property uses title capitalization :/. That is one more good reason to define tooltips yourself.

String freeze for KDE SC 4.9 starts on May 19th, so if your application is in KDE SC, you still have a few days left to check if your application toolbar could be improved!