Experiences creating a SPARK compliant widget set

Keywords: SVG GUI, Interoperability

Christopher T. Lewis
Bioinformatics Biologist
Agri-culture and Agrifood Canada
PhD Canadidate
University of Saskatchewan
Founding Partner
Vectoreal
chris.lewis@vectoreal.com

http://homepage.usask.ca/~ctl271

Biography

Chris Lewis is a computer science graduate of the University of Saskatchewan. In 2001 he joined Agriculture and Agri-food Canada as a Bioinformatics Biologist and developed an SVG GUI library (CGUI) to enable a web based comparative genome browser and has been actively working with SVG since that time. He has been involved with the SPARK project since its inception in 2002. He presented the CGUI library and genome browser at SVG Open 2002 and coordinated an SVG GUI workshop at SVG Open 2003. In 2004, he because a founding partner of Vectoreal, a company specializing in standards-compliant web applications.


Abstract


Scalable Vector Graphics (SVG) is a World Wide Web Consortium (W3C) specification for defining 2D vector graphics, which offers interactivity via scripting and declarative animation. The fact that the graphics are specified in Extensible Markup Language (XML), coupled with their interactive nature has resulted in considerable interest in the use of SVG for web application development. For the most part, developers of SVG enabled web applications have had to develop their own widgets from scratch, which has required considerable duplicated effort. The SVG Programmer's Application Resource Kit (SPARK) GUI Framework (SPARK-FW) was proposed in an effort to make widgets from different sets interoperable and thereby allow developers to concentrate on creating new widgets.

This project sought to evaluate the usefulness of the SPARK-FW by converting an existing SVG GUI library to make it SPARK compliant. The effort provides three key benefits: a set of guidelines that the developers of other SVG based widgets can employ when adapting their widgets to work within the framework; a set of proposed extensions or modifications to the framework based on needs identified in this more thorough exploration of the framework; and a demonstration that the framework is generally applicable.

Supplementary resources, including the widgets used in this paper and their source code will be available at http://homepage.usask.ca/~ctl271/cgui/spark.


Table of Contents


1. Introduction
2. Background
     2.1 CGUI
     2.2 SPARK
     2.3 SPARK & CGUI
3. Experiments
     3.1 What needs to done to make the widgets SPARK compliant?
          3.1.1 Extend the SPARK hierarchy
          3.1.2 Allow the CGUI widgets to use Commands
          3.1.3 Allow the widgets to be created declaratively
     3.2 How can the new widgets be used within the SPARK framework?
     3.3 How is functionality added to a SPARK widget?
     3.4 Can the widgets be declared more concisely?
     3.5 Can the new SPARK compliant CGUI widget be used with the existing SPARK widgets
4. Guidelines
5. Proposed Extensions
6. Sample Applications
7. Conclusions
8. Future Work
     8.1 Server-side generation of widgets
     8.2 Groupware
     8.3 Integration with other technologies
     8.4 Use new standard functionality
     8.5 Ajax
     8.6 Plasticity
Acknowledgements
Bibliography

1. Introduction

SVG [SVG] is a W3C specification for defining 2D vector graphics using an XML grammar [XML]. The specification treats shapes as first class citizens that can be grouped and easily manipulated through the application of transformations and stylesheets. The format offers interactivity via client side scripting and Synchronized Multimedia Integration Language (SMIL) animation [SMIL]. The XML format coupled with the interactive nature of the graphics has resulted in considerable interest in the use of SVG for web application development [Qiu2004, Schepers2004, Lewis2003], especially in the field of cartography [Ueber2003, Carto].

For the most part the developers of SVG enabled web applications have had to create their own widgets from scratch. This has resulted in many interesting variations of the same basic widgets at the cost of considerable duplicated effort. In an attempt to make the creation of web applications easier there have been attempts to create standard SVG widget sets, among them the kevlindev.com widgets [Lind], the CGUI widgets [Lewis2002, CGUI], the SVgUI project [SVgUI] and the dSVG widgets [dSVG] from the Corel Smart Graphics Studio project. However, even in these projects there was substantial duplication and a lack of interoperability between the resulting widgets.

To promote interoperability and thereby decrease wasted effort, the originators of the SPARK project [SPARK] began to discuss the possibility of an SVG GUI framework that would provide guidelines for the construction of SVG widgets and, if followed, allow interoperability between widgets from different sets. The first draft of the SPARK-FW has since been made available [SPRKFW], though only a limited number of demonstration widgets were created to test its utility [SPARK] and its general applicability was not, strictly speaking, demonstrated.

This project sought to evaluate the usefulness of the SPARK framework by refactoring a proven SVG GUI library (CGUI) [CGUI] to make it SPARK compliant. This process provided three key benefits: a set of guidelines that the developers of other SVG based widgets can employ when adapting their widgets to work within the SPARK-FW, a set of proposed extensions or modifications to the SPARK-FW based on needs identified by this more thorough application of the framework, and a demonstration that the proposed framework is generally applicable.

The remainder of this paper proceeds as follows: first, necessary background regarding the CGUI and SPARK projects is presented, and then the steps taken to make the SPARK compliant CGUI (S-CGUI) widgets are outlined. Next the conversion guidelines and suggested extensions elucidated by this process are presented, and two sample applications created using the converted widgets are presented. The final pages summarize the results of this work and suggest topics for further investigation.

2. Background

2.1 CGUI

The Custom Graphical User Interface (CGUI) library is a set of widgets implemented in ECMAScript and SVG for use in web applications. CGUI was initially developed to enable a web based genome browser that would display comparative genomics information between the plant Brassica napus (Canola, rutabaga, rape) and the model organism Arabidopsis thaliana (thale cress or mouse eared cress) [Lewis2002, Lewis2003]. Since then the library has been used in a Security and Properties Management tool (C. Peto, publication pending) and a web based SVG Editor (C. Peto, unpublished) [SVGED].

The widgets are implemented using ECMAScript objects to maximize code reuse and ensure the smallest possible size for the packaged source. The original widgets had the ability to render themselves using a hard coded skin, though the visual representation was later separated from the widget and moved to external Schemes. In addition to the base appearance, the widgets also provide a number of visual cues to indicate their state. For instance, buttons can be in the selected, active or disabled state and their appearance is altered accordingly. The downside of the CGUI widgets is that they are created imperatively, which doesn't appeal to some users who desire a declarative syntax more in keeping with the declarative nature of SVG.

image002.jpg

There are three basic types Bar, Pane and Button and a composite type Frame which can be moved, resized, minimized and closed.

Figure 1: Root of the original CGUI hierarchy

image003.jpg

Every widget has an anchor property inherited from CGUI that can be used to position the widget relative to some target SVG Element (it may be another widget or an Element in the SVG document). Similarly, every ButtonPane (a Pane containing a set of Buttons) has an associated ButtonGroup which controls the behavior of the set of buttons in the ButtonPane (for instance they might be set to behave as checkboxes or radiobuttons).

Figure 2: Example associate classes

The original CGUI design philosophy was that all widgets should inherit common functionality from the root CGUI class (Figure 1), that there would be a small number of basic widgets that could be extended to provide more sophisticated functionality (Figure 1) and that each widget would be responsible for generating its own view. There are three basic widgets, a Pane to contain other widgets and act as a layout element (somewhat akin to a simple java.awt.Pane), a Bar to contain text and buttons (which in hindsight is superfluous and should be absorbed into the Pane), and a Button to receive user input. The fourth type is a Frame, this is a compound widget made up of 1 or more Panes and 1 or more Bars to allow them to be moved as a group, minimized, etc... thereby creating a Window (somewhat akin to the java.awt.Frame). Classes without a visual representation, for instance helper classes, do not inherit from the hierarchy but are instead associated with the appropriate widget(s) (Figure 2).

image004.jpg

Figure 3: Root after architectural change

There has been one architectural change to the CGUI library since the initial version, which brings us to the pre-SPARK state of the CGUI library. The change involved the separation of the widget's appearance from the widgets themselves. The definition of the widget's view was moved into a separate Scheme class, one for each widget, and a collection of Scheme's is assigned by the designer when the application is initialized. Each widget uses the corresponding scheme in the assigned collection unless the designer overrides the scheme associated with an individual widget or instance of a widget. At this time all widgets were also made to extend the EventHandler class, which made common event registration/deregistration and event handling methods available in all widgets (Figure 3). The intent here was to extend this to provide a queue so that multiple event handlers could be registered for the same event type on a given widget, though this has yet to be implemented.

2.2 SPARK

The SPARK-FW defines a root hierarchy that is arguably quite similar to the original CGUI hierarchy (Figure 4). In the SPARK-FW each widget inherits common functionality from the root Widget class and there are a number of basic widgets that must be extended to provide more sophisticated functionality. These basic types closely resemble those of the CGUI hierarchy in that one provides a mechanism for receiving user input and the other is used to group related widgets.

image005.jpg

The root class in the SPARK hierarchy is the Widget. There are two abstract classes that extend Widget, Atom and Container, which define basic widget types. Each widget in the SPARK framework can access core functionality available through the SPARK class.

Figure 4: SPARK Root Hierarchy

image006.jpg

A RadioButtonGroup is a Container containing some number of buttons. The RadioButtonGroup contains the logic related implementing the RadioButton behavior.

Figure 5: Implementation of RadioButtonGroup in SPARK

However, there are a number of philosophical differences between the SPARK widgets and the CGUI widgets. For instance, while the SPARK Container and CGUI Pane are conceptually similar they come with different expectations. It is expected that a Pane will establish a viewBox and that items contained by a Pane but extending outside the visible area will not be displayed (though this expectation has relaxed over the course of time), whereas there is no such expectation of the SPARK Container. Another example can be seen on examination of the CGUI ButtonPane. In CGUI the RadioButton behavior is delegated to a non-widget so that you could have a ButtonGroup without requiring that the Buttons appear in a particular Pane (Figure 2). Whereas in the SPARK examples, the RadioButtonGroup is a container, so Buttons which are part of that group cannot be placed in other Containers (Figure 5).

image007.gif

The above SVG Fragment shows the declarative creation of a SPARK Button. The lines have been prefixed with a line number for ease of explanation. The <g>roup element (Lines 1-2) positions the button at x=300, y=100 relative to its parent document and declares the type in its class attribute; in this case the widget is a SPARK atom of type Button. The portion "Style 1" can be used by the applied Cascading Style Sheet (CSS) to style the button. The view of this widget (lines 5-16) is an ellipse that expands, via declarative animation, when the mouse is over the button and then returns to its base state when the mouse moves off the widget.

Figure 6: Creation of a SPARK Button

image008.jpg

The button on the right corresponds to the button declared in Figure 6 above. The screen shot was taken with the mouse over the button on the right, hence it is slightly larger than the button on the left. The two buttons have a different visual appearance as a CSS has been applied to the button on the right.

Figure 7: Two SPARK buttons

Fortunately, such philosophical differences need not interfere with the ability to make S-CGUI widgets. Such decisions are not enforced by the SPARK framework and are left up to the designer of the widget set.

The declarative nature of the SPARK-FW necessitates two helper classes that were not necessary in CGUI. The first of these is the SPARKFactory. This class provides methods for creating SPARK compliant widgets. When writing new SPARK compliant widgets the designer would add these widgets to the Factory's list of known widgets. The second helper class is the SPARKDecorator, which is responsible for adding the appropriate functionality to the widgets as they are created. The designer would typically write a custom decorator for their application to assign the appropriate functionality to the widgets. The designer need only modify the SPARKFactory if they are adding new widgets for use in the SPARKFramework.

2.3 SPARK & CGUI

SPARK compliance offers several advantages to users of the CGUI widget set. The primary advantage is that S-CGUI widgets can be created declaratively and should be interoperable with other SPARK compliant widgets as they become available. An additional benefit is the ease with which S-CGUI widgets could have their appearance (skin) changed. This is because the skin can be created declaratively at the same time the UI is described in the SVG document. Thus the designer can provide virtually any representation of the widgets at the time that they create their UI (Figure 6, Figure 7), whereas a user of the CGUI widgets must code a custom skin.

Despite these advantages there are several important considerations when adapting the CGUI widgets. While declarative declaration of the widgets is desirable, there may be circumstances where an imperative interface is preferable and/or necessary. Thus all efforts should be made to ensure that the widgets can be created imperatively after they become SPARK compliant. Furthermore, where possible the old imperative interface to the CGUI widgets should be preserved to minimize the impact of the changes on existing applications.

3. Experiments

This project proceeded as a series of incremental experiments. The primary objective was to determine whether or not it would be possible to make the CGUI widgets SPARK compliant, while the secondary objective was to explore any possible extensions to the SPARK-FW highlighted by the experiments. These experiments are briefly described here; in some cases work that was performed as part of separate experiments has been grouped together for the sake of clarity.

3.1 What needs to done to make the widgets SPARK compliant?

3.1.1 Extend the SPARK hierarchy

SPARK compliant widgets should inherit from the SPARK hierarchy. In general, this means extending one of either Atom or Container, whichever is the most appropriate for the new widget. As the CGUI widgets do not extend the SPARK hierarchy, this seems like a fairly obvious starting point in the conversion process. Unfortunately this process is complicated by the fact that all of the widgets already extend the CGUI hierarchy.

image013.jpg
image014.jpg

Figure 8: Replace inheritance with delegation

The straight-forward approach to having the CGUI widgets extend the SPARK framework is to have them inherit from both the CGUI and SPARK hierarchies. Of course there are many reasons why multiple inheritance should be avoided, so the 'replace delegation with inheritance' refactoring is used to maintain access to the CGUI core functionality while allowing the widgets to extend the SPARK classes (Figure 8). Delegating the CGUI functionality required creating an instance of the CGUI object inside the CGUI widget and making all calls to the inherited CGUI functionality via the new reference. In the case where the CGUI method was overridden or extended, the widget's method will now call the method on the CGUI instance and perform the necessary additional functionality as appropriate.

3.1.2 Allow the CGUI widgets to use Commands

In the CGUI framework event handler code can be passed to widgets such as a Button or MenuItem, which is called when the widget handles the mousedown event. In the SPARK framework, this event handler code is provided in the form of Commands, and multiple commands can be added to a given widget. By extending the SPARK framework, the old CGUI widget inherits the addCommand and runCommands functionality, to the line of code that executes the event handler code can be replaced with a call to runCommands, and the code allowing event handler code to be assigned can be removed. After this the old EventHandlers can be trivially converted into Commands and added to the widget using the addCommand method.

3.1.3 Allow the widgets to be created declaratively

The SPARK-FW requires that widget constructors accept a single argument, the DOM tree describing the widget; this tree can be a subtree in a larger document or a document fragment. This requirement allows the widgets to be created by the SPARKFactory class in a single pass of the SVG document when the document is loaded and seems like a logical second in the conversion process. The challenge here is to change over the CGUI constructors, while preserving a simple imperative interface.

The SPARK constructor traverses the DOM subtree and saves references to nodes in the DOM as necessary. For instance, all SPARK widgets have an anchor property which references the root of the widget's subtree. This is a marked contrast to the CGUI widgets, which are created imperatively and take arguments as necessary to construct the object and create the view defined in the associated Scheme.

There are really two problems here. First, the constructor needs to be modified so that it takes in the tree describing the widget as an argument. Second the logic which initializes the ECMAScript object must be preserved and the initialization parameters must be extracted from the DOM subtree. In order to preserve the initialization logic the "extract method" refactoring can be used to move all of this into an initialization method, and, at this time, the call to create the widgets view can be removed. Once this is complete, the arguments in the constructor can be replaced with the single input, and a parseDOM method added to extract the required initialization parameters and save references to nodes in the DOM. After the parameters have been extracted from he DOM, the object can be initialized using the old logic.

image017.gif

The constructor for the old CGUI button took 4 arguments (as well as some optional arguments which have not been shown here). The width and height of the button, the label for the button and either an object implementing the EventListener interface or a method to handle the event. The new SPARK compliant Button takes in the root of the DOM tree representing the widget, and the width, height and label parameters from the old constructor have been moved to the createScheme method. The object implementing the EventListener interface has been replaced by a Command as per the SPARK framework.

Figure 9: Imperative declaration of converted CGUI Button

This change allows the widget to be created declaratively using the SPARK-FW, but does not prevent the widget from being created imperatively. The tree describing the view can be constructed with the necessary parameters from the old constructor call, added to the SVG Document and then passed to the new constructor (Figure 9).

3.2 How can the new widgets be used within the SPARK framework?

At this point, it appears that it should be possible to use the converted CGUI widgets in the SPARK-FW. The constructor has been modified to make it usable by the SPARKFactory, which should allow a UI to be declaratively created. All SPARK related functionality, for instance, the ability to add and execute Commands is available because the widgets extend the SPARK hierarchy. And finally, Commands added to the widgets will be executed.

Widgets in the SPARK-FW are created by the SPARKFactory when the SVG Document is loaded. Each node in the DOM is inspected, and if the class corresponds to a registered SPARK type, then the appropriate constructor is called via the Factory. In the original SPARKFactory there was a hard coded list of available widget types, and a hard coded constructor applied for each type. So to use a newly created widget within the SPARK-FW, the SPARKFactory would have to be modified in two places, once to add the new widget type to the list, and once to add the widgets constructor to the method that creates the widget.

image011.gif

The above shows an example of a SPARK compliant widget registering itself with the SPARK-FW. The registerWidgetType method will be called when the source file is included in the SVG document.

Figure 10: Widget Self Registration

An alternative to modifying the SPARKFactory when new widgets are added is to register the widget type and constructor with the SPARK-FW when they are included in the SVG document (Figure 10). This approach has two main advantages. First, there is no need to modify the SPARKFactory to add a newly created widget. This means that the SPARKFactory can be treated as a static framework class that need not be modified by developers, which makes it easier to add a new widget to the Framework. Second, only the widgets that are used in the application are registered with the Framework, which saves including unused widgets or having to comment out references to them in the SPARKFactory. While this is an implementation detail that doesn't fundamentally alter anything about the SPARK-FW, this approach seems to work quite well and has been used in all the examples produced as part of this project.

There is no explicit imperative mechanism for creating widgets within the SPARK-FW, however they could be created by calling the constructor directly or calling the createWidget method of the SPARKFactory.

3.3 How is functionality added to a SPARK widget?

The SPARK-FW uses the a SPARKDecorator to attach Commands to the widgets at the time they are created by the SPARKFactory. The command pattern [Gamma1995] encapsulates an action in an object whose functionality can be executed. The motivation for using commands in the SPARK-FW is that this makes it possible for application designers to easily add logic to an otherwise generic framework.

On startup, after the widgets have been created by the SPARKHelperFactory, the decorator is responsible for adding the appropriate command(s) to the newly created widget, based on the widget's id. This means that a new decorator must be written for each application. An alternative to writing a new decorator for each application is to allow the widget to be decorated declaratively at the time that the UI is designed.

image010.gif

Figure 11: Declarative Decoration

This declarative decoration was enabled for trial purposes as part of a SPARK Extension by placing a decoration tag inside the widget declaration (Figure 11). The decoration tag specifies the name of the command with which to decorate the widget and provides any arguments to the command constructor as attributes. This extension required changing the SPARKFactory and SPARKDecorator to have them look for and process the decoration tag.

3.4 Can the widgets be declared more concisely?

The example button declaration presented in Figure 6 is quite verbose. Now imagine using that notation to describe an entire application, how long would the resulting SVG document be? Two different techniques were explored in an effort to make the GUI declaration more concise. Ultimately, the correct way to do this will be through the use of sXBL elements, but until the specification is fully defined and there is a stable SVG viewer which supports sXBL other approaches are needed.

image009.gif

In the above example the view (Lines 5-16) has been replaced with a placeholder in a separate namespace. On startup the document will be parsed by a tag replacement method, and where the body tag is encountered it will be replaced by the appropriate view as determined by the class of the containing parent element (in this case "SPARK atom Button"). Parameters related to the construction of the view are passed in as attributes on the body tag. In this case the label for the button has been passed in, though arguably that should be set as part of the buttons model and extracted from the model.

Figure 12: External View

The first technique involved moving the view to a separate file and replacing it with a placeholder in the SVG document. This placeholder is replaced by the externally defined view at the time that the SVG Document is loaded (Figure 12). This technique required the creation of an additional helper class to parse the document when it loads and replace all placeholders with the correct view. This technique has the advantage of being relatively simple and flexible as any necessary parameters can be set as attributes on the placeholder. However it requires the addition of a new custom tag and another helper class.

The second mechanism by which the view could be extracted is through use of the 'use' tag. The 'use' tag allows an SVG fragment to be defined and then reused throughout the document. This allows the view to be extracted without the need for a new tag and helper class, however it has a fairly serious limitation. While the referenced SVG fragment is rendered as if it was at the specified location in the DOM, the inserted fragment is actually part of a separate DOM and not accessible for manipulation via scripting. This makes it impossible to do things such as adjust the properties of the view to reflect state changes in the widget (though the widget can be styled via CSS) or to initialize the widget on creation. So this technique is best suited to creating templates that will never be changed.

A workaround for this limitation is to replace the use element in the DOM with the actual content that it references; however the benefits of this approach rather than the external definition are not clear (this approach was employed later in the plastic clock experiment) as you end up doing essentially the same thing. In fact, this approach might be the worse of the two as it may not be desirable to replace all 'use' elements in the document and so some mechanism for distinguishing between 'use' elements is required.

3.5 Can the new SPARK compliant CGUI widget be used with the existing SPARK widgets

At this point the CGUI button can be said to be SPARK compliant. It extends from the SPARK framework, implements the CommandHolder interface and uses Commands to perform its task, implements the Observable pattern to allow other widgets to receive notification when it receives user input and can be created declaratively by the SPARK factory. Now, the question becomes, has it achieved interoperability with other SPARK widgets? After all, interoperability was the major motivation for the SPARK-FW.

The new S-CGUI widget was used within the existing SPARK examples simply by substituting the old SPARK Button source for the new S-CGUI Button source and including the necessary CGUI sources. The only difficulty was an ECMAScript error that appeared when the SPARK Window containing the Button's was minimized. This turned out to be because the SPARK Buttons had undocumented show and hide methods rather than due to any fault in the S-CGUI Button.

4. Guidelines

There were four guidelines identified in the above experiments that can be employed when making an existing widget set SPARK compliant. These include:

The SPARK hierarchy provides two base widgets that should be extended when creating a new widget. In order to make a widget set SPARK compliant the existing widgets must be classified as either Atoms or Containers. This should be a straight-forward process as an Atom will not contain other widgets and may receive user input, while a Container may contain other widgets and is unlikely to accept user input. Another way to think about this is that the atom will generally provide the target for user input.

After classifying the existing widgets it is necessary to modify them so that they extend the appropriate SPARK class, either atom or container. If the existing widgets don't inherit from an existing hierarchy, this can be accomplished by setting the widgets prototype to be that of the extended class, and calling the super classes' constructor. If there is an existing hierarchy, then the functionality inherited from the existing hierarchy can be delegated to an another class (Figure 8). The "replace inheritance with delegation" refactoring is useful for this exercise.

Having made the SPARK functionality available to the newly created widget and tested that it is accessible imperatively, it is time to alter the widgets constructor to allow it to be created declaratively within the SPARK framework. This means changing the widget's constructor so that it takes the root of the DOM sub-tree describing the widget as an argument and then binds to the tree as needed to provide necessary interaction.

It is desirable to keep something close to the old imperative syntax when modifying the constructor to ease migration of applications based on the old widget set. One way to do this is by separating construction of the view (i.e. DOM sub-tree) from the construction of the widget if it is not already separate. In doing so, ensure that any view related parameters which were previously passed to the widget constructor are passed into the method which returns the view, and add an init method to the widget that can be called with the remaining arguments to initialize the widget. Now, when the widget is created imperatively the view can be constructed and passed to the widget constructor as an argument, and when the widget is created declaratively the view and any initialization parameters can be extracted from the xml document describing the interface. The extract method refactoring is useful for moving view construction and initialization functionality out of the constructor.

The final step will be to modify the widget so that any code that should be executed in response to user input is executed via a Command. This can be accomplished by converting objects that implemented the Event Handler interface directly into Commands, though in the case of a complex Event Handler it might make sense to split this into a number of Commands. Then, these commands can be added to the widget using the addCommand method rather than registered as event listeners on the SVG Elements. If a method was used as an event handler previously rather than an object implementing the Event Handler Interface, that method can be moved to the execute method of the new Command, or split into several Commands just as the handleEvent method could be split.

5. Proposed Extensions

Three possible extensions to the SPARK framework were identified and explored as part of this project.

6. Sample Applications

There were two sample applications produced as part of this exercise. The first of these, the "Train Game" is a simple grid based game that makes use of a number of S-CGUI Buttons with custom skin's designed to look like train cars. The second of these, the "Plastic Clock" is a simple grid based application that displays clocks for different time zones, and depending on a number of user definable parameters my display the clocks side by side or superimposed on top of each other. Each of these is contained in an S-CGUI Pane, another widget that was converted to test the above guidelines.

image018.jpg

Each car in the train game is an S-CGUI button with the appropriate skin applied to it. When the buttons are clicked, they move behind the car that should precede it in the train, or move to the front of the line in the case of an engine if the space is available. Once all the cars have been arranged, either properly or there are no more valid moves, the game ends and a little animation moves the complete trains out of the yard.

Figure 13: Train Game

The "Train Game" was developed to experiment with the use of externally defined skins and to test the simple S-CGUI widgets in a semi-real application (Figure 13). The object of the game is to return the scrambled train cars to their initial state and so that they can leave the yard. The train cars in the application have been implemented as S CGUI buttons with custom, externally defined skins. They were implemented as Buttons because it is intended that they will receive user input (a click event) and move in response to this input if there is a move available. The yard was implemented as a Pane as it has been used to contain and layout the Buttons.

Each car in the train yard has a Command associated with it that causes it to move in response to the click event. A better implementation might have been to associate the Command with the yard itself, and then have the click on the car propagate up to the yard. This would have involve the creation of less Command objects, and provided the yard with more responsibility for controlling the layout of the cars. Currently the behavior of the Buttons in the yard was handled by an associated class called by the buttons rather than through the Pane. The possibility of having the event propagate up to the yard and executing the Command there should be explored further in the next round of development on the Train Game.

image021.jpg
image020.jpg

The top screen shot shows the plastic clock configured to display four clocks, each with a different timezone. As the Pane is resized the layout of the clocks changes based on the configurable number of clocks and minimum clock size. For instance, as the Pane becomes smaller, the clocks will morph into one larger clock that occupies the whole pane (bottom screen shot).

Figure 14: Plastic Clock

The second application of the SPARK compliant CGUI widgets was to create a "Plastic Clock" (Figure 14). Plasticity is the measure of how well a user interface adapts itself to different displays, and the clock was a little experiment to show plasticity in SVG based applications. An SVG UI can be said to be trivially plastic based on the ability to infinitely scale an SVG graphic, however this experiment sought to show how the interactive nature of SVG allows more than a trivially plastic UI.

The original plastic clock (FlexClock) [Grolaux2001] was written as a replacement for the default XClock in the Unix operating system. It was designed to show the time in a number of formats depending on the size of the window it was displayed in. For instance, it might show a digital clock at one size, an analog clock at another size, and an analog clock with a one month calendar at a third size. The SVG plastic clock takes a slightly different approach. This clock was designed to display multiple time zones and only in an analog display. The clock takes advantage of transparency in the SVG specification to overlay clocks showing different time zones on top of each other when there is not enough space to display them beside one another. The clocks will always expand to take the maximum available space and have a user specifiable minimum size which controls when the clocks scale to fit the current cell rather than overlaying each other.

7. Conclusions

This work developed a simple and concise set of guidelines that should facilitate the quick and easy conversion of an existing SVG widget to a SPARK compliant widget. Such an effort has been shown to result in widgets which are interoperable with other SPARK compliant widgets as demonstrated by the use of the SPARK compliant CGUI widgets with the original SPARK sample widgets.

The three proposed extensions to the SPARK framework have been tested in the working examples produced for this paper and seem likely to make valuable additions to the framework once they've been suitably tested and refined.

The conceptual ease with which existing widgets can be converted to SPARK compliance and then used in a real application bodes well for the general applicability of the SPARK-FW for web application development. One real hindrance to the easy conversion of an existing widget set is the lack of a good ECMAScript editor with tool support for the refactoring the sources.

8. Future Work

There are a number of future work items that require little explanation or have already been explained in the proceeding text, for instance:

There are also a number of more interesting items that arise as a result of this effort. These are briefly discussed in the concluding text.

8.1 Server-side generation of widgets

The toy applications presented here were both fun and interesting, but they don't really capitalize on the benefits offered by SPARK compliance. For instance, the ability to create widgets declaratively means that it will now be possible to create new views on the serverside. This ability will make it worthwhile to track the state of the widgets in a database, which this can be used together with some sort of session tracking to save the state of an application so that the user can return to the application in the state from which they last accessed it. How best to track the state of SVG based web-applications has been a long standing question in the SVG community.

This implies the need to add an API for generating the widgets on the serverside to the SPARK framework, and a messaging framework for tracking the widget state on the server, thereby adding persistence to the widgets. In an environment which didn't allow client side scripting to modify the view, for instance SVGT, this messaging framework could be used to redraw the application and return a new view each time a change was requested, much like current web applications generate a new bitmap and return it to the client to allow interactive visualizations.

8.2 Groupware

An interesting addition to the SVG 1.2 specification is sockets. This makes more interactive client server applications possible because the server can now easily push data to the client rather than waiting for the client to poll for new information. Socket based communication together with the messaging framework suggested above could be used to allow distributed, collaborative tools based on SVG to communicate. This would see the messages used to track the state of a widget on the server used to communicate change of state messages to a collaborator's computer, thereby enabling SVG based groupware.

8.3 Integration with other technologies

It has often been suggested that SVG could be used to render the widgets defined as part of the XForms specification. Now that the SPARK framework makes it relatively simple to create interoperable widgets, whether or not XForms widgets could be easily created within the SPARK framework needs to be evaluated. One method for doing this might be to use the XForm widget definition as the model for the resulting widget and the existing framework to provide a view for it.

This is an important step as one of the advantages of SVG over similar proprietary formats is its ability to interact with other standards in a mixed namespace document. Up till now, due to a lack of compliant browsers, SVG developers have been force to work primarily within a plugin environment, which has restricted their ability to mix XML technologies. However, with the recent announcement that Opera supports SVGT and that Mozilla 1.1 will support the full SVG specification natively, a whole new world of opportunities become available. Evaluating the degree to which SPARK can take advantage of the Xforms specification seems like a manageable first step.

8.4 Use new standard functionality

sXBL is an SVG specific subset of the XML Binding Language that is important from the SPARK perspective as it allows the easy creation of interactive code templates. Unlike the use element, the DOM of a template added via the sXBL framework is accessible for manipulation. This should make it easier to template widgets and to modify their appearance without the "replace use hack" described earlier. The question is, how easy to modify SPARK compliant widgets to take advantage of the opportunities presented by sXBL?

8.5 Ajax

Ajax is an emerging approach to web application development that integrates a number of existing technologies XHTML+CSS, DOM, XML+XSLT, XMLHttpRequest and ECMAScript to provide more fluid and flexible web interfaces. It does this by eliminating the page reloads that existed as part of the old web paradigm. It will be interesting to see how the experiences of the Ajax community influence SVG based web application design, and how SVG might become part of this model. It is particularly interesting to the author because on the surface the approach taken by the Ajax community is almost exactly what was done in the Brassica / Arabidopsis Comparative Genome Browser when it was developed. With the possibility of moving SVG applications out of the plugin environment in the not too distant future, the Ajax paradigm could play a role the development of future SVG based applications.

8.6 Plasticity

An SVG based user interface should automatically do well with regard to plasticity as the UI can be scaled for free. Thus it should be possible to design an interface for an arbitrary display resolution and then scale the interface using the viewBox of the SVG document. However, for extreme changes in resolution, for instance from a desktop display to a large display or cellular phone display, the UI is unlikely to be usable even if it is scaled to reflect the resolution of the display. The question to be answered here is how, if at all, SVG can be used to create standard, plastic widgets that will function on a variety of display formats.

One possible solution is the use of XSLT to adjust the interface on the server-side. This transformation could happen before the UI is sent to the client in a web environment, or to simply generate the appropriate depending on the display resolution when the application is started in a standalone environment. However, even more interesting would be widgets that were smart enough that if the display resolution changed the UI would be transformed.

Acknowledgements

Thanks to Alastair Fettes and Dr. Philip Mansfield for their work on the SPARK and in particular their development of the first version of the SPARK GUI Framework. Thank you also to Dr. Kevin Schneider for his encouragement of this project, and especially to my supervisors Drs. Tony Kusalik, Isobel Parkin, and Derek Lydiate.

Bibliography

[SVG] Ferraiolo J., et. al. (eds), Scalable Vector Graphics (SVG) 1.1 Specification, www.w3.org/TR/SVG, 2003.
[XML] Bray T., et. al. (eds), Extensible Markup Language (XML) 1.0 (Thrid Edition), www.w3.org/TR/REC-xml/, 2004
[SMIL] Schmitz, P. Cohen A. (eds), SMIL Animation, www.w3.org/TR/smil-animation/, 2001.
[Qui2004] Qiu, X., et. al., Making SVG a Web Service in a Message-based MVC Architecture, SVG Open, 2004. http://www.svgopen.org/2004/paperAbstracts/MakingSVGaWebServiceinaMessageBasedMVCArchitecture.html
[Schepers2004] Schepers, D., Web Applications and Compound Documents Leveraging SVG, W3C workshop on Web Applications and Compound Documents, 2004. http://www.w3.org/2004/04/webapps-cdf-ws/papers/WebAppPosition-Schepers.html
[Ueber2003] Uebersch䲬 N., SVG for web cartography - recent developments and the future, "web.mapping" conference presentation, 2003. http://www.carto.net/papers/svg/webmapping/index_en.shtml
[Carto] Carto.net, site for cartography on the internet. www.carto.net.
[Lewis2003] Lewis, C.T., et.al., The Brassica / Arabidopsis Comparative Genome Browser, A Novel Approach to Genome Browsing, Journal of Plant Biotechnology, 2003. www.jplantbiotech.com/journal_dir/ pdf_files/vol5_4/vol5_4pp197.PDF
[Lind] Kevin Lindsey, KevLinDev: Kevin Lindsey Software Development. www.kevlindev.com.
[Lewis2002] Lewis, C.T., et.al., BioViz: Genome Viewer, Development of an SVG GUI for the visualization for genome data, SVG Open, 2002. http://www.svgopen.org/2002/papers/lewis_et_al__bioviz_genome_viewer/
[CGUI] CGUI Homepage, http://homepage.usask.ca/~ctl271/cgui
[SVgUI] SVGUI Project, http://svgui.sourceforge.net/
[dSVG] dSVG 1.1 Specification and Test Suite, http://www.corel.com/servlet/Satellite?pagename=Corel/Downloads/Details&id=1047022055166
[SPARK] SVG Programmers Application Resource Kit (SPARK) Project, www.schemasoft.org
[SPARKFW] Fettes, A., Mansfield, P., SVG-Based User Interface Framework, SVG Open, 2004. http://www.svgopen.org/2004/papers/SPARK/
[SVGED] Peto, C., Web Based SVG Editor. http://www.resource-solutions.de/svgeditor/
[REFAC] Fowler, M., Refactoring Home Page. http://www.refactoring.com/
[Fow1999] Fowler, M., et. al., Refactoring: Improving the Design of Existing code, Addison-Wesley Professional, 1999.
[Grolaux2001] Grolaux, D., et.al., QTk: An Integrated Model-Based Approach to Designing Executable User Interfaces, PreProc. of 8th Int. Workshop DSV-IS 2001, 2001.
[Gamma1995] Gamma, E., et. al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional, 1995.

XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.