On May 20, 2007, at 5:25 AM, Jacob Beauregard wrote: > > I was browsing looking for some usability studies on cascading menus > the other day (If you didn't know, I hate cascading menus). I found > this link. > > http://surfmind.com/masters/screens/the_making_of_a_visualization.html
Ah, Andy Edmonds! He and I used to chat about Mozilla usability back in the day. Unfortunately he went to work for Microsoft. :-) > The information that's on this page, and the visualization of it, could > probably bring someone who's mind is on usability, into > micro-usability. It reminds me of a picture I drew long ago to demonstrate why shortcut menu (aka context menu) submenus suck. <https://bugzilla.mozilla.org/show_bug.cgi?id=70830#c35> > For instance, in the diagrams, the users almost always move the mouse > toward the center of a menu before continuing. This is a strategy in > menu browsing, and eliminating the need for it could subconsciously > make the interface feel more usable. Why not center menus under the > mouse rather than the traditional method of drawing it right of the > mouse? The one exception for this of course, would be if centering a > menu under a mouse would interfere with the visibility of the menu. Well, that's right. More precisely, what do you do in cases where (height of submenu) > 2 * (distance from screen top to submenu title), such that you don't have room to center it? You have two choices: (1) Give the menu an upward auto-scroll arrow (even when it would easily fit on the screen without auto-scrolling at all), so as to preserve that center positioning. (2) Temporarily abandon the center positioning. With a menu bar this issue would come up fairly often, because menu bars are usually close to the top of the screen, so (distance from the screen top to the submenu title) is relatively small. If you chose (1), that would likely make those submenus more difficult to understand -- because submenus, like menus, tend to be designed so their structure can be scanned top-to-bottom. If you chose (2), the positioning of submenus would be inconsistent enough that people might never discern any pattern in it. It would be a repeated subtle distraction. (A related problem occurs with shortcut menus near the screen bottom. If you get used to using shortcut menus rapidly (in the way that every OS except Windows allows, because Windows opens them on mouseup rather than mousedown), you can memorize at least the first item as a gesture, rather than looking at it each time. The canonical example is "Back" in a Web browser's shortcut menu. But if you happen to open the menu near the bottom of the screen, and the menu is as long as it is in Firefox or Internet Explorer, the menu opens upward instead of downward and your gesture memory is useless. Netscape versions 2~4 for Mac are the only software, on any platform, that I've ever seen get this right: the menu still opens such that the first item is immediately southeast of the cursor, and there is an auto-scroll arrow at the bottom, even though the menu would fit on screen completely if it started higher up. That way your muscle memory is preserved for as many items as still fit between the cursor and the bottom of the screen. And preserving muscle memory is more important than all the items being visible to start with.) Another problem with centering submenus would be when the submenus were dynamic, with items added or removed over time. (An example of this is the "Edit" > "Remove Tag" submenu in F-Spot. I'm not suggesting it's a *good* example, but there it is.) When a submenu opens with its top aligned to the submenu title, only those items *below* an added/removed item will have changed position relative to the submenu title. But if the submenu was centered relative to its title, *every* time an item was added or removed, *every* other item would change position relative to the submenu title, which would be more disruptive to your muscle memory. If you have a long first-level submenu, though, you can give your users some of that centering goodness by placing the submenu item near the bottom of the main menu. This is, I assume, partly why the Encoding submenu is so low down in the "View" menus of Evolution, Firefox, and Konqueror. Their respective toolkits (correctly) don't align the top of the submenu with the top of its title if that would mean the menu never fits fully on-screen; they start it higher instead. So you get something close to centering. > ... > When my mom's digital camera wouldn't connect to Windows 98, I gave > her my desktop computer that uses GNOME. So I have to mention a few > more things about context menus that she gave her a hard time. Mostly, > she wants to be able to easily organize her photos in the file system. > She blames her problems on GNOME even though she obviously had never > done the same thing on Windows. This may not be a popular opinion around here, but IMO it's unfortunate that she ever had to know what "GNOME" was at all. Ubuntu, Suse, Fedora, fine -- but GNOME? That's like someone with an iPod having to know what Wolfson Microelectronics is. > Please keep in mind that all of the following is based on the Ubuntu > Feisty packages, so if you can't duplicate it with the latest GNOME, > don't shoot me. Ubuntu's release schedule is designed such that, except for a week or two each year, the latest release includes the latest Gnome. > 1. She was confused about what the context menus were referring to. One > solution would be to give context menus a header as to what they are > referring to. KDE does this for many panel applets and the system tray > already, but nothing else. GNOME doesn't have any similar behavior. It > could also be considered whether sub-headers would be useful, but at > this point I'm only recommending a header that states what the context > menu is for. Netscape 3 for Unix did this. One drawback is that it makes choosing the first item in the menu much slower -- you can't just mouse down, flick the mouse a pixel or two to the southeast, and let go. (I suppose you could make the header appear to the northeast, while the first menu item was still immediately to the southeast, but ... meh.) Another drawback is that shortcut menus often contain a grab-bag of whichever menu items happen to be used most often (hence the name), and/or items that apply to successively wider contexts, and in either case there won't be a coherent title you could give the menu anyway. (I can't remember what the Netscape 3 shortcut menu title was, but I'm pretty sure it was always the same regardless of where you opened it.) > 2. When I was trying to show her how to copy/cut/paste multiple files > at the same time, she continuously made the error of right clicking on > whitespace and therefore lost the selection she had made. Considering > how many files she was copying, this wasted a lot of time. I wouldn't > immediately be able to think of a solution for this. Jimmy Clarke addressed this. I don't have an opinion on whether the correct behavior should be to open the menu that's relevant to the selection, or the menu that's relevant to the position of the mouse, but I'd be interested in reading arguments for either. > 3. When she tried dragging photos into a folder, the size of the > thumbnail made it impossible to see whether or not the folder was > highlighted. I would categorize this as a bug, Yes, please report it as a bug if it hasn't been already. Items being dragged should never obscure drop targets, that's defeating the point. They should be either nearly transparent, or (if that's impossible with current technology) drawn just as an outline. > ... > 4. "Move to Trash" in the context menu confused her, because she is > familiar with calling it delete. She was especially confused because I > told her to "delete" the folders she had successfully moved all of the > files out of because they were now empty and useless. I'm not saying > this should change, though someone might have a bright idea of how to > end this confusion. There probably isn't a good way to solve this confusion, unless we somehow change the English language such that "delete" means what Windows claims it means, even though Microsoft knows it doesn't really. "When you delete a file or folder, the file or folder is not deleted right away", they say <http://urlx.org/microsoft.com/0cf03>. Wackos. > I can say though, it would have been beneficial for there to have been > a visual cue to whether or not the folder was empty, as the folder she > was moving to the trash was quite similarly named to another folder. Folder icons in Nautilus are depressingly unexpressive. How much do the folders have in them? What kind of files are they, mostly? How old are they? How often do you use them? You can't tell any of this by looking at the icon. > 5. When getting the message that moving files to a folder would > overwrite already existing files, she didn't know what to do. If I > hadn't told her to say skip and rename the files, she would have > overwritten the files with the same name. This presents a problem with > recoverability in moving files. I would suggest possibly making a > section in the trash for files that were overwritten from the > clipboard and from drag & drop behavior. The last time I read this suggestion was four years ago, from John Gruber. <http://daringfireball.net/2003/03/i_love_it_because_its_trash> I e-mailed him and said, in essence: "That wouldn't work, because what if you later went into the Trash, and selected the item that just got replaced, and chose 'Put Away'? [That's basically the classic Mac OS equivalent to 'Restore' in the Windows Recycle Bin, in case you're wondering.] The item in the Trash would replace the item you'd moved in the first place, so by the same rules, that item you'd moved originally would end up in the Trash, so the two items would swap places, it would look like nothing had happened, and would just be really strange." John replied with words to the effect of: "That's no problem, because as of Mac OS X, the Finder doesn't *have* a Put Away command any more." And I replied with words to the effect of: "What the hell?!?" Alas, Nautilus's Trash doesn't have a Restore command either. :-] And the problem I raised with John was an edge case which probably could be solved somehow, though I still don't know how. > The other problem with the overwrite dialog. It does not guide the user > through what they can do to move the file successfully. The user is > presented with: Skip All, Replace All, Skip, Replace. Even worse, the > user is presented with the question in BOLD, "Do you want to replace > it?" which may have lead her to click "Replace" and permanently lose a > large number of her photos. The mentioning of overwriting the > contents, even if she knew what that meant, wasn't in bold. > > I would suggest displaying thumbnails for both files in the dialog > that the user can open so that the user can see the difference between > the files. I would also STRONGLY suggest giving the option to rename > the file. This option should be failsafe, as it should not allow the > user to choose another filename that already exists, and should inform > them if they do so. I think everyone, when trying to design this alert, falls into the trap of thinking that people will look at it for any more than about half a second before making a choice. A few people may, but many won't. So you need to be *really really sparing*, choosing the elements that are *most likely* to help people. You want more than two buttons? Okay, that's your half second used up, no reading time left for thumbnails. You want to include thumbnails? Okay, that's your half second used up, no reading time left for more than two buttons. You want to include the files' modification dates? Okay, that's your half second used up, no reading time left for thumbnails *or* more than two buttons. > Another option would be to automatically rename all files, such that > on a collision with 00002.jpg, it will just name the file 00002_2.jpg, > and on collision 00003.jpg, it will just name the file 00003_2.jpg. > ... That option would be great for a separate "Merge" dialog, opened from an extra button in the replace confirmation alert. So of all the extra things *I* could choose to put in the replace confirmation alert, a "Merge..." button would be it. That way the alert itself could be kept really simple, but people who wanted to do complex selective replacements or renames could do it with an interface much less ridiculous than choosing "Skip" vs. "Replace" one item at a time no matter how many hundreds of items there are. But on the other hand, once Restore is implemented for the Trash, and Undo is implemented for moves/copies, we could just about get rid of the replace confirmation alert altogether, and use a notification bubble instead. "12 items in “Destination” were replaced by items you moved, and are now in the Trash. To reverse this, choose “Edit” > “Undo Move”." Cheers -- Matthew Paul Thomas http://mpt.net.nz/ _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
