> The HUD will be introduced with the next version of Ubuntu, 12.04
> Shuttleworth: "It will be interesting to see how users react to the changes."
Please... this is an LTS release and your users aren't guinea pigs. I would hate to see another potentially promising feature get bad-mouthed all over the place due to premature release. Something like this needs months of usability testing. Couldn't they just wait until 12.10?
From the article: "although the old menu system will still be available for those who don’t want to use HUD or want to explore the available commands"
In addition, users upgrading from 10.04 LTS to 12.04 LTS are already getting Unity (which is already in itself a breaking change). I see no reason to delay the introduction of this menu system.
As a user jumping between LTS versions I welcome both the introduction of Unity and the addition of keyboard-driven, menu searches.
I see your point though: maybe a better solution would be to have it in the LTS but disabled by default?
I think the best solution would be packaging Unity/HUD separate from LTS and requiring the user to install it, if they wanted to, like they could with any desktop environment.
Of course, if it was already installed on the system pre-update it would install and update Unity/HUD.
They could also make it an option on their already very option heavy (which is good) download page.
I thought it was odd too that they'd put this in an LTS release, however it's not a done deal yet:
Landing in 12.04 LTS is gated on more widespread testing. You can of course try this out from a PPA or branch the code in Launchpad (you will need these two branches). Or dig deeper with blogs on the topic from Ted Gould, Olli Ries and Gord Allott. Welcome to 2012 everybody!
But that's the whole reason I'm using Ubuntu in the first place: sensible defaults. There are plenty of other great distros out there and switching is easy, especially to such a close relative of Ubuntu like Debian.
Too much user-friendly cruft in Ubuntu now. Debian keeps the good parts and doesn't make me do extra work disabling the WM and friends. XMonad >>= that was easy.
This is an incredibly underappreciated functionality. OS X's help menu is a close equivalent to ido-mode in emacs. You hit Cmd+Shift+/ and type in first few letters of the name of some command you're looking for, select it in the drop-down menu, and there pops a thick wobbling arrow pointing at its location in the normal menu hierarchy. Fantastically useful.
I haven't seen the OSX Help menu but I've seen this feature implemented in several other program on Windows and Linux years ago. They don't seem to catch on but I'm not sure why. Maybe it's habit or the fact search seems like more effort or the need to know the exact name for something or that people prefer the 'presence' that menus give to options. Personally I think it's great, as long as there's an option to restore menus so you can 'browse' like you suggest.
What’s great about OS X’s approach is that it’s always there, in every app. (Some apps disable it which is a good way to make me angry.) Especially when you open up a brand new app or one you are not using frequently it can be frustrating to get your bearings. I can, for example, never remember where I can lock or group objects (I’m not even sure whether those commands are usually in a consistent place), the search is a good way to find out whether that functionality is available and where I can find it, also for future reference. Scanning menus for a specific command when I have no idea where it is is very frustrating for me.
This wouldn’t really work if every app had to implement this feature on its own, probably in different places and with slightly different behavior. Even if the behavior were consistent you still could never be sure whether you can search in the first place, that uncertainty is in my experience a good way to make sure a feature will never get used.
The OS X Help menu combines the two approaches. You type the command name, and it opens and highlights the appropriate menu for the result — complete with a big animated arrow next to the item you're choosing — so then you know where to find the menu item next time.
This is a great start, but I hope it goes so much further. I always liked the (now defunct) Ubiquity project. Here's the first video they made, it's so ambitious! http://vimeo.com/1561578 You could bring up a browser command-line and start typing the name of a command, say "map" to look something up on Google Maps. As soon as you type 'm' it would give a list of autocomplete options. The internationalized parser had a concept of subjects, verbs, and objects, and could autocomplete or even guess some of them.
But the coolest part was how you could add functionality. The framework let you write new commands that interacted well with the parser and gave hints to the autocomplete, and even custom UI with HTML & JS. And then users could subscribe to your commands. Ubiquity would cache the code and periodically, seamlessly upgrade your browser with new versions of the commands you subscribed to.
I was very sad when they discontinued development, and Unity looks like an excellent place to put these ideas to work again.
Actually, my first thought was "This reminds me of Enso", Enso being the predecessor to Ubiquity(by the same people before they were hired by Mozilla), but integrated into the desktop as a whole rather than the browser.
Unfortunately, my main complaint with Enso and Ubiquity was that both were unfortunately rather buggy. And given Ubuntu's track record with Unity, I suspect that it will be just as buggy.
The entries in the HUD are definitely hierarchical, so I don't see a good reason why there can't be a way to browse through them "the old fashioned way". I wonder if the autocomplete suggests submenus, or just terminal entries?
I also hope this provides a nice, general way to introduce sciptability into applications, and that actions will be able to take arguments in the future. Or is that going too far?
Drilling down to see leaves and then drilling back up to the root to see the next branch sounds tedious...unless I can do it the same exact way that it can be done now with a mouse and a normal menu (i.e. without clicking, just hovering).
However, "hover" isn't a touch thing, so I bet that Ubuntu will make that functionality a 2nd class citizen or just cut it out altogether in favor of more a more tedious "touch oriented" (read: clicky) drill-down behavior. Which will suck (IMO).
Aren't drop-down menus technically the same as "drill-down" in terms of number of clicks? As long as you can use "breadcrumbs" that allow you to quickly access the hierarchy of menu items, it shouldn't require any additional clicks to get to the option you want.
Menus, shortcuts, and command search each have their place.
One of the goals should be reducing the frequency of keyboard <-> mouse switches. If I'm using Paint, it would be annoying to type to search for commands; it would be the only time I had to let go of the mouse. It works the other way, too, and such "keyboard-centric" applications will benefit from a fast and easy command search.
And no matter what, as many commands as possible should have a keyboard shortcut, which should be listed next to the command when you search for it (this doesn't look to be the case). When we already know which command we want, we don't need to search for it.
I understand the need to force a shift to new/better features, but that doesn't mean removing features for existing and continuing use cases.
An interesting thing is that Unity is also trying to be a tablet-friendly interface. Using the keyboard on a tablet is rather cumbersome. HUD looks like a partly desktop-optimized, partly tablet-optimized interface that sits awkwardly in-between.
I'm curious why Canonical thinks it's a good idea to train users to rely on the keyboard to find things. (Ever tried to find a program in Dash?) Despite the rise of the "search" paradigm, keyboard shortcuts, and typing in general, have always been the domain of experienced users and programmers. Ordinary users tend to rely much more on the mouse; they type only when absolutely necessary. In fact, unless the new interface gives them plenty of hints, they'll probably no idea what to type. Wasn't Ubuntu trying to make things easier for ordinary users, even at the expense of power users? Or does the benefit outweigh the potential disadvantages in this case?
People still need to figure out what to say, or what gesture to make. Without a traditional menu or toolbar to advertise what functionalities are available, how would they do this? A video tutorial?
"Instead of hunting through drop-down menus to find application commands, Ubuntu’s Head-Up Display lets users type what they want to do into a search box."
Do I detect a touch of Jef Raskin's idea of typeable commands here as well? I'll have to re-vist his The Humane Interface
Appears to work well. I think it might be adaptive to some extent in the same way that the Dash is for program names. For instance, typing 'new window' at first produced a list of odd commands, but then after several invocations, the File -> New Window option was listed first.
Trivial example obviously. The activation key is 'alt' at present and appears to be hard wired.
I got news for you ubuntu, CLIs have been doing that since ever. I wonder how people decide to do things like these: the purpose of a GUI is to do the work faster. Did anyone ever try to measure how much longer it takes to perform something by typing it instead of searching through menus? CLIs make sense when you have thousands of commands available, but a typical application has less than 50 commands available and it makes perfect sense to have them in menus (BTW it's the same reason why restaurants have menus and google doesn't).
How about an alternative: Leave the menus as is, and introduce a global keyboard shortcut that searches menus, a per-application Alt-F2
Wouldn't happen. Abandoning user choice and configurability seems to be in vogue with designers these days. We're just slouching our way toward our future as passive appliance users.
(I totally agree - either turn it into a keyboard shortcut, or a reserved 16x16px spyglass icon in the upper right hand corner of the menu bar...)
I haven't tried this myself but it definitely sounds like a great idea. Very similar to the purposes of Quicksilver, Alfred, or Launchy. Only instead of searching for applications, you're searching for functions within an application.
Yerk. I hate these things instead of the drop down menu because
a) often the way I discover about the other programs/things that are similar is the fact that they also appear in the same drop down menu.
b) memory. Often the name of the item is not something I recall, but I remember the shape/color of the icon, or the association with the location in the menu
c) namefail. These things (at least how it works in Ubuntu 11) suck at finding the actual program. Some programs have multiple names by which they are known and they don't show up when you type the more common one. Google Earth is a good example. Or some - just don't show up at all for some reason.
Allowing searching of context menus is a great idea, hopefully this extends to all parts of the UI and will work with Java applications as well (I'm always getting lost in the eclipse settings menus).
Removing context menus altogether though?
Navigating around the application using ALT + <Key> is much quicker than bringing up a search and typing a full word in and then navigating to the second or third option down.
The only other alternative would be to add keyboard shortcuts to absolutely every feature in every application.
This sounds a lot like the 'Help' menu in OS X 10.5+, one of the best "details" of Mac OS ever. I apply radial blurs in Photoshop exactly that way. Click 'Help', type "radi", enter.
Also great to find your way around after an upgrade to Xcode 4. I even used it in TextMate until I found out about cmd+ctrl+T. Only Eclipse had (has?) broke it, of course...
//"Instead of hunting through drop-down menus to find application commands, Ubuntu’s Head-Up Display lets users type what they want to do into a search box."//
One of the reason why I loved Launchy[1] so much. That little program drastically reduced the need to use the mouse and launch/find any application with just a few keystrokes.
Even, Ubuntu 11 has similar functionality with Unity. But,it's searching capability is little disappointing, though.
Random question -- does any operating system or application, having noticed you did something the hard way, say, "hey, next time, hit Ctrl-% when you want to do that?"
Both Windows and OS X have conventions in place to help with discoverability.
Windows menus items have certain letters underlined, and you can hit Alt+underlined letter to open a menu, then Alt+letter to select an item or submenu. It provides both discoverability and keyboard-based navigation.
OS X places hotkeys at the far right of every menu item which has a hotkey equivalent.
sure, discoverability. I guess what I want as a user is for Excel to tell me, "you're formatting a lot of cells the same, have you heard about format painter?" ... though as Clippy that was a little obnoxious.
That would be great. Do you know any other apps (other than emacs, that is) that provide a similar sort of discoverability? And on the similar note, is there a way to make emacs's tips be even more prominent?
I always wished the kind of mouse+command line interface found in AutoCAD existed for more applications. This seems like an nice step in that direction.
This looks like a cool idea, but a search-centric menu system doesn't allow for "discovery" of the item you might be looking for. Sometimes at the end of a long day I might be burnt out and not have in my head exactly what the item I need is called, but my fingers remember how to get to it. This system kind of makes that scenario a bit more difficult.
I'm not in love with the design, or how big and out of place it feels just appearing in the top left corner, but it's a great start and I hope they keep pushing it forward.
I hope developers of Alfred for OS X look at this and try to apply some of those ideas going forward. App-specific, contextual Alfred would be great.
Ubuntu 10.04LTS has gnome 2, it also had gnome-do which was awesome. Ubuntu 12.04 is going to have unity/blurify or whatever -- this is a gigantic change and what prompted me to switch back to windows 7 on my laptop. This is too much change too fast especially when Ubuntu is targeting people from windows that are accustomed to windows xp/7.
I would argue it's not moving fast enough. We are in the middle of a very fast-paced transition in human-computer interaction. New form-factors like tablets are being adopted rapidly (nearly doubling over this holiday season alone). A speech-enabled HUD could become the killer app of hand-held devices. But it's still not on the market, and Canonical still do not have a way to install Ubuntu on tablets. E.g. They have to move even faster!
If you think that the pace of technological change is too fast, or if you think that the music is too loud and those young hooligans should get off your lawn... then please stay on XP; but don't hold back the rest o us who will move forward without you. I look forward to your similar rant against Windows 8 with it's hand-held interface design.
OK, I think I might have worded things a bit awkward there. Actually I agree with you completely in that technology is not moving fast enough. Having a speech enabled android tablet/phone could actually compete with siri and would be very, very cool.
The point that I disagree on is that Mark Shuttleworth & CO are releasing software every 6 months that in many cases (myself included) breaks comparability with hardware. This among other problems has IMO caused Ubuntu to fall to #2 on distrowatch, while Linux Mint which includes MATE and a much more customizable gnome 3 has risen to the top. If they can really make it against apple then more power to ‘em.
(yes I know Ubuntu does not include gnome 3 by default but both gnome 3 and unity depart from the traditional win95 style desktop)
> Shuttleworth: "It will be interesting to see how users react to the changes."
Please... this is an LTS release and your users aren't guinea pigs. I would hate to see another potentially promising feature get bad-mouthed all over the place due to premature release. Something like this needs months of usability testing. Couldn't they just wait until 12.10?