[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: powerful tooltips,
From:       <triankar_dev () yahoo ! gr>
Date:       2003-11-15 5:20:28
[Download RAW message or body]

Hello all,

I'd like to chip in my two cents on the toolbar
clutter topic (and modification, while we're at it).


1. Button clutter
It's the more novice users that will want more buttons
on the toolbar (eg. cut copy paste), while more
experienced users tend to use keyboard shortcuts more
often. (When was the last time you used the Cut/Copy
button?, what does a Print button do in a file
manager?).

Having said that, a 30-button toolbar is not going to
help a novice (have you tried Ultraedit in Windows?).
So people need choice, and if they're novice, they
probably shouldn't get their hands too dirty. ;-)

We could be encouraged to keep a minimal set of icons
as the barebones toolbar and then add *individual*
buttons as required (or maybe a toolbar right-click
option to select an 'expertise level', much like text
position, size etc.).

(I say 'encourage' because it's going to be
difficult/ugly to provide a generic infrastructure
that automagically disables 'novice' buttons for every
KDE app when it 'detects' an expert user during
configuration. This is in fact my grief with point
#2.)


2. Toolbar configurability.
---------------------------
Suppose you're an 'expert' user and you want to tweak
the toolbars. In many apps there are component-related
toolbars that somehow mix/insert buttons beyond your
control.

An example is KWrite: Say you want a toolbar with
[new][open][save][search][print] in this order,
instead of the standard toolbar. When you try to
customise the toolbar, there's a kwrite and a
kpartview toolbar. In the editor they look like
separate toolbars, but actually they display with
their buttons interleaved! It'd be ok if they
displayed as separate (sub)toolbars, but they do mix
in a way that in the end you simply *cannot* get what
you want (try it!).

I understand this happened for the sake of modularity
(most likely), so that the katePartView toolbar has
its own components common across apps that use it, but
I believe it's the wrong kind of modularity.


I don't know if the latter issue has been addressed at
3.2, but I could not find anything about it in the
list archive. Sorry if I missed something or this was
discussed before.

regards,

Trian
(back from a 2-month absence due to uni work :-)


____________________________________________________________
Do You Yahoo!?
Αποκτήστε τη δωρεάν @yahoo.gr διεύθυνση σας στο http://www.otenet.gr
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]