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."

Familiar name

I thought I'd heard this name before. [ubuntu.com]

Re:Familiar name

they should change the name to Phoenix

Danger ?

So correct me if I am wrong, but could the Black hats write something that could hijack this? Suddenly I am seeing bogus emails going out to my credit card companies, etc..

Re:Danger ?

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 [mozilla.org] on their site.

Quicksilver for the browser

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.

Ubiquity XForms

Interesting choice of name, given that IBM recently announced Ubiquity XForms [google.com], a 100% AJAX implementation of XForms which lets web application authors to use markup to control DOJO and YUI and other libraries, and which runs in Firefox, IE, Safari, and Opera.

oh the fun

when the CEO accidentally twitters the list of layoffs thanks to a hotkey.

Re:

It will just be a few Adams, Allen and Anderson that will get upset, the rest would be outside the 140 character per tweet limit.

Re:the other twitter?

Really, I'm getting a bit tired of the comments on the 140-character limit that Twitter imposes. The idea behind the limit is something tha

Linux support very third rate at present

(2)Those of Linux/Firefox + ubiguity with less/no money who don't pay the browser/OS/soc network but still have their online life lived for them, so they can live in the real world

First we need decent support for Linux in Ubiquity, which doesn't seem to be immediately forthcoming. They can't seem to decide on a toolkit to use for their transparent popup window a la Mac and Windows, so those of us using a free system are, for the time being, without many of Ubiquity's features. Since I'm not going to chang

Not sure what to think...

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.

Re:

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

Why not have both? Provide a simple interface by default and add optional features which people can turn on if they want them.

I think choice is a good thing and there is no single interface which appeals to everyone.

I would use this new interface, because it appeals to me. You wouldn't. Where's the conflict?

Re:Not sure what to think...

My own view on this would be that a browser should help me in trying to reach/dispense 'information' with the least steps possible.

I just wonder sometimes why everything needs to be done in the browser.

It reminds me of one of their other experiments, Snowl [mozilla.com]. We used to have the newsgroups using its own protocol and application, and then that got replaced with forum web applications. Then that forum and weblog software started adding support for RSS so you could grab the feed and dispense with the defined UI. So then with Snowl it seems like they're essentially allowing you to treat the feeds like threads and reply directly-- and it suddenly made me wonder whether we're essentially returning full-circle to newsgroups, but using different protocols.

I don't have any real objections to the development, but there's been this general push to put everything into web applications, including e-mail, chat, discussion, and office applications. But then it seems like some of these browser experiments and extensions are being created specifically because we don't want to deal with websites. And that makes a certain amount of sense to me, because I'm the sort of user that much prefers to use a local IMAP client than webmail, and prefers to use a RSS reader separate from my browser, but the whole progression just seems a little weird and unplanned.

I'm half expecting people to declare IMAP to be obsolete in a new age of webmail, and then turn around in 5 years and build a complete e-mail client extension into the browser using XML to pass e-mail around, but no HTML for the interface. To me, the whole web application took a funny turn when I realized that Google Reader also published RSS, thereby allowing you to view their web-app RSS reader in a client-end RSS reader application.

It all make me wondering whether we might want to aim for a future without websites. Maybe not the complete end, but here's what I'm really starting to wonder: when I want to check the Wikipedia 10 years from now, will I be opening a web browser and typing "http://wikipedia.org"? Will the Wikipedia even bother to offer an HTML version? Or will they just have some database of articles with a pre-set API, and I'll be able to query the database for information from any number of applications, depending on the platform I'm using and the purpose of my query.

And then if that's the case, someone will have to develop a generalized viewer for these queries which would follow certain display specifications, and you'll end up with the reinvention of the web browser.

Blah. Sorry, I know this is kind of an aimless rant. But these Mozilla experiments do funny things to my head.

ZOMG FF3 KILLER CLI

This entire article reads as if the new FF extension at least solves world hunger and maybe even provides world peace. It's a command line interface that pops up in some black dialog box, where you can type commands instead of pointing and clicking with a mouse. It's great, but users will have to learn those commands, won't they?

Re:ZOMG FF3 KILLER CLI

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!

Re:

It's great, but users will have to learn those commands, won't they?

They should be able to define their own name for a command which makes learning it much easier.

Bloat

Wasn't Firefox supposed to be the anti-bloat fork of SeaMonkey? Are we going to have another fork in another year that's the anti-bloat version of Firefox?

Re:

Are we going to have another fork in another year that's the anti-bloat version of Firefox?

I dub thee WaterWeasel.

Not user-centric

This is a classic case of "because we can build it"-based design instead of "what problems can we solve for users"-based design.

Re:Not user-centric

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.

Re:

welcome to open source where the number of contributors and not the number of users is a measure of success.

Re:

Looks more like a classic case of "let's slam the thing in question without even bothering to read the fine article" to me...

Re:

In the Tutorial: "

...On Linux, we don't have a good messaging system yet. If you have a suggestion for how Ubiquity can display messages on Linux (preferably in a way that will work on all major distros and window managers), please tell us about it. "

Re:

As I was saying above, it's working fine for me on Fedora 9 x86_64.

I don't see the "enter key" problem the OP was referring to.

Re:No Linux....

It's working fine for me on Fedora 9 x86_64.