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

List:       kde-core-devel
Subject:    Re: the "terminal sessions" kicker button behaviour...
From:       "Friedrich W. H.  Kossebau" <Friedrich.W.H () Kossebau ! de>
Date:       2004-02-17 23:41:13
Message-ID: 200402180041.13906.Friedrich.W.H () Kossebau ! de
[Download RAW message or body]

cc: usability to move over

Am Dienstag, 17. Februar 2004 23:49 schrieb Aaron Seigo:
> On February 17, 2004 13:48, Friedrich W. H.  Kossebau wrote:

#reinserted for understanding:#
> Am Dienstag, 17. Februar 2004 21:03 schrieb Aaron Seigo:
> > > On February 17, 2004 12:48, Alexander Neundorf wrote:
> > > > I can remember the time when the kicker terminal sessions button 
behaved like 
> > > > many other buttons in kde: clicking it opened a "normal" terminal and 
keeping 
> > > > it pressed opened the menu with the different session choices.
> > > > I think then there was some discussion that this behaviour is not good 
and 
> > > > doesn't follow ui guidelines and is inconsistent and it was changed to 
the 
> > > > way as it is today: both clicking and keeping it pressed opens the 
menu, i.e. 
> > > > to open a simple terminal you have to click twice.
> > > > 
> > > > Now with kde 3.2 I think this kicker terminal sessions buttons is the 
one
> > > > who behaves inconsistent to the rest of kde.
> > > > In konqueror the up, back and forward toolbar button and in kmail the 
check
> > > > mail, reply and forward buttons all feature the old behaviour: 
clicking
> > > > executes the default action and keeping pressed opens the menu.
> > > > Can we please revert the kicker terminal sessions button to this 
behaviour
> > > 
> > > but the konsole sessions button isn't in konqueror or kmail, or even on 
a
> > > toolbar. it's on the panel, and every other panel button behaves this 
way,
> > > including the Preferences menu button.
> > 
> > > as you noted, it was determined to be inconsistent and not to follow the 
UI
> > > guidelines. for menus and panel buttons, that is.
#reinserted end#

> > Hm... does nobody else see the panel as the toolbar of the desktop? Why
> > do we make a distinction here? Is it due to app-centric thinking?
>
> there are parallels, and as such i do treat them similarly in a variety of
> ways (such as the value of the space). but they are divergent since the
> panel:
>
>  o does not represent actions only
>  o contains menus
>  o contains completely dynamic and interactive elements
>  o does not have a corresponding menu where the same items are found
>
> these would likely all be style guide violations in a toolbar, but makes
> quite a bit of sense for the panel.

Then our style guide needs to be rewritten to take common use cases into 
account, like found in more complex apps like Konqueror, KOffice, KDevelop 
and many more. All over the place you will find at least menus and dynamic 
and interactive elements. 
Forgive me but I think our style guide should be more refined. After all it is 
called toolbar, not button bar ;) Too sad I still had not the time to come up 
with a full featured presentation of my toolets idea ;( (hopefully in april)

> so i personally see them as the same but different.

In which way different? Take your time and think about. I would guess it is 
the app centric thinking that we all got used to*. But this is a technical 
aspect and should/could be hidden IMHO. Take all the shell apps like 
KDevelop, Kate, Kontact, ... Are they still simple apps or more desktop 
oriented ones**? It's merging time. Welcome to the K Destop Environment! :)

*By the time and experience. Compare this to all the average users. The ones I 
have contact with usually do not talk about "word", "explorer" or "outlook" 
(oh yes, it is a world of sin here) but say "windows" or "my computer"

** E.g. in KDevelop you can add entries for external apps to be started from a 
menu.

So I would vote for to give the same user experience on the desktop's panel 
like on an app's toolbar.

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