[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:       Christoph Niemann <cnieman () suse ! de>
Date:       2003-08-13 6:51:34
[Download RAW message or body]

On Tuesday 12 August 2003 17:47, Sander Devrieze wrote:
> Op dinsdag 12 augustus 2003 15:43, schreef Christoph Niemann:
> <snip>
>
> > > But also gets confused if they remove for example an entry...
> >
> > How would they do that? It's virtually impossible to _remove_ an
> > entry without trying to do exactly that conciously. To remove an
> > entry, you must RMB on the entry and select 'remove' from the
> > context menu. In every other case, the entry is not removed but at
> > most moved into another directory or onto the desktop.
>
> I actually have seen this happen...

Seriously? -- Well, point taken, then.

> <snip>
>
> > IMO, the difference is the complexity of the task. For advanced
> > uses KMenuEdit might be just The Right Tool (TM). However, for
> > simple tasks, such as reordering, direct manipulation is easier to
> > understand. Editing websites is much more complex and is not easily
> > done with direct manipulation tools (as evidenced by different
> > WYSIWYG website editors).
>
> And moving an entry from one submenu to another isn't complex? IMO
> this will be easier (and faster) with a separated application which
> shows a tree.

If you are planning on reordering the menu big time it might be easier 
to use the menu editor. Usually, however, it's just that one paticular 
application that you'd rather have somewhere else (for example: bring 
the one more often used application one level up). In this case it's 
rather cumbersome to start up another application, change the entry and 
close the application again. 

<snip>

> > > 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 ;)
> >
> > Which, of course, features a lot of direct manipulation, as this is
> > very usable in a variety of ways ;-)
>
> But also to have not more than 1 way to do things: look how you now
> have to configure task bars, the K-menu, the interface,... It's all
> done by a separated application and this is a very good thing IMO. I
> think it isn't good to change for example the font size, theme,...
> from the interface directly (so without KControl). The *only* things
> that the user may change directly are his own documents.

Except for the last sentence, I very much agree with you here. There is 
no need to make the font changeable directly. There are seperate 
applications for that. Again, it is the complexity demanding a seperate 
application here: If you want to change a font you have many different 
input values. You can change the font name, the weight, italics, the 
size and so on. There is no unambiguous way to map all these inputs to 
direct manipulation with a two dimensional input device like a mouse. 

Reordering does not fall in this complex task category. Moving an entry 
somewhere in the menu does exaxtly map to mouse movements. That's why 
it is so easy to understand. 

> You also have to keep the function of applications in mind.
> Applications like cat are succesful because they just do their job
> and not more. Bloated things aren't easy to maintain and so the
> chance for bugs is bigger. It's also more difficult for the user to
> know the real function of the application if it's bloatware. There
> are more of these bloat problems (also usability) in KDE. Luckily
> already some of these problems are fixed (e.g. kaddressbook-kmail
> separation).

Indeed, I am not at all for the swiss army knife approach. There are 
good reasons for having different applications for different tasks. 
OTOH, it is not good to split up applications too much either. cat may 
serve as an example again. It combines three different tasks (open, 
write content to stdout, close) into one application. Noone wants to 
bother about these tasks one by one. The same is valid for the KMenu. I 
don't want to bother about different applications if I just want an 
entry somewhere else.

On a side note: I also agree that KDE does not suffer from such a bad 
menu design as Windows. However, I do not take that as reason to make 
organizing the menu exceptionally hard.

Greetings,
Christoph

-- 
 | Christoph Niemann <cnieman@suse.de>
 | SuSE Usability Guild
 |
 | Contrary to popular opinion, the plural of 'anecdote' is not 'fact'.

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