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

List:       kde-usability
Subject:    Re: About icon RMB menus
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2003-11-26 23:19:18
[Download RAW message or body]

Hasso Tepper wrote:
> I agree that KDE 3.1 menus where big and pain to navigate. I agree 
> that something had to be done. But I don't think that the way it is 
> now in the HEAD is best one. I filed one bug about issue I found most 
> irritating - http://bugs.kde.org/show_bug.cgi?id=69099
> 
> But this is not the only issue. 
> 
> Look at icon RMB menu at the moment in konq. From top there are 
> entries to open file/directory in new window/tab, then standard 
> copy/move/rename etc, then open with menu, them preview with menu and 
> then action menu.
> 
> Now think about what user probably will want to do if it clicks on 
> icon with RMB. Click on directory - open in new window/tab? Yes, 
> probably. Click on tar.gz file? Open in new window/tab? I don't think 
> so. Mostly I will want to extract it to the current directory or open 
> in ark.

IMO, the important thing is that menu entries that don't do anything useful should be 
eliminated.  In this case, with a data file, you shouldn't have these choices when using 
them only results in an empty window or tab (there are better ways to get an empty window 
or tab).  For a data file, this means that if there isn't an embedded service available, 
then these two options shouldn't be there.

This, applying this general principle, does not agree with what you said about a: 
"*.tar.gz" file because you can open it in a new tab or window with Ark.  Note that 
opening it in a new window doesn't seem to work correctly, but that is a bug in 3.1.4 that 
appears to have been fixed.

Perhaps this is too complex to implement.

> My propsal: every icon RMB menu should contain most probable actions 
> in top. No more than two of them, they should be carefully chosen 
> etc, but IMHO it makes great difference to the direction of better 
> usability compared with current situation.
> 
I think that limiting to only two is too restrictive, but options that don't apply must be 
eliminated.

--
JRT

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