Sharing Streamable Functionality

Advertisement:

POWERED by FUSION

Question: How do people share on the net?

Answer: They use services like Del.icio.us, Facebook, and Twitter. They IM, Email, and RSS. They advertise, search engine optimize, and chain letter. But it all comes down to communicating URLs.

Now, that might seem to be a trivial conclusion. And it is—the URL is the unit of location for the Web. But as we began to think about how to share new functionality for the browser (read Ubiquity commands, as well as the broader spectrum of Firefox add-ons), we realized that the basic URL was again going to be the key to sharing.

Question: How is functionality shared now?

Answer: Via one-time software downloads. New versions of Firefox are downloads (albeit often transparent ones) and add-ons are available as static XPIs. There is something largely last-decade about requiring restarts to add a new feature to your browsing experience. It’s ironic that the entire Web is on a push model, yet the browser—the most fundamental tool of interacting with the Web—is on a pull model.

Functionality is not shared via URLs, but it should be. Security concerns aside (we are starting to think about them), it’s a corner-stone of streamable browser functionality.

Question: What should functionality look like?

Answer: Like the rest of the Web. The closer new browser functionality can be packaged to look like standard HTML and JS, the larger and more diverse a community will create it. XUL and the desktop paradigm for extension development, while powerful, has a high cost of adoption. Right now we have a short tail of browser functionality with thousands of add-ons. There should be millions. We can get to that long tail using a more web-like model for functionality development&tools that are accessible to hobbyists and tinkerers, but that scales to professionals.

Bookmarking Functionality

Given that functionality implementations should look webby (think microformats) and be sharable by sharing URLs, it makes some sense that to add a piece of functionality, you should just be able to bookmark it.

In Ubiquity, you can do just that. We still haven’t defined a Ubiquity microformat, so right now functionality is simply a Javascript file. To nab it’s functionality, you bookmark it and tag it “ubiquity”.

Immediately, your browser has new functionality. Streamable functionality.

Using bookmarking solves a lot of user experience problems for passing around functionality: It doesn’t introduce a yet another new thing to learn, it enables no-action syncing between computers with Weave, and it lets you bookmark RSS feeds for aggregating interested meta-sets of commands. It also makes semantic sense: You bookmark content that you find and like, so you should be able to bookmark functionality you find and like.

The bookmark method works in the current prototype (running it requires pulling it from the HG repository). If you build some commands/verbs and want to share them, it is as simple as just posting a file online. If you do, tell us about them on the wiki.

About this entry

You’re currently reading “Sharing Streamable Functionality,” an entry on Aza’s Thoughts

Published:: 7.23.08 / 4pm

Category:: Firefox, WEBLOG

Chris 7.23.08 / 5pm

I almost agree.

So … imagine if the browser chrome was a website, chrome.mozilla.org, that the browser was hardcoded to display. Then you could install extensions by re-setting your chrome to chrome.mozilla.org/extensions/1843;5579 (if you wanted Firebug and PicLens).

But changing chrome favourites is different to setting content favourites. It’s a different user experience, a separate category that is always restricted to the mozilla domain.

One more thing - extension developers would need a service hosted on chrome.mozilla.org, sorta like Force.com for Salesforce, but relying on web standards like HTML5, CSS, Javascript 2, etc. I really think hosting it is the only way to provide security.

MarkC 7.24.08 / 4am

“XUL and the desktop paradigm for extension development… has a high cost of adoption”.

Extension development and the desktop paradigm definitely have a high cost of adoption. XUL itself, on the other hand, has a very low cost of adoption for anyone already familiar with HTML. Indeed, in my experience, basic XUL is significantly easier than HTML simply because Gecko is the only target, so there’s no need to know about cross-browser issues, and it’s safe to use more modern functionality that is missing from some other browsers.

The problem is partly that _remote XUL_ doesn’t receive much love and attention. In theory it should provide a great way for an existing web developer to create something more application-like, quickly and easily, whilst leveraging their existing knowledge of XML, CSS, JS and so on.

In practice it has too many artificial restrictions, which mean that in many aspects remote XUL is even more locked down than a normal web page. To make matters worse, a lot of these limitations aren’t clearly documented.

Remote XUL could be a great option for bookmarkable extensionsn (and other uses), if only it were a slightly higher priority in Mozilla’s eyes.

James Heaver 7.25.08 / 5am

I’m not a dev, so I can’t comment completely.

But Songbird seem to be doing some interesting things with XUL in this regard, openign up their chrome to website etc.

Ian Bicking 7.30.08 / 1pm

A little like bookmarklets? I’ve always preferred bookmarklets to extensions, when both exist (and for quite a few extensions, bookmarklet form is workable). Like, a combination of Greasemonkey and bookmarklets…

Bookmarklets, being explicitly invoked, also have the (substantial) benefit that they can’t mess your system up. I’ve had bad experience with several extensions and Greasemonkey scripts, and the inability to really understand the problems is what leads to a general suspicion.

Brett Dalton 8.29.08 / 11pm

Bookmarking of extensions looks to be a great way of sharing them with the implications of upgrade detection etc. However there are a couple of points.

Code versioning is difficult short of having to replace bookmarks unless there is a dynamic mechinism for updating bookmarks given uses an option to upgrade or not (not difficult, add a CmdUtil function in the case of Ubiquity with the upgrade URL).

Security again can be simply handled by storing a local Hash of the script which will detect changes alerting the user. This will prevent malicious code changes going unnoticed.

So far I’m yet to see a down side except for bandwidth and load times which are becoming less and less an issue.

Guillaume Riflet 8.31.08 / 4pm

Hi,
I just wanted to congratulate you guys for the fantastic work you’ve been doing with the Ubiquity add-on for firefox.
For the last couple of years (ever since I learned how to store-and-sync all my bookmarks using del.icio.us) I’ve been harnessing “functional” bookmarklets that allowed me to do simple stuff, like twitter, translate pages, use the feeling lucky button, share stuff with several sharing devices etc…
However, I longed for some encapsulator that would allow me to centralize and document and share all these js shortcuts (something like yubnub.org, but with more functionality and more javascripting). And I really really think you did it! So thanks to all!! Looking forward to follow the Herd ;)
Cheers,

Guy Leech 10.22.08 / 6am

So, will this work in reverse? i.e. will my existing commands be magically translated into bookmarks?

As for the whole idea of using bookmarks, I agree with you - it seems to make a decent amount of sense. However, I do think that a microformat would be a much greater step froward, giving not only users easy / useful ways to access Ubiquity commands, but also giving developers chances to do what they like with them.

DX 12.6.09 / 10am

I think you’re mistaken.

People communicate URLs effectively because there’s a clear link between “things” and “places” that exists in the real world and is fairly easy to transpose.

What you’re proposing is far too subtle and mentally-intensive for the public to ever master. The idea that an average person will be able to atomically catalog individual software functions and manage them by location is totally ludicrous.

And the Web is not on a push model AT ALL. Some applications of HTTP might be considered “pseudo-push”, at most, but the whole request / response model is totally pull-based. So I’m not sure exactly why a browser requesting updates is ironic compared to anything else that happens.

Sharing Streamable Functionality

About this entry

9 Comments

Have your say

Previous

About me...

Projects