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

List:       kde-usability
Subject:    Re: KMenuEdit vs. direct manipulation [was: Re: RMB - once again]
From:       Sander Devrieze <s.devrieze () pandora ! be>
Date:       2003-08-12 12:29:37
[Download RAW message or body]

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

Op dinsdag 12 augustus 2003 12:14, schreef Christoph Niemann:
> On Tuesday 12 August 2003 09:03, Sander Devrieze wrote:
> > Op dinsdag 12 augustus 2003 02:22, schreef Henrique Pinto:
>
> <snip>
>
> > > > Why?
> > > > o People don't use this functionality much.
> > >
> > > Do you have data to backup this statement?
> >
> > No, but I see 2 kind of people I know who use MS Windows: some people
> > know this functionality and use it. Others don't know it and don't
> > use it. The difference between these groups is that the first is much
> > smaller and have much more experience with computers than the second.
> > Of course this is only with people I know, but I think this will be
> > the same if you do some tests with a lot more people.
>
> So, the group using direct manipulation of the KMenu probably likes it

I don't know for sure but I thought this group also use(d) the "kmenuedit" of 
MS Windows.

> and the other group ignores the feature.

But also gets confused if they remove for example an entry...

You can compare this thread with the difference between browsers like Amaya 
(not much) and other browsers/html editors. Because most people don't have to 
edit their menus every day several times and only need to view it, it's 
better to use a separated editor and viewer default IMO. Of course you can 
add (not default) a setting to have an Amaya style of using the menu

<snip>

> > > > 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.)
>
> On the contrary: If there is sufficient visual feedback, the users will
> feel even more in control.

I don't know how this can be easily done? Everytime popups? :s

> Actually, is a user bothers to reorder the
> menu, he will expect to be able to manipulate it directly.

We can make it possible to show a "don't show again popup" standard when you 
RMB click. This dialog can points the user to the place where he can change 
his menu.

> The reason
> is that Windows implemented this feature since Win98 (I believe).

Maybe something to add on this page:
http://developer.kde.org/documentation/standards/kde/style/basics/badInterface.html
:D

> The use of direct manipulation eliminates much the necessary interface
> knowledge a user needs to use KMenuEdit.

I agree that KMenuEdit needs a usability review...

> Thus, the user can focus on
> task knowledge, the tool (KMenuEdit) disappears and the users feels
> like he is in control. The direct manipulation of the menu is therefore
> more intuitive.
>
> Still, KMenuEdit might be useful for advanced features (as has already
> been noted) but for reordering and similar simple tasks, direct
> manipulation should be easier for users.

If we focus on making KMenuEdit simplier, adding an interactive tutoial like 
in KLines CVS (which is difficult to implement for the Amaya style menus idea 
I think),.... it should be much better than implement a duplicate way (new 
for people who already can use KMenuEdit). How will you act e.g. with hidden 
menu entries in the Amaya way? IMO it's not because windows has such 
functionality we also should introduce such thing: that's the goal of XPde, 
not KDE... One of our goals is to have a much better GUI ;)

<snip>

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

iD8DBQE/ON21K+G8aHNHCSMRAs+wAJ9NsdVg/Dj8BRJXt72Q9/4BsrLS1QCfbrU6
4H2BSSLn9KqaA1Pqhh0dohw=
=ombS
-----END PGP SIGNATURE-----

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