Mozilla Ubiquity: a ridiculously useful Firefox extension
vimeo.com
vimeo.com
It's like calling a unix-shell "user-friendly" because with all commands, and pipes, and possibilities to combine them you can do everything. It's possible, sure, but who really can, besides like 1-2% of computer users ?
I get the same feeling from this thing. It's supposed to make you feel like you only ask your computer for something and it comes naturally, but basically, it's only typing a command to make an action. And the main flaw of it, is that words that are obvious to one person, are not to another.
And last point, I know, it's still alpha software, but not everyone does everything with their keyboard. I do, i'm quite a big fan of utilities like Launchy, for example, but most of people prefer to use a mouse for their actions, they want a flow of action, they want drag and drop.
Basically, this ubiquity, it's just a unix command line adapted to a browser, but i can't see that becoming very useful to most people.
Given that, I do find ubiquity much more user-friendly and useful than commands in the terminal, for the tasks it was designed to use. For example, you can select a whole page, just alt-space, write 'translate to chinese' and it substitutes the text in place, fast. In your email, you can select an address, write 'map' and insert it in the email almost instantly. You can save many seconds and mindshare with this tool.
The question is who is the 'user' that it's friendly to? The power-user who uses an application every day where the initial learning curve will consist of a relatively small amount of time compared to the speed and frequency of doing tasks, or the new user who is likely to do something only once and as such will never get past any 'learning curve' and only the initial understanding matters?
Is it "flawed" to intentionally develop something to focus on the prior but not the latter? Is it a fair trade-off to deliberately increase the learning curve for long-term flexibility and power?
If the Unix terminal isn't to some degree "user-friendly" why is it rediscovered by successive generations who notice its speed, power and flexibility over the alternative GUI interfaces? When given a /free choice/, why does a certain subset of users /choose/ the terminal over the GUI interface?
In my experience users hate to drag and drop. And they never drag and drop, with an exception of very few Apple old-timers, because Apple GUIs historically have been using drag&drop more heavily, as opposed to Windows users who are more conditioned to right-click on everything.
Drag&drop never works in user interfaces because 99% objects in everyday software are not draggable and users are not conditioned to even try. Buttons plus menu is what people are used to.
P.S. This opinion comes from reading hundreds of support emails and replying "have you tried dragging it?" over and over and over again.
But better than that, you could drop it on another application. Consequently, you could create and edit a pixmap, and drop it into a vector drawing program where it would become an embedded object. Want to edit it again? Drag it from there back to the pixmap editing program's icon on the icon bar. Neither of these touched the disc; it was in memory transfers. And the program code didn't need to know the difference between saving to another app., or saving to disc through a filer window.
Other aspects of the desktop were also novel and worked well. It had a three button mouse. A proper one. No silly scroll wheel. The right button did what the left button did, but altered in some way. So you'd pop up a context sensitive menu with the middle button. Select an item with L and the menu would disappear. With R the menu would stay there. Great for when you want to do several menu items in a row, e.g. adjusting an object's attributes.
Scrollbars worked better. Firstly, the mouse cursor on the screen only moved in one dimension once a drag with L was started. None of this cancel the drag if you wander off orthogonally a bit. But if there were two scrollbars, dragging with R would control both; an instant `pan' widget.
Hold the `up' arrow with L and it would scroll up. Switch to R and it would scroll down. No need to move to the other end of the scroll bar. Same with `paging' by clicking either side of the thumb.
Drag a window by it's title bar with L and it'll come to the front of the stack at the same time. Use R and its depth is unaltered.
Double-click a folder icon in a filer window with L and a new window opens with its contents. Use R, the current window switches to show that directory. Close a filer window with R and it becomes the parent folder.
Note, you didn't need to know all these uses of R to use the system. You could manage with L. But the paper User Guide it was shipped with explained it and you soon got used to the productivity gains.
This was back in the 1980s and 1990s. Today, you can find remnants of it in the ROX (RISC OS on X) Desktop. http://roscidus.com/desktop/
Acorn did some smart stuff. Today, the main vestige is the ARM chip and its instruction set, designed by Sophie Wilson.
Since Google Maps and others are equivalent in functionality, with minor differences, this is not the best example. When, in the video, he added an event, to what calendar was this added? Google, a desktop program?... Because it'll not be easy to convince users to switch services just so they can save two or three keystrokes.
Like you said, besides having users learn a new language, Ubiquity would need to figure out (and correctly interpret) hundreds of possible combinations.
This will probably gain some traction with certain segments of the population, but it's far away from its promises.
This capacity is just one reason why a linguistic CLI, such as Ubiquity and the earlier Enso, has a usability edge over a conventional CLI.
The UI paradigms and metaphors we use today have been the same for nearly 20 years -- it's good to see people working at the edges.
I argue that the shell is great and very userfriendly. It has a few rules, which can be composed logically without too many gotchas, and if you cannot remember the name of a particulary feature then it is easy to press the tap key and get a hint.
I have come to hate how stuff is judged based on superficiallity (how soon can the user use this program) and not on substance (how much benefit will the user eventually derive from this program, even if it takes a week to learn to use it?)
It is the same problem with people who don't make the effort to learn to type on their keyboard without looking. Unless you are never going to use a computer, have the respect and decency to yourself and learn to use the tools you have at your disposal.
As ubiquity gets updates, the ubi scripts get out of step. The command to email a page to someone is pretty handy--if it worked most of the time.
Also, the algorithm to do real-time narrowing down of commands that you might mean gets slower and slower (seemingly exponentially) the more you type. After a while, I find it gets bogged down and unusable.
The only use I've had for it was to make it easier to twitter something, only because I don't have twitter clients installed.
That said, it's still early. I think the concept is good. And even better when you can have context specific commands for each web app that you visit. That way you don't need to download each ubi script as you want them. They dynamically load and unload with the web application.
http://blog.wundrbar.com/2008/08/wundrbar-vs-ubiquity-our-th...
http://www.youtube.com/watch?v=I1llZnsye0M
http://eprints.ecs.soton.ac.uk/16861/1/uist08-inky-preprint....
Glad people finally saw it - the submitter was smart to point out it's a FF extension in the title.
On the other hand, Google's Quick Search Box (http://code.google.com/p/qsb-mac/) is looking a lot like Ubiquity without the browser!
In about a month, Ubiquity will be the Linux, and I'll be the Windows.