toolbar icons

[Andreas Pakulat]

On 06.08.09 14:30:30, David Nolden wrote:
> Am Donnerstag 06 August 2009 13:49:21 schrieb Andreas Pakulat:
> > On 06.08.09 13:31:51, David Nolden wrote:
> > > Am Donnerstag 06 August 2009 13:07:18 schrieb Andreas Pakulat:
> > > > That takes a lot more time to memorize icon and action. And especially
> > > > with the toolbar the idea is to _quickly_ do something, not waiting
> > > > another second until the tooltip comes up and you can read what a
> > > > button does.
> > >
> > > In my experience, the toolbar is mainly useful to quickly do some very
> > > common action _again_ without having to remember keyboard shortcuts.
> > > Every toolbar action is also replicated in the menu, and should have the
> > > same icon there.
> > >
> > > So you can also learn the icon using the menu, and then use the toolbar
> > > to get quick access to that action.
> >
> > Still, to learn about the icon the user needs to do this actions a couple
> > of times. And that completely contradicts the "quickly" part, as navigating
> > the menu is slow, even more so if the user doesn't remember in which menu
> > the item was. Sure you could say that the action is simply placed in the
> > wrong menu, but we also cannot have a separate menu for each and every
> > "group of actions" as that would take too much space (look at the tools or
> > view menu for example).
> It's quicker to use the toolbar icon than the menu, so where's the 
> contradiction to "quickly"?
> 
> The menu has to be used anyway for many actions, as we want the toolbar to 
> contain only a hand full of selected actions. Removing the text from the 
> toolbar icons may lead the user to look at the menu first when wanting to 
> achieve something, rather than already having that randomly selected action in 
> the toolbar.
> 
> Not a big tradeoff IMO, as the menu has to be used anyway, and the price paid 
> for that little convenience of seeing the text is a either permanently reduced 
> productivity (For example, the context-browser line might not fit into the 
> screen, which is more useful than _any_ toolbar icon), or forcing the user to 
> reconfigure KDevelop. And an app that _needs_ to be reconfigured first before 
> it can fully shine is not a good app. Most of the shallow internet reviewers 
> would probably not even notice that there is something like a context-browser 
> bar, if it wasn't visible by default.

For sake of talking about what actually happens, lets look at the following
three screenshots I've just done after completely removing
$HOME/.kde/share/(config|apps)/kdev*, i.e. what is shown on initially
starting kdevelop.

First one without any changes whatsoever:
http://www.apaku.de/vardata/kdev4_initial_start.png

Two problems are clearly visible:
 - broken default size, the window needs to me a lot larger
 - the debugger toolbar needs to be moved to the debug area

However, both quickopen and contextbrowser toolbar are fully visible. Qt
properly compresses non-widget actions.

Now, lets remove the debugger toolbar:
http://www.apaku.de/vardata/kdev4_initial_nodbg.png

If we wouldn't have the perspective actions there, we'd have run, build or
debug visible already, without fixing the mainwindow size even

So, choosing a sane default, netbooks these days seem to have 1024x768
already, so I've resized the window to that (aproximately, taking a panel
into account) and we get:
http://www.apaku.de/vardata/kdev4_initial_sane_size.png

Again, without the area-actions and probably some less separators we'd have
the 5-6 most-used actions clearly visible and also the quickopen and
contextbrowser. So the user is surely aware of both widgets and both are
usable too as the expanded widget they show when activating them resizes
itself so that it shows all the information needed. 

And looking at:
http://www.apaku.de/vardata/kdev4_initial_ctxbrws.png

I can even use the context browser to see in which function I am in simpler
code (which is what beginner users will have usually).

Thats it, for me this case is clearly closed as removing the text doesn't
provide enough added value that make up for the problems caused by it.

Andreas

-- 
Don't worry.  Life's too long.
		-- Vincent Sardi, Jr.