toolbar icons
Andreas Pakulat
apaku at gmx.de
Sun Aug 9 10:21:40 UTC 2009
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"?
You missed my point, until you've fully learned what the icon represents
you have to use the menu. So until you've memorized the icon and its
association with a given action you're much much slower at executing the
action. Not to mention that in this case you'll also have to memorize which
menu the action was in or search a couple of seconds for the right menu. If
the toolbar icon has a proper text with it however, all you need to do is
quickly glance through the toolbar.
> The menu has to be used anyway for many actions, as we want the toolbar to
> contain only a hand full of selected actions.
Right.
> 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.
I don't think so. A user that doesn't see an action in the toolbar will go
to the menu. However with no text its harder for the user to decide wether
the action is in the toolbar or not, so he's more likely to always walk
through the menu, rendering the toolbar pretty much useless.
> 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.
Thats your personal opinion. I'm valueing first-time-users (not just
developers using kdevelop for the first time, or even an IDE, but also
people who just start off becoming developers) way way higher than the need
for experienced users to do a right-click+select an option.
> 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.
Who said it wouldn't be visible by default? I never said it should be
hidden. If it doesn't fit all in one line, it'll have a separate line by
default.
Andreas
--
Celebrate Hannibal Day this year. Take an elephant to lunch.
More information about the KDevelop-devel
mailing list