juice-project.org

Richard Wallis, Technology Evangelist, Talis

The Juice Project, like many such endeavours, has grown out of programmer laziness.

One facet of the Talis, Technology Evangelist, role is to demonstrate how easy it is to extend the web interface of our products with embedded functionally. With a few years experience in Ajax programming techniques and a moderate understanding of JavaScript, html, and CSS, none of this is exactly rocket science. Over recent months and years this has been made even easier with the aid of JavaScript Frameworks such as Prototype, Dojo, and JQuery. These take much of the hard work out of writing code that will work in several browsers, and easy repeatable ways of identifying components in an html page.

Despite all of that, adding ad-hoc mashup style integration of external services from sources such as Google Book Search, Amazon, and WorldCat, over several months becomes an inefficient task. Taking previously developed code, analysing it to refresh your memory on how you did what you did, re-factoring it to fit it to your new service, and finally debugging the inevitable conflicts with what you did before, is not the most enjoyable task. Adding to this the possibly of applying the result to more than one application brought me to the conclusion that I need a framework to take care of all this!

Elements of Juice

Analysing what I had been doing previously drew out the following elements that were common to the vast majority of extensions.

• Defining locations on a page - for both adding things for users to click on, or to sometimes display results.
• Identifying data displayed on the page to be used to pass to an extension - Author, Title, ISBN, location, etc.
• Creating and dynamically inserting an element in to the web page to contain either things to click on or, resultant data to display.
• Adding a debug area to the page to help get things working.
• Handling a call to a remote service that would optionally enable an extension.
• Dynamically changing the CSS attribute of [my] elements in a consistent way.
• Go to another page in a new browser, or iframe, or overlaid window.
• Other utilities such as loading new script files and delaying actions until they are fully loaded, or parsing ISBN strings to remove things like (pbk).

Encapsulation of these elements became the basis of a Juice framework. Experience of JQuery demonstrated it's usefulness and power in identifying elements of, and manipulating the shape of, a web page document. JQuery was then chosen as a Javascript framework to support the Juice extension framework.

The Juice Community

Building on the theme of laziness, and humility, it is clear that there are far more people, with far more ideas for extending these interfaces than just myself. So why not build a framework that could be used by many. By making the framework an open source project will enable a community to form around it so that the innovation can be shared far and wide.

Who will use Juice

There are three overlapping groups of web user interface managers/designers/developers who will use Juice.

• Application managers - comfortable with making simple html changes to their interface. Happy to copy and paste a few lines of code, or comment out some, that have been demonstrated as working by their peers who also manage the same type of application. - I expect these to be the vast majority of Juice users
• Application Managers/Developers with basic confidence in html/css & Javascript - It is this group who will copy then make enhancement to already available extensions, create new ones, and create definitions for previously unsupported applications.
• Advanced developers - in addition to all of the above, this group will enhance and develop the Juice framework itself and create new more complex extensions.

If the community grows as I hope, I expect that these groups will constitute approximately 90%, 9% & 1%, respectively, of the Juice users.

The Juice Philosophy

Guiding, but not set in stone, principles:

• The barrier to understanding and take-up of Juice by the vast majority of users needs to be maintained at a low level as possible.
• The impact on the application that Juice is extending should be as small as possible. Ideally no more than the inclusion of three single-line <script> elements.
• When there is more than one option for implementation, the low barrier for entry requirement for non-advanced users will always win out.
• Whenever possible, hide the code from the copy and paste user.