[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 15:47:16
[Download RAW message or body]

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

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...

<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.

<snip>

> > > 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/bad
> >Interface.html
> >
> > :D
> :
> :-(
>
> Oh well, I do not quite like the idea...

:p

<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.

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).
- -- 
Mvg, Sander Devrieze.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/OQwKK+G8aHNHCSMRAsGvAKCkm9ok1AN/WvyDJwW3ls0A291oTQCaAtef
P6ASnIWIlLudiBW1XDOo/zY=
=HCa8
-----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]