[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-12 13:43:39
[Download RAW message or body]

On Tuesday 12 August 2003 14:29, Sander Devrieze wrote:
> 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...

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. 

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

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

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

No, I do not think popups are necessary. I was rather thinking along 
these lines:
  - If you start dragging an entry, a copy of the entry 
    appears under the mouse cursor (just like dragging 
    icons on the desktop)
  - As long as you hover above the menu, there should be 
    a line or something similar to indicate the target 
    place if you would drop the entry. (An example of 
    this can be seen in mozilla's bookmark editor, if you 
    reorder items)
  - To prevent entries from getting accidently lost in folders,
    you cannot drop them on the folders but only on the menu 
    displaying the contents of the folder.
>
> > 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/bad
>Interface.html
>
> :D

:-(
Oh well, I do not quite like the idea...

> :
> > 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 ;)

Which, of course, features a lot of direct manipulation, as this is very 
usable in a variety of ways ;-)


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]