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

List:       kde-usability
Subject:    Re: Kicker bar maiming
From:       Sander Devrieze <s.devrieze () pandora ! be>
Date:       2003-12-26 23:14:43
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op donderdag 25 december 2003 21:07, schreef Frans Englich:
> On Sunday 21 December 2003 11:13, Sander Devrieze wrote:
>
> Due to a KDE crash I've lost the latest 3-4 mails from our discussion but
> fortunately I don't think it matter. Anyway, I did read your BR before
> responding, I simply didn't take the 'preview' suggestion seriously.
>
> This is the sitation AFAICT; You think removing the konsole button is a
> good idea but for some reasons (I haven't fully grasped) it must be
> accompanied with an extra step in KPersonalizer where configuration of the
> Kicker is done. I oppose, and find the extra step a bad idea and find it
> unnecessary.
>
> This is the reasons:
>
> * We remove the konsole button because the majority of KDE's userbase does
> not use it. Thus, for the majority of the users, that default is not
> optimal, wastes screen space and is confusing. We remove it to avoid that
> and make the interface simple.
> (Those who wants it, the power users, are a minority and they will adapt to
> the majority. The same applies to all other minorities, such as the
> KFoulEggs addicts(imaginary speaking..) - they will too have adapt to the
> majority's preferences.)
>
> * For the perfect software, configuration is not needed.

That's *not* true: *all* software needs configuration. This is because there 
are different peoples with different tastes. Therefore KDE should make 
*configuring* simplier in place of saying "You should use this and we don't 
help you to change it!". We don't need to be a Gnome- or Windows-copy IMO... 
The last interfaces can be compared with fast food restaurants where people 
only can choose little things by there own. On the other hand, KDE is - and 
should stay in the future too IMO - a traditional restaurant where people can 
choose the food they like to eat (the interface) via a usable menu with many 
choices. In this "KDE restaurant" people can get assistence by a waiter or 
waitress when they don't know what something on the menu is, etc. 
(KPersonalizer, WhatsThisHelp, Howto's,...).

> And that is good
> because configuration is bad -

Configuration isn't bad: configuation is *good* when it's implemented in a 
usable way. There are people who are using KDE and not Gnome, MS Windows,... 
because of its configurability. The only smart thing (IMO) that we can do is 
to make configuration easier (and not removing configuration possibilities) 
and so have a DE which can live *beside* Gnome...

> it steals time from the actual purpose -
> using the software, is confusing and is just extra work for the user.

If you go to a traditional restaurant you also need some time before you can 
eat. If you don't like to choose your food by yourself or if you don't like 
to spend some little time in the beginning to look at the menu, to choose, to 
order and to wait until you can eat, you better go to a fast food restaurant 
where you don't have to wait (long), don't have to choose (limited 
choice),...

What I want to say, is that there is already a *good* "fast food restaurant 
FLOSS DE" and that it's bad to compete with it by changing our roots because 
our users use KDE because it's a "traditional restaurant DE".

(If all configuring is grouped and bundled, it's much less extra work.)

> This
> does in all it aspects apply to steps in KPersonalizer: the user has to
> parse and interpret an interface and then take decisions - we don't want
> that. We don't want configuration and should thus try to avoid adding
> another step to kpersonalizer.

That's what Gnome people want: it's not because KDE has no real HIG that we 
just have to copy the Gnome one.

> And no, you can't make a step in
> kpersonalizer optional.

Yes you can: you can add it at the end. Today you can *already* start 
*optionally* KControl in the last step. So other optional stepS (like the 
Kicker one, but also others) can be started also from there (via buttons with 
descriptive texts). Do you understand now?

> * We removed the konsole button in order to make life easier for the /most/
> people using KDE. Note, we didn't make it easier for power users or some
> other userbase group but, the decision made life easier for the /majority/
> of the users - from the big picture the outcome was positive.

It's like removing toilets for disabled people in a public building (ok, this 
is maybe a very strong comparison :D but so also very clear I hope)...

> If we add an extra step to KPersonalizer we make life more /difficult/ for
> _everyone_ - not just a minority or even the majority - it hurts /everyone/
> in order to please minorities. And I oppose to this - it is for the
> outlined reasons bad.

...what makes it more difficult for the majority to choose the right door and 
what makes it also harder to clean.

So see optional step-idea (and maybe also the restaurant things).

> * Having two interfaces for the same purpose  - KPersonalizer and kicker is
> from UI perspective bad.

KPersonalizer is the menu/waitress of the KDE restaurant: it will assist new 
users with configuring their DE in a comfortable and fast way without the 
need to configure it in different separated times. The waitress of KDE also 
knows what the KDE restaurant can serve to the newbie. She also knows what 
regular asked questions are (e.g.: Where's the toilet?), she points newbies 
to their table, etc. All this makes that she's the right person to help new 
but also existing users to explore the great world of wonderful configuration 
options of KDE without overwhelming them if she sees they don't like it.

> * The user don't really know what functionality she wants. Will I use
> konsole often? What is Konqueror and will I use it? Will I need to use the
> configuration functionality often?

I agree: big changes in KPersonalizer are necessary.

> Kicker's interface is not difficult to use and if it is, that is a very
> serious issue. Saying it is a punsishment (roughly) having to configure
> using the kicker is quite ridiculus, it is not a punishment or means more
> work than it means to have KPersonalizer and Kicker combined.

I mentioned it already before (not with the following words of course): It 
isn't comfortable if people need to choose the parts of their meal in 
different times: that's why a waiter/waitress gives you the menu *when you 
enter* the restaurant. When people have to choose after every course the next 
course their conversation will be everytime interrupted. The same applies to 
KDE: if people need to configure things when they remember that they need to 
do it, their work will be everytime interrupted (or they feel bad because it 
hinders them and they don't have the courage/time to change it at that time). 
Of course this will only hapen during the first weeks when the user is using 
KDE. However these first weeks are very important for the attitude of the 
user against KDE...this first time impression about KDE is quite important 
for managers who coordinate or plan a migration and also deciding for 
individuals: will they stay or will they leave using KDE?

> You can also look at it from another perspective:
> Do you agree that removing the konsole button is a good thing?

No, I only agree that it isn't necessary for some usergroup while there are 
usergroups for which it's important.

> In that case
> it is a wise decision removing it, no matter if the kpersonalizer step gets
> added or not.

I don't agree.

> After that, you can continue discussing /further/ improving
> KDE's UI, such as a kpersonalizer step(which is added to make life easier
> for the konsole/whatever users?). In other words, just because we don't
> know if one idea is good, shouldn't hinder us from driving through another.
> Especially when they are not related.

They are related: they are about how we handle usability: KDE way or Gnome 
way...?

> In either case you are in the situation of getting it implemented. Who will
> do that?

There are people enough who can make some code; this is only a detail.

> Correct me if I'm wrong, but AFAICT you are the only one who
> support this idea.

I don't hope so ;)

> And the implementation will be very hard to do

KDE was also impossible.

> and I
> don't understand how it will be possible.

I hope I was clear above? Sorry for all that text :)

> It will be duplicated
> functionality wrt to the kicker and somehow shrink the kicker to fit in the
> wizard.

Yes, of course there are some technical problems in my draft proposal. But 
it's about the idea. (you also may think about beter ways to implement it of 
course ;-)).

> Ok. I think I have summarized all my points in that long thread, hopefully
> somewhat more clearer and easier to understand.
> What is your position now?

I hope I was clear enough above. :)

> What are your comment?

See above.

- --
Mvg, Sander Devrieze.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/7MDpK+G8aHNHCSMRAmsUAJ434NLRq7epvh92qpN4p1pXkXA3xwCg2j0M
1caKCagBxgRGwywmXtVWcqU=
=NVRy
-----END PGP SIGNATURE-----

_______________________________________________
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]