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

List:       kde-usability
Subject:    Re: TOM
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2003-05-22 20:57:21
[Download RAW message or body]

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

On Thursday 22 May 2003 02:08, b.walter@free.fr wrote:
> I think we should keep the menu as small/clean as possible and have focus
> on tasks that are really needed (and frequently needed). Of course the

what is really/frequently needed will vary from user to user, of course... but 
i generally agree with the sentiment...

> items in the Destinations categorie are very useful, but are not used that
> frequently.

frequency isn't the only issue. if a person needs to read a help file, they 
should be able to find it easily and quickly. having it hidden in a submenu 
does not help. i'd also suggest that "Browse my files" is a very common user 
action, as is exploring the network.

> Using a Destination submenu would be much better, such
> destinations would be great :

in which case it may as well just be a taskgroup and not a separate area of 
the menu at all. this would make it run-time configurable as an added bonus.

> - Browse my files (Home Directory)
> - Devices (I have not found a good expression for this one !)
> - See other computers (Network Neighbourhood)
> - Explore Trash
> - Find Files
> - Consult Manual

any reason for this particular ordering? or is it just what you feel would be 
most often used? if so, i'd put "See other computers" above "Devices". the 
first and last entries in the menu are special when it comes to focus, so i 
agree that "Browse my files" and "Consult Manuals" taking those positions 
could be good...

> It's nice that "Run command..." is not an "inline textbox". I don't think

yeah, it was a cool effect. but after using it for a while the novelty wore 
off and i decided against it... so i put in the Debate list instead ;-)

> A textbox in a submenu is not very common

TOM ground rule: the argument "is not very common" carries ZERO weight. i want 
to innovate if possible. i'd prefer to try zany ideas an rip them out later 
than not consider them at all just because they aren't common ideas.

> and is rather confusing.

how so? it was very obvious that it was a line edit, when you moused over the 
menu entry it got focus (the ibeam cursor would appear in the combobox and 
everything), so i can't agree here. i went to some great lengths to make sure 
that it was obvious.

> And of course it takes
> too much room, but you already explained everything in the README file :-)

yes, this is my real concern.. that it puts too much emphasis on something 
that isn't so vital as to deserve that emphasis.

> The new way group titles are printed in a popup menu is nice (it does not
> look like a disabled element anymore !), 

there are a few changes already in kdelibs that came out of my messing around 
with TOM, so TOM has already had some (hopefully positive) effect on KDE =)

> but I'm not sure this is really
> needed for this menu, it takes too much place, a separator would be enough
> (and cleaner).

the reason for the titles is: 

1. when you have a large menu with no obvious separations, the user has no 
cues as to why things are grouped that way. it is left up to the user to 
figure out the groupings. in this case, there are very real groupings that 
have very different meanings. a great example of this problem can be seen in 
the current K Menu where it shows Recent Applications as a list at the top of 
the menu with a simple separator. according to my user surveys very, very few 
people EVER make the connection between that list and what it actually is. 
labeling the list immediately made a difference. so i'd argue that my 
usability testing has shown that such labels dramatically improve user 
understanding of the menu.

2. by having obvious visual separators, the user is given easy to spot cues as 
to where the different parts of the menu are. once learned, the user can 
simply glance at the menu and tell by the visual cue, without even reading 
the contained label, where the tasks vs the destinations are. they are the 
menu equivalent of road signs.

3. i don't think the titles are non-clean at all. maybe that's just personal 
aesthetics, but i find them far less intrusive than the side image in the K 
Meu.

> Recent Applications/Documents should not be in toplevel. Most users want to
> find applications always at the same place.

there's a problem here, though. not all applications will be in the menu. some 
will be launched via Alt-F2, or by snooping about in the "More Applications" 
menu. these apps will accumulate in the Recent Apps menu.

perhaps a good observation would be that only applications NOT in the 
taskgroups should be shown in the Recent Apps menu, and perhaps change it to 
contain "Other Recently Used Apps"?

> Dynamic menus should be used as little as possible.

except to represent dynamic concepts?

> The only reason why a recent menu is useful is when you forget the location
> of your recent documents... But in this case, it does not matter if the
> Recent Document submenus is located somewhere else (in Destinations ?).

one of the ideas i'm trying in TOM (which is not to say that it's set in 
stone) is to divide things into semantically unique concepts. Tasks, 
Destinations, Recent Items, and the horribly named Special section. if we put 
recent documents in with destinations, destinations is no longer a static 
area that represents common shortcuts but is an ever changing area. the 
Recent section is meant to be dynamic and reflect usage temporally. if there 
is a set of recent items at all, i'd like them to be separated into their own 
section to aide understandability. other candidates for Recent Items would be 
things like appointments in your calendar.

> I have attached a png with a possible layout for the menu.

i can't open it.. every program i try says the same thing: that the file 
contains errors... =/ i even tried mozilla =) can you try doing it again? 
perhaps in a different format if whatever app you used to generate the PNG is 
somehow broken when it comes to PNGs?

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE: The 'K' is for 'kick ass'
http://www.kde.org       http://promo.kde.org/3.1/feature_guide.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+zTmx1rcusafx20MRAgfKAJsHMB00LsZWHoBFa7GlYDhPxPnOnACglfT+
x06/DQjwFvexfym53m9F7Zk=
=Pd7t
-----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]