I thought we had moved on from Window's adaptive menus. Moving menu items around inhibits the user, you can work more quickly if you know where the item is going to be.
That said, I love the way you can search menus, this is a feature that every toolkit should support. I don't know how long I've spent searching Gimp's erratically organised menus.
I don't see how this is innovative though, he would want to have some very convincing results from his usability tests.
In OS X from 10.5 on, the Help menu has a quick search box (command-shift-/ aka command-?) that works somewhat like this. I find it most useful in programs like Photoshop which I don't use enough to memorize the menu layout, but enough to where I know approximately the name of the menu command I need.
You find Gimp's core menus erratically organized or the extension/plugin menus erratically organized? I've had issue with the more recent incarnations of the preferences window, but the core Edit, Layer, Image menus I've had no problem with. If you're often using a plugin, which have traditionally, for some reason, been sorted into menus based on the language they're written in (thankfully this has been getting attention in the 2.x releases, now a few years old), then I can definitely sympathize.
Some filters and plugins might really be better if integrated into the core menus, but then you run into problems with a plugin seeming to override a core menu item (maybe this is desirable) producing a confusing interface for the user. In this regard, Gimp had taken a play from the likes of KPT, where all those cool filters were available as a separate (and guh, inconsistent) menu/UI to call them out as separate (although, in the case of KPT, it seemed to be more of a branding thing).
I think a lot of the problems stem from the need for a consistent UI being incompatible with a tool that is infinitely extendable by the user via installable plugins. You end up with something like the Windows 95 Start menu, where all vendors were effectively encouraged to put things wherever they wanted in the hope that you'd find them the easiest and/or associate the application with their brand (all Adobe products being in the Adobe subfolder, for example).
It isn't a product, but a research project. I typically name my projects whatever since they are internal and will most likely not lead to confusion in the marketplace.
I didn't mean to imply that it would be a bad thing if dnd from one window to another wasn't possible. I personally hate the dnd metaphor, which IMHO is an example of GUI designers gone wild, and would love to see it replaced with something else.
Some good ideas and a very well executed prototype are presented.
The window management concept seems very similar to recent mobile operating systems, specifically the "card" concept in Palm's webOS and the tiled window view in Nokia's Maemo 5.
It seems to me that the Stripes menu design presents too much information to be applicable to small mobile devices with low-res screens (e.g. iPhone), but it might be very effective on the new generation of mobile phones with higher screen resolutions (Motorola Droid/Milestone, Nokia N900).
It seems very interesting, but there is one thing I do not like, and that is having the menubar on the side. I always feel as though I'm losing so much screen real estate to it. (This is also the reason why I stopped using iGoogle as my homepage) Does anyone have any links to usability research that shows that having menus on the side vs the top is better? It looks like a few people are going this way in their designs, and I am wondering if it is just to make their product look different and new, or if there is actually sound logic behind the changes.
10 comments
[ 2.9 ms ] story [ 32.6 ms ] threadThat said, I love the way you can search menus, this is a feature that every toolkit should support. I don't know how long I've spent searching Gimp's erratically organised menus.
I don't see how this is innovative though, he would want to have some very convincing results from his usability tests.
Some filters and plugins might really be better if integrated into the core menus, but then you run into problems with a plugin seeming to override a core menu item (maybe this is desirable) producing a confusing interface for the user. In this regard, Gimp had taken a play from the likes of KPT, where all those cool filters were available as a separate (and guh, inconsistent) menu/UI to call them out as separate (although, in the case of KPT, it seemed to be more of a branding thing).
I think a lot of the problems stem from the need for a consistent UI being incompatible with a tool that is infinitely extendable by the user via installable plugins. You end up with something like the Windows 95 Start menu, where all vendors were effectively encouraged to put things wherever they wanted in the hope that you'd find them the easiest and/or associate the application with their brand (all Adobe products being in the Adobe subfolder, for example).
I guess you won't drag and drop elements from one window to the other with such a GUI.
The window management concept seems very similar to recent mobile operating systems, specifically the "card" concept in Palm's webOS and the tiled window view in Nokia's Maemo 5.
It seems to me that the Stripes menu design presents too much information to be applicable to small mobile devices with low-res screens (e.g. iPhone), but it might be very effective on the new generation of mobile phones with higher screen resolutions (Motorola Droid/Milestone, Nokia N900).