From this screenie, it should be obvious that KDE's new toolbar default of "Text Under Icons" does not work unless one has a screen with 5,000 x 5,000 resolution.
which nearly misses the point. it is very true that many of our toolbars when used with text under the icons take up a lot of screen space. however the problem is not bigger toolbar buttons, which are good for usability in many ways (more on that in a second). the real problem is that we cram so many (often stupid) things into our toolbars.
so what are toolbars for? toolbars give rapid access to the key actions in a given context (which is usually a task-specific window).
toolbars are not a billboard to advertise "neat-o" but rarely used features. that's what menubars are for. so when "mail" appears in a painting program's toolbar (kolourpaint) one really ought to say themselves, "wait a minute! this isn't an email program! this is a painting program! emailing a doodle isn't in the top 5% of actions! it's not a core part of this task's workflow!" and for most apps, even the top 5% of actions is going to be more than you want to shove in a toolbar.
another tip: if your toolbar icon's text is more than 2 short words long, ask yourself why you're being so wordy. probably it's because the action is ill defined or you're trying to be overly exact. remember that users can mouse over for tooltips and that once they learn the toolbar (given that it's learnable, e.g. less than 10 or so items on it) they won't rely on the verbage anyways: it becomes a matter of muscle and visual memory (placement and iconography). that's right, i'm looking at you "next unread message" in kmail and "mark feed as read" in akregator! why not just "read next" and "mark as read"?
in other words, changing the toolbar defaults is meant to make application developers rethink their abuse of the user experience through really poorly thought out toolbar entries.
i mentioned earlier that bigger buttons in the toolbars are better for usability. why? bigger objects are easier to point at. bigger objects also mean bigger icons which means greater clarity (22px icons are pretty hard to make really clear, particularly given the specificity of some of our actions). bigger objects mean fewer objects which means less clutter and greater learnability.
so rather than bemoan text-under-icons, perhaps take it as an opportunity to make your toolbars suck less(tm). users of kde4 will thank you. chances are you'll thank yourself.
25 comments:
"another tip: if your toolbar icon's text is more than 2 short words long, ask yourself why you're being so wordy."
Aaron, in in many languages, e.g. "properties" word takes so many space... This is also a problem...
Ok a few things...
on clarity, why not have the icons get bigger on mouse over like mac os's whoo bar?(no animations please!)
also it should be possible to have a table view of all the possible tool bar icons with the name of an action (used in scripting an application), the icon , and the description(tooltip). this would allow one to see the icon and mach it to a more memorable name and idea.
on selection of the most common actions. CUSTOMISABLE TOOLBARS!
> why not just "read next" and "mark as read"?
Because then you will end up with actions in the 'Configure Shortcuts' dialog are out of context and make no sense :(
You can only fix on if the other is fixes first..
@jaroslaw: 'in in many languages, e.g. "properties" word takes so many space.'
yes, the i18n issue is a hard one. we may end up having to simply change the defaults based on $LANG. no reason to cripple all environments simply because some languages are verbose.
@tim: "should be possible to have a table view"
this is coming with LiveUI. hamish already has a drag'n'drop toolbar editor, but it's blocked by limitations in xmlgui that will hopefully be addressed concretely with liveui.
"CUSTOMISABLE TOOLBARS!"
we of course already have this since kde2. however, there are limitations such as how the application not the user defines which toolbars an action can appear on. liveui also removes this issue.
@tzander: "You can only fix on if the other is fixes first."
sooo ... this would result in a cascade of fixes? sounds good to me ;)
ok, that was a bit glib. yes, it'll mean thinking about the names of our actions. i don't think that's a bad thing given the current state of affairs in many apps.
Besides the language problem already mentioned (which is not only about longer words but also the fact that some languages are a lot "wordier" than others where leaving out too many words makes the text just too awkward or just plain unreadable) there is also the problem of ambiguity: the "Mark As Read" happens to exist for both articles and feeds so which is it?
I'm slowly starting to believe MS has actually invented something useful with their new-fangled "ribbons". Maybe it's time to look for something better as well? :-)
or
You can fix the damn toolbar to not waste so many space, ain't that more simple?
Of course it is.
@quintesse: 'there is also the problem of ambiguity: the "Mark As Read" happens to exist for both articles and feeds so which is it?'
this is actually a problem in the akregator UI. marking a message as 'read' is pretty useless since you have click on it to do so which pretty much automatically marks it as read.
and perhaps the toolbar should operate only on the feeds. oh wait, it already does! =)
'I'm slowly starting to believe MS has actually invented something useful with their new-fangled "ribbons"'
perhaps. i'm waiting to see what happens when it hits the market. =)
@ramsees: 'You can fix the damn toolbar to not waste so many space, ain't that more simple?'
sorry, not sure what you mean exactly. could you be more verbose?
+1, you rule Mr. Seigo
I was surprised the other day when I used a fresh install of KDE - and saw the myriad of toolbuttons in konqueror which I'd happily forgotten about. I have a single toolbar with these buttons: back, forward, up, refresh, stop, clear url, url, enter, search, throbber. All at 22px. The only button I rarely use is the enter button. I thought I didn't use it at all until I removed it, and then got annoyed by its absence.
Anyway, I just think larger icons look nicer. And having text displayed by default is a good idea, although I'd get rid of it on my machine.
And fixing the toolbar customisation would be great. It's annoying when I delete a button and there's no way to add it back in, or a button refuses to go on the toolbar I want it on or one of the many other weird things that happen at the moment.
> @ramsees: 'You can fix the damn
> toolbar to not waste so many
> space, ain't that more simple?'
>
> sorry, not sure what you mean
> exactly. could you be more
> verbose?
To me, it sounds much like "I want the old behaviour back". Which is of course more simple, but doesn't improve a thing at the core.
I anticipate a KDE4 with text under icons as default. I've been using it since I started using KDE (around 3.2 or so) and can't wait for the day when Kontact/KMail's standard toolbar (including antispam buttons) fits on my 1400x1050px screen by default :)
Text under icons is also better than text alongside icons in every respect, and as such it's essentially the only way to make newbies use the toolbar who would otherwise be scared of icons "without immediately recognizable meaning".
But the font size should be cut down a little bit, like one or two points below the standard size (which is 10 point, right?) - I'm currently going with 8 point. The fonts being that wide is the main cause for lost space, and they are still readable in smaller sizes.
Hi Aseigo,
Maybe you can help me with this Kopete bug.
Kopete Chatwindow is really bloated. I can't even imagine it using text under toolbar items!
And I agree with Jakob, maybe you should tune toolbar items to reduce blanks, reduce fontsize a bit or other techniques to make it look better.
Thanks, good post!
The problem is this, you can't use the $LANG var because the toolbar will also depends of the global settings of the entire DE, you can turn the behavior the entire bunch of toolbars with one click in the control panel and see how some of them are not changing because they behive different and independent, and no, and option in the application like
"Respect global settings for toolbar" won't do, it will only bring more bload, so how do we solve the problem?
I guess with a better desing.
Aaron, I agree with everything you said, but I think smaller default fonts for button descriptions relative to the icon size would also be a welcome improvement. SUSE Desktop 10 seems to have gotten this right. Take a look at the how small “Home”, “Computer”, and “Search” are relative to the icons above them. Now compare this to the humongous writing of “New”, “Open”, and “Save” in Clarance’s screenshot.
Is possible to set button description font-size independently from the menu font size (ie. “File”, “Edit”, “View”, etc)? If so, the button descriptions should be a couple of points smaller.
@Ramsees: "you can't use the $LANG var because the toolbar will also depends of the global settings of the entire DE, you can turn the behavior the entire bunch of toolbars with one click in the control panel"
sure, but $LANG can influence the global default. if you set it to something else manually, well, that's your call. but the default could well be influenced by $LANG. voila.
@vladc6: "Is possible to set button description font-size independently from the menu font size"
yes, having a decent font for the toolbars will be a must if we go this route =)
>>'I'm slowly starting to believe
>>MS has actually invented
>>something useful with their
>>new-fangled "ribbons"'
>perhaps. i'm waiting to see what
>happens when it hits the market.
I saw the ribbon yesterday at my work, a guy there used it. He showed of powerpoint - wow, i was really amazed. He did amazing things in such an easy way, its hard to describe. but I love that ribbon...
As a happy KDE user I would just ask that it is possible to quickly restore KDE 3 defaults.
I don't care what the default is, but I detest text under icons. It wastes space and I actually like to have 20+ icons around to have direct access to most commands I EVER use.
I don't want to touch a menu unless it's for something I use for the first time. Menus are a terrible waste of time and disruptive to the workflow.
Of course I know I can configure toolbars, but again, that takes quite a bit of time, and the results are somewhat non-deterministic when toolbars get merged.
Therefore I'd really appreciate if a "many icon" option were in place besides whatever you guys decide to make the default.
aseigo:
"the real problem is that we cram so many (often stupid) things into our toolbars."
I disagree. At its current state, toolbar takes up equal amount of screen space whether it is showing a single icon or 10 icons.
I'd suggest a better shape for the toolbar (e.g., curved so that only the part which has icons takes screen space) or perhaps some autohide functionality.
Just my 0.02€
Wow. I didn't know that text under icons was the new default. What on Earth took so long (speaking as a user there who knows KDE's settings and turns this on immediately)?! I'm glad to see some sensible usability thinking is taking effect.
the real problem is that we cram so many (often stupid) things into our toolbars.
Indeed. It should be perfectly possible to give the common functions via the toolbar and organise everything else sensibly under menus or other methods. Of course, it gets slightly more complicated when users try to customise, but that also depends on other factors.
Whatever, there's a number of KDE applications who's interfaces and logic need to be tidied up desperately. This doesn't mean removing functionality, but simply better organisation. Turning Konqueror into a good seperate web browser and file browser is a good start. There's a lot of stuff in Konqueror that you just can't lump together, and the new toolbar default highlights it.
I'm slowly starting to believe MS has actually invented something useful with their new-fangled "ribbons". Maybe it's time to look for something better as well? :-)
Microsoft's ribbon came about because they now have too much stuff in their drop-down menus. The tried hiding some less commonly used menus, but that was a disaster because users wondered where everything had gone. Also, with more menu entries there was simply no visual feedback and icons for a user to recognise what they were.
The ribbon isn't a new concept at all, but no one has decided to do anything like it outside of Windows because drop-down menus are what people have been used to. Either that, or other systems have better organised applications.
[ Aaron J. Seigo ]
> how the application not the user
> defines which toolbars an action
> can appear on
Not the user?
Can you ellaborate on this?
I hope I will still be able to move the URL LineEdit of Konqueror from the URL toolbar to the main toolbar... So I have a clean Firefox-like toolbar in Konqueror.
Would be a shame if the URL LineEdit would be tied to the URL toolbar.
I've done the same for Kopete contact list, where I moved the search LineEdit into the main toolbar...
Even if I think toolbars should come well arranged by default (so I should never had customized the toolbar like that), I hope it will still be possible.
BTW, having text under icons is a very good move for KDE.
I tryed to do so in my KDE desktop, but sometimes it's hard to do because of poor labels... and non-configurable labels in the toolbar configure dialog. Should be customizable in KDE4, like icons are cutomizable in KDE3.
Aaron,
I totally agree. The problem is that a lot of KDE apps inherit a lot of toolbar elements from the kdelibs that are not widely used in these specific apps.
Check Kopete's chat window to understand what I mean. That's why I had started a thread about Kopete in the kde-usability list some months before.
It would be nice, if you bring the issue again in the list.
Icons + description in the toolbar is just (very) annoying redundance. Users unfamiliar with an application usually expect a short hint when holding the mouse still above the icon for a second or so. And everyone (blind persons aside) remembers the pictogram instead (re-)reading the text below. The text under toolbar icons (or text only) should probably be the default in a accessibility profile, but never the default for the "eye-animals" we are. Usability is in this case a matter of having high quality icons.
Also the additional text takes not only extra horizontal, but aso extra vertical space - it's not yet another toolbar button. Crammed toolbars is a completely different topic.
read that blog and just *had* to comment on it.
If some of the KDE devs - unfotunately important ones, that actually decide what such a default should be - think that text-under-icons is such a great idea, I'd urge them to have a look at even some toolbars in languages that are not as simple and use such extremely short words as english.
have a look at KMail and akregator for example. Yes, you used them as 'bad examples', but nevertheless: Turn on text -under-icons on on a german system or with another language that has similar long words... et voila.
Yes, the wording is much too long. But is it too specific? Hardly. It's just not possible to even have a good hint at the functionality of a button with one or two short(!) words in german.
"new feed" (maybe it's "newsfeed" in english at the moment, but I'd expect it to be "feed" by KDE 4) for example is "Neue Nachrichtenquelle" in german.
Sure there is "Nachrichtenquelle als gelesen markieren" (mark newsfeed as read) which is ridiculously long, but you still get "Nachrichtenquelle gelesen" or "als gelesen markieren" ("mark as read") if you want any kind of obvious meaning - just "gelesen" (read) doesn't make much sense.
That's just an example and you may find a solution for that, but there are thousand cases where it's not only really hard but nearly impossible to find any kind of good wording.
I'll just put it on my mental list of features-that-I-hate-in-kde4 and hope that it might still be possible to disable it, though a lot of configurability seems to be phased out.
It's great that people are realizing that the KDE toolbars are far too cluttered. This is a step in the right direction.
I'm not sure if you've seen how others do it... but I'd like you to consider this:
http://bugs.kde.org/show_bug.cgi?id=75970
The bug report above marked as "won't fix" mentions the "selective text on right" toolbar view-option.
IMO, as an experienced user, the "selective text on right" increases the ease of clicking the most used buttons*. I would have liked to see this as default, or at least as an option.
*) It is true that app creators should define in their code which buttons are the most used buttons (and should keep their text when "selective text on right" is chosen) but I don't find this a major problem since it increases usability for people which are already familiar with the app.
P.S. I must have missed this but... when was it decided that KDE4 will have "text under icons" by default?
Post a Comment