Greasemonkey in the Enterprise: When is GM the Right Tool for IT?
Peter Laird's Blog |
August 17, 2007 11:00 PM
|
Comments (4)
As I have covered in previous blogs, Greasemonkey is a powerful client-side tool for augmenting web sites or creating mashups.
It consists of a Firefox plugin coupled with scripts that are written and installed to modify web pages as they return from a web server.
Greasemonkey generally is a tool for techies who want to tweak their favorite sites around the web.
But does Greasemonkey have a place in the toolbox of IT departments in the enterprise?
My next few blog entries will work towards an answer to that question.
In this installment I will introduce a framework for measuring whether Greasemonkey is a good solution for a specific enterprise project.
This is part 3 of a series of blog entries on Greasemonkey mashups.
Quick Aside: my last posting was over a month ago - my blogging was interrupted by an extended paternity leave.
I had intended to continue blogging through the time off, but that proved to be an unrealistic goal.
Any downtime was sleep time - if you are a parent you know what I am talking about!
If you are new to Greasemonkey, I would recommend navigating backwards to see the first two posts.
An Enterprise Use Case for Greasemonkey
You probably did not learn about Greasemonkey (GM) in a Computer Science class at University.
When drawing up an ideal solution for delivering a web application, Greasemonkey is probably no where in sight.
The truth is Greasemonkey is a pragmatic solution for real world problems when other options aren't available.
It is not the cleanest solution, but it makes up for that by being effective.
It will always have detractors who will dismiss it as a hack, and an evil one at that.
While its shortcomings cannot be denied, it is a mistake to dismiss it.
Greasemonkey has the potential of fast tracking IT projects that would otherwise never get implemented.
It can also lower the bar for IT skill sets - a junior scripter can use it to modify the most complex of web applications.
I feel that Greasemonkey deserves a place in your IT toolbox, and should be an option when it is an appropriate solution.
But I will be the first to say that Greasemonkey is not for everyone, and is not for every project.
Greasemonkey definately has a sweet spot.
Outside of that sweet spot, you are best off looking at another solution like other mashup tools or custom development.
For a quick example of good GM use case, imagine a web application in the enterprise with these characteristics:
- It is a closed source packaged application, purchased and installed from an external vendor by IT.
- It is used by a modest sized group of users, all of which are comfortable with computers and web browsing
- There are a couple of missing features that dramatically hurt productivity
- Those features can be easily woven into the application using a Greasemonkey script
This web application would make a good candidate for augmentation with Greasemonkey.
A GM script could be quickly created that would add the missing features without needing to acquire the source code for the application.
The deployment of the script would be relatively simple - the user population is modest in size and are technically competent.
IT could be a hero by providing a quick solution to an expensive problem.
But what makes this use case a good fit for Greasemonkey?
What other applications are good candidates for a Greasemonkey mashup/augmentation?
What guidelines should you use when deciding if Greasemonkey is right for a given project?
This blog will answer these questions.
Greasemonkey Selection Framework
This section provides a framework for evaluating whether Greasemonkey is a good fit for an enterprise project.
Like any software selection process, you must consider many factors before choosing a best fit solution.
You cannot base your decision on a single factor; you must sum the overall suitability against the project requirements.
The list below enumerates a number of factors to look at before making your choice.
For each factor, I explain when Greasemonkey is best suited.
 Factor: Do you have access to the source code of the web application?
Description: IT brings in many packaged applications from external vendors.
In such cases, IT may not have access to any source code, or only a partial set (like the HTML files).
For applications home grown within IT, this is not an issue as the source code is available.
Greasemonkey Fit: When the source code is available, it may be easier to just update the original application.
Greasemonkey is indicated more when the source code is unavailable.
Factor: The application is home grown and the source code is available. But updating the application is very risky?
Description: Even if the source code for an application is available, it may not be cost effective to
update the application directly. Perhaps all of the original developers are gone, and there is little documentation
on how the site was built. Or perhaps the current staff is
unfamiliar with the technology that was used to implement the site. If the code base is complex, it may be
risky to make any modification to the source code.
Greasemonkey Fit: Greasemonkey can be a safer solution for adding new features to web applications
that are risky to touch. The Greasemonkey script is externalized from the web application, and so the new development
is clearly separated from the legacy application.
Factor: How critical is the feature to be added?
Description: Is the feature a productivity enhancement, or is the application as-is no longer valid without the update?
An example of the latter would be a feature related to a compliance project. In order for the legacy application to update company
financial data, a new "explanation" field needs to be added to a web form for auditing purposes. Users must not submit this form
without the added field.
Greasemonkey Fit: It would be difficult to enforce that a user have the Greasemonkey installed and up to date (although the
last blog entry in this series will offer a possible solution for this). Therefore, if an application is not valid without the
new feature, Greasemonkey may not be the right solution for implementing that feature. For optional features such as productivity
enhancements, Greasemonkey is a great solution.
Factor: Is Firefox certified for use in the enterprise, and does it work with the target application?
Description: This factor is obvious, but be careful not to miss this in your software selection.
Greasemonkey requires Firefox (there have been attempts to port to IE
(gm4ie, GreasemonkIE),
but are they complete/solid?).
Also, some web applications may not work correctly with Firefox.
Greasemonkey Fit: If your enterprise does not support users on Firefox, Greasemonkey is not an available solution.
Also, if the target web application does not work well with Firefox, Greasemonkey is not a great fit for the project.
Factor: To what degree are the target users computer literate?
Description: Within the enterprise, there is a broad range of computers skills amongst the employees.
Greasemonkey does require users to be able to follow directions on installing Firefox, the Greasemonkey plugin and
the required scripts.
Greasemonkey Fit: The more computer literate the user base, the better for Greasemonkey. While installing plugins
and scripts seems like a no-brainer for anyone that would be reading this blog, it is a true obstacle for many within
the enterprise.
Factor: What size is the user population that needs the new feature?
Description: The appeal of web applications is in their ease of deployment. IT need only
manage the application on a few server machines in the data center. Updates are efficiently deployed. Client side solutions
are generally more expensive to deploy, as each client needs to be updated with each new version.
Greasemonkey Fit: The cost of deploying a Greasemonkey script to a small user population is likely
modest. On the other hand, deploying a new version of a Greasemonkey script to a huge user population is
an expensive proposition, particularly when computer literacy is an issue (see above).
Greasemonkey is best when the user population is small.
Factor: Is the application exposed to the public internet?
Description: Many enterprise applications are available to a closed audience of employees and partners.
But some applications are also exposed out to customers and the general public on the internet.
Greasemonkey Fit: Because Greasemonkey requires Firefox, the GM plugin, and the proper user scripts installed,
Greasemonkey is a good solution when the user base is well known and constrained. Otherwise support costs and
customer complaints will be high ("Hello, Avitek Industries, how may I help you?"; "Your website says I need Firefox. What is a Firefox?").
Factor: How often is the page structure in the web application changing?
Description: Regardless of who is changing the web application (IT, or the ISV if it is a packaged application),
every update has the potential of breaking existing Greasemonkey scripts. Minor changes to the content will
probably be safe, but bigger changes to the page templates will almost certainly cause problems.
Greasemonkey Fit: Greasemonkey works best if the structure of the pages within the target web application is not changing substantially.
Factor: Does the application manage or expose sensitive information?
Description: Some enterprise web applications are low security risks. The site that hosts
a monthly employee newsletter probably is not much of a concern from a security point of view.
A payroll system is quite the opposite; the consequence of a security breach is severe.
Greasemonkey Fit: My next blog entry in this series will discuss the Greasemonkey security
model and why it is not a great fit for the enterprise. Based on that analysis, Greasemonkey
is not a good choice for adding features to highly sensitive enterprise web applications.
Further, some IT Managers may feel GM is too risky to allow at all. More to come in the next post...
Factor: Does the new feature require many changes to the existing web application?
Description: Javascript can update the DOM of an HTML page quite easily. But for each
update on a page, there is code involved. Writing raw HTML (in an .html file, a JSP/ASP file, etc)
is far easier than a similar effort in JavaScript code.
Greasemonkey Fit: Greasemonkey is a great fit for features that can be implemented with a few
snips to the target HTML. As the number of distinct changes to a page increases, the suitability of
Greasemonkey decreases.
Factor: Does the target web application already have JavaScript code that mutates the page?
Description: The web application may have JavaScript code that modifies the page structure.
This may be in support of Ajax capabilities, or just the way the initial page load was implemented.
A Greasemonkey script runs before any page defined JavaScript runs. This may or may not be
a good thing.
Greasemonkey Fit: Implementing a feature with Greasemonkey may be difficult if the page is
already mutating itself with JavaScript.
Factor: Does the feature require communication with a server in a different network domain than the web application?
Description: Browser based programmatic requests initiated from JavaScript (XmlHttpRequests) are restricted in their
reach - they must not cross a network domain (e.g. bea.com). This is browser security, and this is generally good. But if you
are adding a mashup feature to the web application, this would normally prevent the feature from being implemented in
the browser. However, Greasemonkey scripts are not subject to this limitation, and can issue an XmlHttpRequest
to any network domain.
Greasemonkey Fit: Greasemonkey is a good fit when you wish to implement the feature in the browser but
need to connect to a different network domain.
Alternatives:
This section lists a few alternatives to consider when looking at a mashup or augmentation project.
Two of the three are BEA products; is it any surprise that BEA is my employer? ;)
BEA WebLogic Portal
Disclosure: I am an engineer on this product.
WebLogic Portal is well entrenched in the enterprise and offers a feature called Portlet Publishing (aka Adrenaline) that can be a solution for these projects.
This feature allows IT developers to create new application widgets (calendar, travel planner, etc) using Java portlet technology.
These widgets can then be injected into any web application in the enterprise with a simple change to the page HTML.
For more information, consult my Using Adrenaline Portlets to Energize Web Applications article that describes the feature and how to use it.
BEA AquaLogic Ensemble
BEA offers another approach to mashups and augmentations with a product named Ensemble.
BEA AquaLogic Ensemble is a reverse proxy server that has the ability to dynamically inject widgets into web applications by inserting special tags into the application's HTML.
It also offers security features such as authentication and authorization.
Monkeygrease
Monkeygrease is a companion project to Greasemonkey that takes an opposite approach.
Instead of making HTML modifications in the browser like Greasemonkey, Monkeygrease uses a Java servlet filter to do this work on the server side.
Like Greasemonkey, Monkeygrease enables a developer to write JavaScript to change the HTML page before it is passed back to the browser.
The web application must be a Java web application deployed on Tomcat, WebLogic, etc.
Favorable Enterprise Greasemonkey References
To see how others have used Greasemonkey on enterprise projects, or for opinions on how Greasemonkey can add value to the Enterprise, consult these links:
Greasemonkey Improves Productivity -
this company uses Greasemonkey to speed up enterprise form entry
Enterprise Greasemonkey is Inevitable - "...sooner rather than later we're going to see GM within the enterprise - if only b/c they have the potential to take some of the load off of beleaguered, shortstaffed IT staffs."
Firefox in the Enterprise Working Group - focuses on a larger issue than just Greasemonkey, but this expert group is looking at some of the issues noted above.
Using Greasemonkey to Enhance Auditing -
this script adds time logging capabilities to JIRA.
Anti Enterprise Greasemonkey References
And the opposing view. There are those who think IT should stay well away from Greasemonkey:
Greasemonkey Primes Firefox For Embarrassment
- this is an article you have to pay good money to read. Here is an excerpt from the abstract: "But IT managers beware: Greasemonkey will cause you nothing but headaches..."
[Greasemonkey] is Evil - "What's evil is the idea you mention that we'll end up making sophisticated infrastructure like automated script updaters in an attempt to turn a quick-and-dirty hack into a robust solution."
The Story Continues...
My next blog entry will discuss the Greasemonkey security model, and why IT will see it as "inverted" from what you would want.
Technorati tags:
Greasemonkey
Enterprise
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Eric - great questions.
1. What do you see in terms of adoption of Firefox in the enterprise generally?
At BEA we develop application infrastructure software products for the enterprise. Our customers have driven us to certify BEA products primarily on Internet Explorer and Firefox. This indicates that Firefox usage is widespread in the enterprise.
A second indicator comes from a public demo server I host for BEA. I assume that visitors to the site are current or potential BEA customers and are therefore enterprise employees. Web statistics captured from over 6,000 recent users of the site show that BEA customers use Internet Explorer 53% and Firefox 45% of the time. While it is a very small sample size, it does illustrate the trend.
2. Can you provide any specific usages of Firefox within BEA?
BEA has adopted a third party software product as our mission critical product management tool. It employs a user interface technology called XUL, which is supported by Mozilla derived browsers such as Firefox and not Internet Explorer. I believe most users use Firefox. Therefore, the productivity of the product development team at BEA is dependent on Firefox.
3. Is there any evidence that web developers prefer Firefox over IE when building enterprise web applications?
I cannot provide any hard evidence, but it is my impression that Firebug has become the most popular browser based developer tool. It can provide assistance with debugging JavaScript code and web page network traffic among other things. Although Firebug has some support on other browsers, it is primarily a Firefox extension. This would indicate that Firefox is the most popular browser for web developers.
Hope this helps - PJL
Posted by: plaird on January 6, 2008 at 9:55 PM
-
Peter,
Your posting above piqued my curiousity. I am looking into Firefox usage in the enterprise, can you provide any insight into the following:
1. What do you see in terms of adoption of Firefox in the enterprise generally?
2. Can you provide any specific usages of Firefox within BEA?
3. Is there any evidence that web developers prefer Firefox over IE when building enterprise web applications?
Thanks!
Eric
Posted by: ericlaicw on January 6, 2008 at 9:28 PM
-
I am a senior consultant and Greasemonkey user. Thanks for this interesting read. Just one note from my own experience.
iMacros for Firefox is another good tool for fast tracking IT projects that deal with website automation, sso or mashups. It is a web browser macro recorder for IE and Firefox. You can automate websites literally in minutes, similar to using VBA in Access or Excel.
Posted by: MikeSchreiner on September 3, 2007 at 8:05 AM
-
Johannes la Poutré blogged his thoughts on this Greasemonkey blog series on his blog. Thanks Johannes! Johannes is active in the Greasemonkey community, check out his GM work here.
Also, there are comments about this blog entry being filed on the Greasemonkey mailing list, which is hosted here on Google Groups.
Posted by: plaird on August 20, 2007 at 9:27 AM
|
