On Icons and Labels

Posted on Posted in English, FSLab, KDE, Qt

To be frank: I think that the Kubuntu’s switch to “Text aside icons” (as discussed by Seele) was a mistake. The reasons for that are best explained by an example:

Here, only one of three actions are visible in the tool bar, rendering it pretty useless. But let’s revisit what we had as the default in KDE 3 before we used “Text below icons”:

Now, “Text below icons” is a bad idea, because it wastes vertical space, which we are already short of (Plasma panels, menu bar, window decoration). Given the emerging 16:9 ratio monitors, this sounds like a call for “Text aside icons”, the new Kubuntu default:

During the quite vivid and productive discussions on Seele’s blog, some people proposed to show the text only for special actions (mockup as posted there). This does not only allow to easily spot the most important of the actions (keep in mind that all actions in the toolbar should be kind of important, otherwise they shouldn’t be there), but also eases hitting the actions tool button.

Actually, this idea has gone through my mind quite often and our friends over at the competition used this for ages, albeit for Evolution only. Instead of going for such a solution, KDE has struggled for years searching for the right defaults and discussed about screen resolutions.

The actual reason for this was mostly of technical nature: QToolBar couldn’t change the tool button style property for specific actions in Qt 3.x, and the almighty XMLGUI layer used by KDE thus had no such option either. Instead, one everyone got to pick his poison (no description, or space wasting ones).

Attentive readers will have noticed my deliberate use of the past tense in the paragraphs above. This is because with Qt 4, it is possible to do just what I said was missing: Adding actions with an individual Qt::ToolBarStyle. So without further ado, here is my (code-backed) mockup:

The secret is to add those actions that should get a text aside the icon like this:

    ...
    QToolBar *bar = mw.addToolBar(QObject::tr("Actions"));
    bar->setIconSize(QSize(22, 22));

    QToolButton *tb = new QToolButton;
    tb->setDefaultAction(new QAction(QIcon(":/icons/mail-message-new.png"),
                                     QObject::tr("New Message"), tb));
    tb->setToolButtonStyle(Qt::ToolButtonTextBesideIcon);
    bar->addWidget(tb);
    ...

This is officially documented behavior. Quoting the Qt docs on QToolBar::addWidget():

If you add a QToolButton with this method, the tools bar’s Qt::ToolButtonStyle will not be respected.

Now it shouldn’t be too hard to add suppport this idiom to XMLGUI, by adding a flag for “important” actions. That said, XMLGUI is a quite complicated and fragile matter. However, I will take a look at this soon to see if it can be implemented in a clean way without patching Qt.

PS: I think this is one example where less could actually be more in KDE. If we get this right, there is no need for choosing an icon label alignment at all.

28 Comments on “On Icons and Labels”

  1. That certainly seems like a good idea.

    What would be even better (in my opinion) is if labels automatically appeared and disappeared according to the width of the window. If the window is really narrow all labels can be hidden, if it is made a bit wider the most important icons can be given labels, wider still and more (or even all) icons can have labels.

  2. I am all for making toolbars and colums aware of window width. I am tired of resizing colums/toolbars/icons every time i start a program. Sort of shocked people havent started a riot by now, but i guess everyone is used to it after putting up with it a hundred times a day.

  3. I don’t know if it’s allways wise to have text aside the most important icons. When you know what an icon is for, you do not need to have the text there anymore. May be the text should appear disappear in an intelligent way. Meaning that if an icon is used frequently no text is needed and it is shown with unused icons. Or may be it would be good to follow facebooks approach on this. When they introduced the new design they had Yellow arrows and a small text explaining the function. I have googled a screenshot, where you can see this:
    http://www.352media.com/rantingandraving/CMFiles/Images/new%20facebook.jpg

  4. Yes! Text beside those that need text, or that could benefit from the larger target.

    Intelligent text display based on window width (and maybe personal usage, though that’s iffier) might be good, but do the simpler step first. Works great in Gnome.

  5. I don’t know how about you but for me text was _under_ icons in kopete.

    More than that:
    kopete has not so great designed toolbar,
    so I almost always need to hide this toolbar,
    menubar in kopete is too large for resized window too.

    So it is more kopete issue then someone mistake. And I love to see text next to icons in dolphin, etc.

  6. Great, I like your proposal very much and was not aware that Qt4 is able to do this 🙂 Do you think this can be done for KDE 4.2? As the feature and message freeze is on Monday: please drop me a mail if I can support you with e. g. the toolbars configuration dialog (I should have a few hours left on this weekend for some kdelibs hacking).

  7. What is wrong with having tooltips instead of any text at all? Once you have used the program a little bit you’ll know what most of the buttons are for, and besides the majority of icons are fairly self-explanatory anyway (often shared between programs).

    Tooltips are easy enough to discover, at least on a desktop or other machine where there is a mouse input. Maybe it could default to text next to “important” buttons if there is no mouse detected?

  9. A step in the right direction I believe. Although it’ll introduce yet another preference setting, and a “fall back to icons only when space is tight” would be really nice.

    But this still leaves to the programmers the task of guessing which actions are important. Here’s an idea : how about a “dynamic toolbar” that can be used instead of the “default toolbar”, and that inserts (and promotes to icon+text) actions automatically depending on usage patterns (like the “frequently used applications” of the KDE3 menu) ?

  10. That’s something to be thought of, too. But it has to look nice & smooth in order to not confuse people. Still having the possibility to prioritize the labels of certain actions is probably a good idea.

  11. The whole idea is to *avoid* the introduction of further settings. 🙂 The default should be sane. Please see my reply above.

    Dynamic toolbars (like dynamic UIs in general) are tricky, especially wrt support. “Can you see an icon labeled ‘Check Mail’?” “No, but I have ‘Next Message’ here.” Also, they limit the text down to the value of a click area extender, because when people click on an action frequently, they probably know its purpose 🙂

  13. This only changed with Kubuntu 8.10. Other packages use the KDE 4 default “Text below icons”.

    Kopete has more specific issues indeed. But we have to ask ourselves if our framework (i.e. XMLGUI) is powerful enough to handle those challenges. I think it isn’t.

  14. A lot of suggestions here, but the bottom line seems to be that it would be nice if a toolbar item had a priority, so I’m all for adding this in XMLGUI if possible. And maybe start out with the fixed solution suggested in the post, and then more intelligent or dynamic ways of using and changing that priority could be worked out later.

  15. Just another possibility: How about a kwirk menu?

    (e.g. css-html-javascript implementation http://www.kriesi.at/archives/apple-menu-improved-with-jquery)

    A hover on the entry would reveal the text alongside. Might have better discoverablity than tooltips, since those have some delay + font is most often smaller than the rest.

    I can’t judge how annoying that might be, with all the animation, just a quick thought I had.

  16. Nice to see that someone picked up my maded graphical mockup (forget to add a nick there 😉 ) and made a code-based mockup from it. Morning got started nicely when someone got new ideas from my.

    Seems that we have three kinds suggestions about toolbar.

    1) Status Quo – We have tooltips and you learn icons reason in time.
    2) Dynamic toolbars – Texts would appear or disapear affected by window size or how much the icons are used.
    3) Configuration option to select what icons gets text and what does not, when using text-Alongside mode

    1) has few problems, the user can not see right away important buttons functions, thats why icons should be informative as possible so they could understand it just by looking. Text is there for giving the information reading it, without moving mouse over icon. This is important for new user, not for user who has be using KDE4 since it got released. The text+icons or text-only or icons-only approach is little wierd because when we look the kopete or other applications where we want more buttons. We end up to situation that we have all icons without text and empty space after them. Or we have icons with text and some icons gets hided behind small arror (>>). Default settings should actually be always greated per application by usability expert. Like kopete with icons-only and dolphin with text-under-icons and kontact with icons-alongside to get best default settings.

    2) If the text would appear and disapear by size, problem would still be there. User could be confused by that the toolbars gets text when window is on fullscreen and not when not on fullscreen. If developer (or user) choose what icons are primary and what secondary, and text appears in that order, it still leaves questions why some icons gets text and some not? Someone said good point about giving support over phone “Can you see the button where reads the “Details”?”. If text depends about size, this might be a small problem in some situations.

    3) The KDE usability experts could choose what icons need to have the text and what not. So could do the application developers itself. Space would be saved when only important buttons would be showin with text, but user could when ever wants, to choose what gets text and what does not. Important thing as on every other suggestion, is that default settings are made as good as possible. The texts would not appear or disapear, but still we would have a need to make some per application settings, like for kopete. But one important feature is, that the important buttons getting text is not about that you can read what it does, but that button size gets bigger. So you need aim less to hit that wanted button. In the example of my mockup where I used the Konqueror, I choosed Back/Forward buttons what are used mayby most times by normal usage. And then a Refresh and Print for examples. This way KDE usability experts, could do default settings as good as possible for KDE’s own applications. Still mixin the “Icon only” and “Icon+Text” modes.

    I use lots of “Icons-only” and “Text-alongside” modes. Depending of screensize, application, amount of buttons in toolbar etc. I like to do customizing when I start application first time. And in time when I use the application to add buttons what I need to toolbar to speed my work. Thats why I am hoping some day there is possiblity to add custom buttons to toolbar so you could add all the menu functions as buttons to toolbar what you want. Then hiding the menu when you dont need it so often than in current situation when hiding menu and finding that you need the one thing where you dont have button on toolbar, even you would have space.

    Kmail is one of this kinds (and Kword) where I always want to have this kind feature, to select what buttons gets text and what not. Because everytime I use them, i want to have different buttons on toolbar, but I would like to have text on “New Message”, “Check Mail”, “Reply”, “Trash” and “Create To-Do” and leave “Print” “Forward” “Previus/Next” etc buttons just with icons. And this gets even more important when you have netbook machine with 1024x600px resolution screen and you fight to save everyone pixel.

    The Blogposter who made the code-based mockup of Sanetoolbar, it just looks awesome. Getting only the needed buttons with text and others “hided” without text.
    Think how you could just give that kind UI for your grandmam who just sends email for family members and few closes friends. They need clean UI, but there should be important buttons still on toolbar, so they dont need to get to menu, but same time the most used functios should be founded right away. “Write New” and “Get Mail”.

    And if they still would add the Ctrl+M feature for Kmail to get the menu hided by default for people who dont need it… KMail could be even more the best Email Application for old people!!

  17. This is just a image for what I tried to say. The difference is not big for the code-version what Daniel made but this just has the menu hidden too. You can notice how does the UI actually change for smoother by the default settings of icons. If you could add the needed buttons to toolbar so the menu is not needed, it is possible to get KMail turned easy to use for old people.

    http://img362.imageshack.us/my.php?image=69351941de2.jpg

  19. I don’t really care what the defaults are, as long as I have the option to change the defaults. I don’t know what the current situation is (I couldn’t get Kubuntu to install so I’m still with XP), but please, options. If I want developers to decide what’s good for me I’d use Gnome.

  20. *If I want developers to decide what’s good for me I’d use Gnome.*

    The most important feature of usability is to allow user to configure the UI as s/he wants. But very important for usability is to have good default settings, so the avarage Joe does not need to first suffer from bad configs. But same thing follows the usability, if new user should not suffer from bad defaults, why should advanced user suffer same thing by forcing him to them?

    First, make default configs good as possible. Then, make configuration options as much it is possible.

    Those who dont care things and does not want to learn things, enjoys the default settings. Those who knows what they want, can actually change settings how they like them. And everyone are happy.

  21. I agree with mark. I don’t need text on the buttons I use all the time, but rather on the ones I don’t use often.

  22. Personally I don’t really care if this mixed alongside/icon-only mode is added. However, if, as Qt’s documentation suggests, it forcefully overrides the toolbar’s style, does this mean that for certain actions the text will be *always* alongside icons, even if the user explicitly says that the toolbar should be icon-only? Because that’d be a problem for me…

  23. “Text Alongside Icons” is, in my view, a good *default*. Applications for which this *default* is not best should use the setting that works best for that application. The same goes for users. It has always, and continues to be the case that the application specific toolbar settings should override the global *default*. The *default* is just that: If the toolbar setting is not specified at the application level, it should take on the *default* setting.

    Thanks for highlighting to application developers that they have more options and that the are not forced to use the *default* setting, or even any of the canned settings provided by KDE, if it is not appropriate to their application.

    To be clear though, all Celeste and Nuno are suggesting is what the *default* behaviour should be. For that purpose alone I actually like what Kubuntu has done.

    Hope this helps clarify for those who are a jumpy at every little change that’s made.

    peace and respect

  24. With XMLGUI that’s an implementation detail really. So yes, we need to think about it, but no, it’s not a problem really.

  25. Sorry, I lost my interest in your arguments at “If I want developers to decide what’s good for me I’d use Gnome”. Configuration is nice, but fighting for configuration options before a sane default is figured out is just the mindset that makes KDE look like crap. Also attempting to blackmail developers with the “or else” case is rather stupid. We have a brain of our own. Thankyouverymuch.

  26. “Configuration is nice, but fighting for configuration options before a sane default is figured out is just the mindset that makes KDE look like crap.”

    What you say is true, but what is even more crap… is that you cant even fight with configurations because you dont have any 😀

    The default sane configs are always needed. There is no sense if default settings are terrible and you have million different configurations available, they just dont fix the situation. So, make the good default settings and then configuration possibilities and everyone are happy.

  27. i think you found the best solution there.
    for me its ok to disable the text, but its not a solution to make ‘text aside icons’ the default. there are too many examples where this need way too much space.
    to have ‘text aside important icons’ would be great as default option. i think thats the best usability solution for now.
    but i might be missing some important facts 😉

  28. Good defaults are important, but they do not replace customization! Please don’t let KDE be like GNOME with forced settings! Several people (including me) want no labels on *any* of their icons, we should be able to set it up that way no matter what the default is.