[PATCH] "Show only important text" mode for toolbars
frans.englich at telia.com
Wed Sep 22 04:43:02 BST 2004
On Wednesday 22 September 2004 02:20, Peter Rockai (mornfall) wrote:
> I spoke with Aaron yesterday on IRC about toolbar plans for 3.4 and I asked
> what about the text-alongside-icons mode and overly long texts. He
> suggested adding a flag like textImportant to the actions and a checkbox
> (and toolbar context menu item) to show/hide "unimportant" texts.
I'm a big fan of simplicity. This adds yet another configuration option, and
it also pushes a usability decision upon the user(which we should do for
them). It adds a configuration option for everyone, for an feature which is
very little used(from anecdotal evidence). Perhaps the complexity it creates,
is more negative than the positiveness of any advantages it creates.
Here's some other disadvantages I see:
* It introduces a visual inconsistency, which perhaps is not esthetically
pleasing, and it can also lead to user confusion("Why is there no text on
this button while the other ones have?")
* It decentralize an important decision(it complicates development)
* It's a little bit of gambling; "important" items could still be long(a
factor one doesn't know since it involves translation), and those would the
user not be able to disable. In other words, whatever is tried to be
achieved, is largely dependent on what is important/unimportant
I wonder if we actually have a problem, and what the purpose of the
text-along-icon feature is. Why do the user activate that option at all? The
popular reason to enable labels underneath buttons(not the case) is to boost
working speed by spacing the buttons and making the hit area larger(Fittz
law). This is not achieved to the same extent when having the text on the
I don't know the purpose of the text-along-icons option(enlighten me); that
must be clear before any decisions about it is taken. For example, the
proposal assumes the text have a communication purpose, which is not the
usual reason for text on toolbars, AFAIK. It also assumes that buttons
actually can be categorized in important/unimportant.
For example, a more generic solution would be to crop long text("This is a
lo..."), but that have tons of implications, and could be backed up by tons
of different arguments -- depending on what the idea behind the
But the most critical IMO is that it adds yet more complexity to KDE.
In other words, I would like to have the assumption that we actually have
something to fix, clarified, before we focus on implementation issues.
More information about the kde-core-devel