Just for the record, the Windows Vista start menu does this list thingy too. But you can still choose to have hiararchical menus à la w95 if you want to.
have you looked at gnome-do? its the gnome answer to spotlight / quicksilver, you invoke it, start typing and it lists matches in a somewhat similiar manner.
The current release in ubuntu is somewhat patchy, but I really hope they work hard on it and enable it by default in the next release, its an awesomely useful application that has at times replaced
1. the menu bars completely,
2. a lot of trivial stuff done in the shell (copying / findings files)
3. the awesomebar for firefox
4. navigational controls (alt+tab for window focus)
"somewhat patchy" is an understatement. it's probably the buggiest software I use on a daily basis. That being said, I use it on a daily basis and wouldn't dream of going back to doing things the old way.
I vaguelly remember a drunken conversation with an ubuntu "high up" saying they were either working hard on gnome-do or an alternative, and that there would be a lot of focus on it for one of the upcoming releases.
This works for smaller amounts of data, but hierarchies are still needed to sort very large amounts of data that have to be accessed at any time. Yes indexing/searching/filtering is an option but when you have 1GB of pure text, searching "the company" is gonna get you several hundred hits. Google excels at this because they've created ways to dynamically optimize their results via user input. However no one is gonna do that for your private docs.
Personally krunner like gnome-do is useful but not for searching my files, because it gives no context. Someone needs to create a good kde app/plugin for context able searching through strigi.
Overall I enjoyed (and agreed with) the points here, however I have three reservations:
The first is that the big-filtered-list depends on jumping from the mouse to the keyboard and back (if I'm mistaken, the means of using the keyboard exclusively are not obvious enough). This is an expensive jump and should be avoided in most common cases.
The second is that you usually don't know what you are looking for (otherwise you wouldn't have to look, you would just "know" where it is). In this case, textural filtering doesn't help you (although the meta-description idea for searching programs addresses this in the application launching context).
My third reservation has to do with the concept of "most recently used". This implies that the list's contents (or at least their order) is dynamic in nature and this is very destructive to the ability to memorize the location of commands. There is a temporary advantage to the unaccustomed user, but for most "desktop" applications this user is the minority (hopefully) and moving things around punishes the daily user.
Again I want to re-state that I think there are allot of good ideas here and implemented as-is would result in a vastly improved user experience, but I believe with a few of these issues addressed it could improve the current state without introducing new problems.
"The first is that the big-filtered-list depends on jumping from the mouse to the keyboard and back (if I'm mistaken, the means of using the keyboard exclusively are not obvious enough)."
Well, the obvious one is to permit the cursor controls to work in the filtered list, which is trivial and reasonably intuitive. See also the Awesomebar, where left & right move around in the text box but up and down actually move the focus. There are other possibilities, but probably none that good.
"This implies that the list's contents (or at least their order) is dynamic in nature and this is very destructive to the ability to memorize the location of commands."
A valid point, but part of the idea here is to toss out the entire "memorize the location of commands" in the first place, I think. Build a system whereby users swiftly get taught keyboard shortcuts (even if they are "[command key], w, e, b, DOWN, DOWN, enter" in some cases) and the need to have locations memorized goes away.
Personally, I'm unconvinced the "location memorization" is of such great value we need to contort the rest of the interface in order to not throw it away.
"Personally, I'm unconvinced the "location memorization" is of such great value we need to contort the rest of the interface in order to not throw it away."
I might agree for general-purpose computing however professional operators with traditionally "workstation" tasks (CAD/CAM, video editing, forms processing, etc.) would strongly disagree. For these individuals, much time has been invested in the physical memorization of commands, allowing them to issue the commands as if they were any other trained function of the body (catching a ball, for example). Having to stop and think about operating the software causes a mental "page fault", removing their focus from the work and wasting time.
I don't want to get off-topic, but many professionals have expressed dismay with the move from workstation computers to PC's for this reason.
There's probably an approach we can take based on this that retains the location-friendliness without reverting back to old menus.
Then again, I'd say, for any existing system built for experts... just keep the current UI! There's no chance this is ever going to be _mandated_, after all.
Most of what he says is right on, but that reworked Paint.NET menu is just insane. There is nothing even remotely usable about it. It looks like someone threw dynamite in a widget factory.
As far as searching menus is concerned, OS X already has this. Hit Command + ? (that's Command + Shift + /) to bring up the search field in the Help menu and start searching.
"I should note that this isn’t terribly radical, and in fact, it isn’t all that different from the direction Gnome and KDE have been heading."
Given that he just seems to be proposing the Vista-style Start menu (which I think is a good thing) is not that radical, no.
Alan Cooper covered most of this in his book, "About Face", but Cooper noticed the important things which seem to have gone missed (well, it is Cooper's job, after all).
For instance, getting rid of the menu altogether is probably a mistake. Cooper pointed out that the menu is the pedagogical interface. i.e. the way people learn how to use programs, and what programs can do, is to go through the menus and find stuff. Just by looking through menus is a good way to get a feel for what a program can and can't do (one of the reasons why you should only grey/disable menu items, and not sub-menus).
The way a lot of users actually use the program once they've learned it is with toolbars, shortcut keys, direct manipulation, etc. Some people still use menus all the time, and most people will use menus for the features they don't use often.
The Office ribbon is a smart evolution of the UI - you can still explore the ribbon to find out how to do stuff, but that stuff is generally more available than hidden away on a menu.
Presenting people with either an empty box that they have to type a search into, or a massive pane of everything the user can do (seemingly what he suggests with his Paint reworking), doesn't seem like a great idea. By this I mean that it takes away the user's ability to learn a program as easily.
Having all of your apps located in a big zoomable space has many of the advantages of a list. Also, if the desktop space is large enough, why not just have the application window sitting in there?
I think many of the metaphors of computers could be collapsed into just two or three large zoomable spaces. Have a desktop with your apps and documents, which would behave somewhat like the current OS X dock. It would have more representational real estate -- namely the whole screen. Actually, it would be even larger, since it is zoomable. Like the dock/desktop, it represents your current "working set." But to put an item back, you'd just have to right-click and select "put back." Bringing an item to your desktop wouldn't move it, so much as give it a visible alias there. There would also be a larger zoomable space which would just contain everything. Perhaps you could have an indexing scheme with the apps along the left edge, with their associated documents trailing out to the right in order of decreasing recency. The "Finder" app would have everything associated with it, of course.
I really liked the original idea of Windows 3.1's desktop; it was simply ahead of its time. Under 3.1, an icon is a window, and vice-versa. Instead of "minimizing" a window, you "iconify" it. In a zoomable interface, the icon would simply be a mipmap—that is, at a small resolution (16x16) it would be artwork, but at a large enough scale it would be the window itself, fully manipulable. Every representation of a saved file would simply be the window displaying the file as it was when it was open. In that way, it would be a lot more like a Squeak image, or an emulator save-state. Actually, since there would be no difference between "minimizing" and "closing" a document (both "sleep" the document image, and then suspend/serialize it to disk, and both create an icon), it has distinct similarities to the iPhone OS.
Right. This would get the user out of the business of "saving" their work. When you've just written stuff down on a notepad, you don't have to "save" it. It's just there. Computer apps should be like that.
»I realized that I spent a considerable amount of time with task-switching activities — searching for the very same applications, documents, files and folders on my hard disk again and again. The better those items were organized in hierarchical structures such as folders and subfolders, the more time it took to reveal these items.«
[…]
»The very first "prototype" was not even an application. It all began with dozens of little shell scripts and a tiny Terminal window. Each of the scripts had a very short one- or two-letter name and just opened one specific application or document. The Terminal window was placed in one of the screen corners, allowing us to bring it to the front quickly using the mouse. When we wanted to launch Interface Builder, for instance, we just had to click that screen corner, enter "IB"«
24 comments
[ 743 ms ] story [ 742 ms ] threadWindows is still based on Windows 95 hierarchical menus. Btw. I never use those Windows menus unless the system forces me to.
If you have indexing enabled (client-side for local data and server-side for network shares) it can scour trough gigabytes of data in no speed.
It's obvious that he that said that "Windows is still based on Windows 95 hierarchical menus" haven't really used Windows the last 5 years.
have you looked at gnome-do? its the gnome answer to spotlight / quicksilver, you invoke it, start typing and it lists matches in a somewhat similiar manner.
The current release in ubuntu is somewhat patchy, but I really hope they work hard on it and enable it by default in the next release, its an awesomely useful application that has at times replaced
1. the menu bars completely,
2. a lot of trivial stuff done in the shell (copying / findings files)
3. the awesomebar for firefox
4. navigational controls (alt+tab for window focus)
I vaguelly remember a drunken conversation with an ubuntu "high up" saying they were either working hard on gnome-do or an alternative, and that there would be a lot of focus on it for one of the upcoming releases.
Personally krunner like gnome-do is useful but not for searching my files, because it gives no context. Someone needs to create a good kde app/plugin for context able searching through strigi.
press s + SPACE / TAB, then start typing, it matches on 1. directories, 2. google autocomplete results,
if I pick a directory, then I tab to enter a phrase to search for, if its google, then the search is performed.
http://video.google.com/videosearch?q=gnome%20spaces&oe=...
http://www.launchy.net/
http://code.google.com/p/putty-launchy-plugin/
The first is that the big-filtered-list depends on jumping from the mouse to the keyboard and back (if I'm mistaken, the means of using the keyboard exclusively are not obvious enough). This is an expensive jump and should be avoided in most common cases.
The second is that you usually don't know what you are looking for (otherwise you wouldn't have to look, you would just "know" where it is). In this case, textural filtering doesn't help you (although the meta-description idea for searching programs addresses this in the application launching context).
My third reservation has to do with the concept of "most recently used". This implies that the list's contents (or at least their order) is dynamic in nature and this is very destructive to the ability to memorize the location of commands. There is a temporary advantage to the unaccustomed user, but for most "desktop" applications this user is the minority (hopefully) and moving things around punishes the daily user.
Again I want to re-state that I think there are allot of good ideas here and implemented as-is would result in a vastly improved user experience, but I believe with a few of these issues addressed it could improve the current state without introducing new problems.
Well, the obvious one is to permit the cursor controls to work in the filtered list, which is trivial and reasonably intuitive. See also the Awesomebar, where left & right move around in the text box but up and down actually move the focus. There are other possibilities, but probably none that good.
"This implies that the list's contents (or at least their order) is dynamic in nature and this is very destructive to the ability to memorize the location of commands."
A valid point, but part of the idea here is to toss out the entire "memorize the location of commands" in the first place, I think. Build a system whereby users swiftly get taught keyboard shortcuts (even if they are "[command key], w, e, b, DOWN, DOWN, enter" in some cases) and the need to have locations memorized goes away.
Personally, I'm unconvinced the "location memorization" is of such great value we need to contort the rest of the interface in order to not throw it away.
I might agree for general-purpose computing however professional operators with traditionally "workstation" tasks (CAD/CAM, video editing, forms processing, etc.) would strongly disagree. For these individuals, much time has been invested in the physical memorization of commands, allowing them to issue the commands as if they were any other trained function of the body (catching a ball, for example). Having to stop and think about operating the software causes a mental "page fault", removing their focus from the work and wasting time.
I don't want to get off-topic, but many professionals have expressed dismay with the move from workstation computers to PC's for this reason.
Then again, I'd say, for any existing system built for experts... just keep the current UI! There's no chance this is ever going to be _mandated_, after all.
Given that he just seems to be proposing the Vista-style Start menu (which I think is a good thing) is not that radical, no.
Alan Cooper covered most of this in his book, "About Face", but Cooper noticed the important things which seem to have gone missed (well, it is Cooper's job, after all).
For instance, getting rid of the menu altogether is probably a mistake. Cooper pointed out that the menu is the pedagogical interface. i.e. the way people learn how to use programs, and what programs can do, is to go through the menus and find stuff. Just by looking through menus is a good way to get a feel for what a program can and can't do (one of the reasons why you should only grey/disable menu items, and not sub-menus).
The way a lot of users actually use the program once they've learned it is with toolbars, shortcut keys, direct manipulation, etc. Some people still use menus all the time, and most people will use menus for the features they don't use often.
The Office ribbon is a smart evolution of the UI - you can still explore the ribbon to find out how to do stuff, but that stuff is generally more available than hidden away on a menu.
Presenting people with either an empty box that they have to type a search into, or a massive pane of everything the user can do (seemingly what he suggests with his Paint reworking), doesn't seem like a great idea. By this I mean that it takes away the user's ability to learn a program as easily.
I think many of the metaphors of computers could be collapsed into just two or three large zoomable spaces. Have a desktop with your apps and documents, which would behave somewhat like the current OS X dock. It would have more representational real estate -- namely the whole screen. Actually, it would be even larger, since it is zoomable. Like the dock/desktop, it represents your current "working set." But to put an item back, you'd just have to right-click and select "put back." Bringing an item to your desktop wouldn't move it, so much as give it a visible alias there. There would also be a larger zoomable space which would just contain everything. Perhaps you could have an indexing scheme with the apps along the left edge, with their associated documents trailing out to the right in order of decreasing recency. The "Finder" app would have everything associated with it, of course.
From the interview:
»I realized that I spent a considerable amount of time with task-switching activities — searching for the very same applications, documents, files and folders on my hard disk again and again. The better those items were organized in hierarchical structures such as folders and subfolders, the more time it took to reveal these items.«
[…]
»The very first "prototype" was not even an application. It all began with dozens of little shell scripts and a tiny Terminal window. Each of the scripts had a very short one- or two-letter name and just opened one specific application or document. The Terminal window was placed in one of the screen corners, allowing us to bring it to the front quickly using the mouse. When we wanted to launch Interface Builder, for instance, we just had to click that screen corner, enter "IB"«
The idea was later taken to the extreme by Quicksilver: http://www.blacktree.com/ — the author of which now does Google’s Quick Search Box: http://googlemac.blogspot.com/2009/06/introducing-google-qui...