Slashdot Mirror
Mozilla Labs' "Ubiquity" Helps Automate Web Interactions
Martin writes "Mozilla Labs have released a prototype version of the Firefox add-on Ubiquity. It is basically Launchy (the application launcher) for Firefox with the difference that Ubiquity makes use of web APIs and the Firefox browser. The official website contains examples, a command list, information about creating your own commands and of course the Ubiquity extension that is compatible with Firefox 3.x. Ubiquity can pull and send data to various services like Twitter, display, find and embed Google Maps, perform searches, write emails, add entries to the calendar, digg stories and more."
I thought I'd heard this name before.
This is very handy - especially since it's much easier to code up a Ubiquity command than a ful fledged Firefox plugin. And the fact that it's interactive differentiates it from Greasemonkey.
when the CEO accidentally twitters the list of layoffs thanks to a hotkey.
Good people go to bed earlier.
Some of the examples seem nice, but I'm not quite convinced. How is this substantially different from the various site-specific Firefox extensions, like the kind Flock uses to help you integrate Flikr photos with your blog?
I'm the sort that is always conflicted about whether I really want my browser to be a web-application platform or I'd rather keep it as a plain document viewer. The latter seems safer and more efficient for a lot of things, but here I am posting on Slashdot, and webforms already make it more than a passive viewing application. But anyway this sort of thing exacerbates the tension for me because I can't quite figure out what new direction the devs are pushing the browser towards.
Don't we hit a point where we take a step back and ask, "What are we really trying to do here?" and then build a system for that purpose? If we want to standardize web application interaction, then it makes me want to ask: Should we really be trying to rebuild the browser to use the backwards hacks that people are currently using to make web applications, or do we want to build a new web application framework and a new sort of web-application platform built for that purpose? Must we squeeze everything into the web browser?
But I might just have a mental block on what they're trying to do. And besides, they're only claiming to have made an experimental prototype/tech-demo, so I guess there's no point in getting into a huff.
Now, someone tell me that I don't understand what the Internet is.
Been playing with it for a little while now. So far the commands are very natural to what you'd think they are. Google Maps is "map", Gmail is "email", in-line translation is "translate {selected text} from {language} to {language} (by far my favorite feature so far). And all you have to do is start typing for it to suggest commands it has. Makes it very easy to learn what it can do. If the "trusted network" of commands gets going like they plan, new commands are as easy to get as visiting a website and installing like a plugin after reviewing whether it's one you like & trust. Once this gets a feature to let me use Thunderbird to email, I'll like it even more!
This is a classic case of "because we can build it"-based design instead of "what problems can we solve for users"-based design.
Definitely disagree with you. I only installed it today and its immediately become part of my workflow. Its best to think of it as a way of pulling information into a page that wasn't there to start with as opposed to a 'web interaction automator' or the 'net command line' some sites have labeled it as. For example it provides translation directly onto a page without having to run it through a new translator - so it all feels like functionality that should have been there to start with - rather than some nifty toy. They've actually thought it through based on existing products. For example quicksilver/gnome-do style things have really taken off with a + combo - so a + combo feels very natural. And because it allows you to use language like 'this' it makes sense.
It's working fine for me on Fedora 9 x86_64.
Firefox has a security framework in place which is designed to prevent web pages from being able to manipulate the browser chrome (aka javascript code, UI, etc). So on the firefox level, pages can't access any add-on code to begin with. Up until recently pages could reference scripts or other chrome documents as urls but I believe this has been fixed in Firefox 3. The only possible exploits now would be if ubiquity explicitly registered javascript commands for any web pages to use to interact with ubiquity, and I don't believe there are any (actually ubiquity works exactly the opposite way, the user calls up ubiquity to interact with web page contents, not the other way around).
My understanding of the behind the scenes stuff in Firefox is rudimentary at best, so don't take my word for it. Mozilla has tons of documentation on their site.