On Browser Extensions
Saturday, June 24th 2006 | Ismael Ghalimi
One of the rules for Office 2.0 is that applications should not require browser extensions or plugins. Nevertheless, some much-needed features, such as delegated opening of email attachments, cannot be supported without them. This raises the question of how such extensions should be developed in order to work seamlessly across web browsers.
Currently, bookmarklets implemented in JavaScript are portable across the most popular web browsers, which is one of the reasons why they became so popular, so fast. Nevertheless, their capabilities are limited, and they cannot support the full range of applications that require browser extensions today.
Having a standard way to create browser extensions would not only ensure browser portability, it would also support user mobility. Indeed, one can easily imagine a scenario where a user would register a set of standard browser extensions on some online service and download them to a new web browser, much like bookmarks can be imported today.
For such a standard to emerge, it must rely on existing technologies that are supported by web browsers today. JavaScript is a good candidate for this. From an architecture standpoint, one could adopt the model used by Greasemonkey for Mozilla, and implement browser extensions as user scripts. Even though it would not allow any kind of plugin to be developed this way, it seems to me that the functional scope would be enough to address most user requirements.
Until Internet Explorer, Opera and Safari support the same standard, some migration path will have to be devised. One approach could consist in developing a generic plugin for each browser that would allow them to support Greasemonkey user scripts. This approach would require end users to install the plugin on each web browser they have access to, but it is technically feasible.
That being said, browser extensions might very well create more problems than they solve, which is the reason why the original rules for Office 2.0 made them a show stopper. Delegated opening of email attachments is a good use case in favor of such extensions, but it might very well be the exception that confirms the rule. I will be looking for similar use cases moving forward though. In the meantime, many thanks to Enrico for having suggested the need for standard browser extensions.
Entry filed under: Office 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ismael,
I don’t claim to be an expert on this in any way, but I think I have a potential solution to the problem. I had to put it on my blog as it is rather lengthy being written a little late at night. Here it is.
In summary, it uses a third-party service as a registry for online Office 2.0 applications, enabling the Client Applications (email or whatever) to write to a single interface to interact with any possible user-preferred Editor Application (e.g. word processors, spreadsheets, etc. from different vendors).
I think it is compelling for both the Client Applications and Editor Applications, as well as for the provider of the Online Application Registry. I’d be interested in your thoughts and comments on it.
It is not going to be technically perfect at this stage, but I hope it is useful to at least spur some really smart people to come up with a good answer to the problem!
Cheers
-Phil
Ismael,
Let me start with a little narrative titled “Monkeying with Greasemonkey”.
A few months ago I’ve decided to contribute to our Web community by programming a Web 2.0 initiative — a tool that will ease reading web pages and search results by utilizing one of the foundations for Web 2.0: the IT crowd.
A Public/Community Web Marker: The main idea was adding a feature to the web browser which will enable users to highlight what they think is worth highlighting for later personal use. In the background a centralized service will save, publish and integrate the highlighted content to produce a public heatmap Web page.
Without further ado, My experience with Mozilla’s DOM was a torment, this is why I believe Greasemonkey, with it’s limited functionaly, is nothing more than a code candy.
-Harel Gal a.k.a. Enrico
I use ten extensions and a couple of Greasemonkey scripts every day. They all streamline my work. I could live without them, but life is so much easier with them. Why would I want to give them up? What am I trading them for?
I love the tab preview extension. It uses SVG, a standard supported by Firefox but not IE. Do I stand in front of the line, or wait for all the major browsers to play catch up?
SessionSavers and LiveMarks are both features that the browser should do (and Firefox 2.0 will). They just prove these features are necessary, and are available today. Since they hook into the Firefox code base, standards alone won’t make them portable.
The only reason for Office 2.0 to not require extensions is to reach a wider user base. But shouldn’t users be able to pick the best tools that make their life better?
Assaf,
I agree. Standard Office 2.0 setups should work without extensions, but users should be free to complement them with whatever will make them more productive, be it browser extensions or traditional Office 1.0 suites that are required for some specific use cases.
Another thing I (sort of) liked is the GMail browser. It’s a standalone application that does one thing: GMail. It’s basically Safari that only opens to one site, and there’s a similar application for Campfire.
The good point, you get a window that’s dedicated to e-mail without any other distractions, which many people find useful. But you keep all the benefits of GMail. It doesn’t add any new dependencies or breaks anything, strictly nice to have. If only it worked with Firefox…
When it comes to traditional Office 1.0 suites, I’d like to see more nice-to-have options for things I really care for (like text, code), and use Office 2.0 for the rest (spreadsheets, presentations).
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment