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

List:       kde-usability
Subject:    Re: RMB - once again
From:       Henrique Pinto <stampede () lagoaminas ! com ! br>
Date:       2003-08-12 0:22:01
[Download RAW message or body]

Hi,

On Sunday 10 August 2003 10:55, Sander Devrieze wrote:
> ...but also possible to dissable. (Don't ask this again e.g.)

Huh?

> And much people are too lazy to spend time to change the default
> application manually...like me :D

But some are not. And these people wouldn't want to be bothered by popups.
Of course those popups shold offer a "Don't show this dialog box again" 
option, but that rises an issue. They have two options ( "Change" and "Not 
change", of course worded in another way). What should be the default if the 
user chooses not to see the dialog again?

> > Such a dialog should be simple.
> > What about puting this functionallity in the menu editor?
>
> I Agree.

Ok. Anyone disagrees? If not, I'll fill a wishlist item for KMenuEdit in 
b.k.o.

> > > The items in this list of applications could be draggeable in order
> > > that people may set their own preferred order.
> >
> > Agreed. And so should be the whole menu, not only this part.
>
> Not agreed: this functionality should be done by another dialog like now
> already possible with the K-menu (of course there are usability problems
> with this editor that needs to be solved).
>
> Why?
> o People don't use this functionality much.

Do you have data to backup this statement?

> o People will not know that this functionality exists.

Most people don't know it is possible to resize a window by holding the ALT 
key and pressing the right mouse button. Should this functionallity be 
removed only because of this?

> o People will get disappointed if they click wrong and so change their menu
> without knowing why it changed. (They will feel they have no control and
> this will results in fear when using KDE.)

Of course that should be done in a way that prevents this type of accident. 
There should be a sensible delay before it gets activated.

> o Doing it in another application makes it possible to add advanced
> functionallity in a simple and usable way. (e.g.: we can add the
> possibillity to change the actions in the Actions >> submenu.)

And why implementing this functionality would stop you from doing this? Or do 
you think one wouldn't need KMenuEdit anymore as soon as this gets 
implemented.

> o It will be easier to disable this functionallity with kiosk without
> having users complaining that their is a bug in their menus (they can't
> edit it).

I'm not sure I understood this statement fully. Preventing my users from 
accessing /, having shell access and other things is actually a feature for 
me, not a bug. And my users don't think KDE is buggy just because they can't 
browse /etc. Why would this be different?

And users getting confused by KIOSK restrictions is a problem that should be 
dealt by the sysadmin, not KDE. Is he the one who chooses what restrictions 
to apply or not.

BTW, someone pointed out in aseigo's blog that threads on kde-usability should 
be summarized in http://usability.kde.org/activity/recent/. This thread is a 
great candidate for this because:

1) It is getting rather big;
2) It deals with many things that were already discussed previously;
3) Many things were already agreed upon;
4) Many other things are too subjective for us to agree on them;
5) Because of its size, it is unlikely that many people will keep reading the 
whole thread to look for already agreed upon things and implement them.

What is the policy for submiting this kind of summary to the site?

-- 
	Henrique Pinto
	stampede@coltec.ufmg.br

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]