SVG as a Key Technology for the Spatial Collaborative Structuring of Knowlege

sTeam whiteboard with SVG functionality

Keywords: Shared Whiteboard, CSCL

Thorsten Hampel
Jun. Prof. Dr. rer. nat.
Universität Paderborn
Fürstenallee 11
Paderborn
33102
Germany
hampel@upb.de

Biography


Abstract


The SVG-format opens new perspectives of net-based learning and working due to its manifold options. This article describes our efforts to develop new forms of a net-based spatial structuring of knowledge in groups and testing them in practice. Our java-based shared whiteboard has been extended to allow for a graphical representation of knowledge via SVG-maps, which can then be used in classical WWW-based e-learning environments. The conceptual centre is defined by the concept of knowledge-spaces, which can be structured semantically into groups. It is then possible to publish them as navigational aids and knowledge representations in the internet.


Table of Contents


1. Introduction
2. Concept
3. Technical Realisation
     3.1 Whiteboard Architecture
     3.2 Implementation within the Whiteboard
          3.2.1 Class "SVGObject"
          3.2.2 Class "SVGGenerator"
     3.3 Storage options for SVG files
          3.3.1 Locale Storage
          3.3.2 Storage on a sTeam Server
          3.3.3 Storing into other data formats
     3.4 Integration into Stylesheets
4. Prospects
Bibliography

1. Introduction

The central element of group-based (collaborative) learning and working is the active semantical structuring (of) and orientation in knowledge stocks.

To ease orientation in virtual knowledge-spaces, a multitude of graphical aids for navigation has been developed and tested. Results range from local overviews, to clickable maps, up to three dimensional representations of a virtual world. The different approaches and display options can be generated automatically or manually (by authors or recipients). The latter can take place individually or cooperatively (Hampel et al. 2005). Virtual knowledge spaces act as a basic construct for cooperative work on virtual knowledge stocks.

Virtual knowledge spaces are lasting (or 'permanent') places in the net, in which people meet to cooperatively create, edit or structure knowledge. This is supported by multiple synchronous and asynchronous communication mechanisms (Hampel 2002). Virtual knowledge spaces consolidate different services and tools and act as a place for the semantical structuring and presentation of documents, images or any other kind of media object. Responsibilities and authorizations are contained as well.

Technologically this approach is based on the open-source-system sTeam (Hampel, Keil-Slawik 2002), with the 'sTeam Shared Whiteboard' responsible for graphical structuring. It allows for synchronous and asynchronous forms of structuring the knowledge space graphically. Due to other asynchronous methods of the sTeam system it is possible to define links between documents, create new material and open it within a browser or an editing tool. Thus the whiteboard only represents a view on the cooperative knowledge space. All actions and materials in the related virtual knowledge space and the whiteboard are persistent.

Relating to the technical and conceptual implementation the following three core competencies need to be named:

2. Concept

The goal of our approach is a representation of the extended options of the sTeam shared whiteboard into a SVG-based web representation that is as homogeneous as possible. The majority of available features have to be converted for use in the SVG format, especially in the area of navigational structures. This means that elements such as links and active elements have to be transformed into SVG-constructs.

The medium term the goal is even to allow for active structuring and manipulation mechanisms in the SVG-Viewer/Browser itself. This would enable the user to create knowledge structures directly in the browser without the necessity of a specific tool. WWW-based SVG views are active views on knowledge spaces (which ties into the basic concept of the sTeam system). Similarly wiki-based views on the same set of knowledge spaces can be used for a textual structuring into a wiki-hypertext-view.

In the introduced realisation a primary set of active navigational and structuring elements are converted into corresponding SVG structures. – These are:

3. Technical Realisation

3.1 Whiteboard Architecture

The whiteboard consists of a collection of java packages, each being responsible for a specific task in the whiteboard. This component based architecture allows for adding and removing components without the need to change the complete code. Each packet represents a different part of the program: E.g. there is a component responsible for client-server communication and display in the main window. Another component deals with navigational elements and the GUI.

Drawing tools are implemented in such a packet as well. It enables drawing, creating and moving of graphical objects within the whiteboard. Every drawing capability has a class that contains every possible formatting and is specifically called when needed. This guarantees that each drawing element can be regarded and maintained separately. Elements are drawn layer based similarly to SVGs. Fore- and background can therefore be edited and changed arbitrarily. Created elements (if they are drawing components) are saved in the form of attributes of the corresponding area and are published simultaneously, so that other users can interact with them. Embedded contents are deposited in the form of documents. Separately storing the created areas is unnecessary, since any change is instantly updated to the server. Spaces and objects are saved persistently, changes are applied immediately.

Java 'awt' and 'swing' classes have been utilized for drawing graphical elements. These resemble corresponding implementations in SVG code in the use of necessary data. Position vectors for example can be exported without mayor problems.

The whiteboard distinguishes between storage of objects, attributes and files. Documents and other contents are saved as files, graphical elements like images and the exported SVG are saved as objects, which can be called via a unique id. The described position and formatting data are saved as attributes.

3.2 Implementation within the Whiteboard

Mainly to classes that transform the java code have been added to the java-based whiteboard. One contains corresponding get and set methods, the other is a so called 'generator class' which enables the translation of code and subsequent creation of the SVG files. The SVGObject Class has been added to the component that deals with communication support and acts as an interface between the drawing packet and the 'generator'. The SVGObject class only gets data that is related to the current object, due to the concept of layers and the fact that the corresponding class is only called once per object. Thus data can be read in and out in layers which suits SVG.

Some of the existing classes and methods of the whiteboard are put to use to for example put documents and contents onto the server.

3.2.1 Class "SVGObject"

All data needed for the transformation of java drawing obcects is read into and out of this class. In case of the whiteboard these are placement coordinates, colours, fonts, line width, fore-, background and link information. Set methods create coordinates and are returned to the SVG generator class via get methods. The SVGObject class therefore acts as a container and transmission interface for the required data. Methods of this class are called within the responsible class (of the drawing object) and thus save the designated data. The object class consists of static methods, which are called from their corresponding classes and which store data that is needed for the export into the SVG format.

Required data are: The id of the SVG-object, which is required to assign an attribute to the sTeam server with a unique id. Other contained methods control: Colour data (fore- and background colour of graphical elements), line data (formatting, coordinates and direction [which is needed to display arrows]), data for displaying geometrical objects (coordinates, height, width), display of images and links (URL, hyperlink name), display of textboxes (one or multiple lined) and display of freehand drawings as well as different help methods that store object related data that's used in almost all graphical components.

These may include colourdata, line width, line type, fonts, font colour, font size and diverse bool methods, which check whether a SVG should be stored on- or offline.

3.2.2 Class "SVGGenerator"

After this storing is finished the generation of the SVGs commences. The designated methods are executed within their responsible classes (for a drawing). Necessary data is read from the described object class. The generator class takes this data, adds corresponding XML-Code and saves it to a string. This class sets the required attributes, calculates the size of the SVGs to be generated and adds Java-Script Code where needed.

To describe the process of SVG generation we introduce the example of a drawing consisting of 3 rectangles within the whiteboard. After pushing the export button a method is activated, generating a string and enabling the generation of an SVG in the appropriate drawing classes (here: 3 instances of the rectangle generation class). The class SVGObject is filled with required data. In this case these are coordinates (x,y), height, width, colour and line (border) data.

After each call the object is passed to the SVG generator class which is executed immediately. In the case of our example three times. The created string is filled with the SVG data produced by the generator class after each call of the component classes. After cycling through all objects the string consisting of the SVG data of the three rectangles is passed over to adequate methods. These add fitting start and end tags and either save the data as an object on the server or as a file on the local system.

The following activity diagram shows the SCG generation. The representation has been simplified, to show only relevant classes.

architektur.jpg

Figure 1: generation process

For an optimal display of the SVG a method that calculates the maximum distance to each point of origin is called for each representation object. This ensures that the resulting SVG does not succumb to a statistical size and that the representation and file-size can be created in an optimal way. In the following some special help methods will be described in more detail.

Help methods have been implemented that check if a multi-line textbox with scrollbar (slider) functionality exists in an area. Since there are no options to code multi-line texts with or without scrollbars directly, methods are needed to create java script with a "tspan" tag that creates and displays scrollbars within a textbox.

The basis fort his method was a simple scrollbar found on http://www.mecxpert.de/svg/slider.html. This scrollbar has been modified and extended, to allow for the execution of actions that are a necessity for this kind of representation.

Further aids have been implemented that allow to process data extracted from java drawing methods and return it in a usable form for SVG. Calculation methods of ellipses and different line types may act as an example. Drawing ellipses is solved differently in java than in SVG. While java needs the centre and radii of an ellipse, the SVG format needs the upper corners, height and width of the object. This transfer can be accomplished via a simple mathematical function. The same applies to line styles. Corresponding styles enabling a display in XML code are defined in the SVG generator (stroke-dasarray).

Additionally several methods have been implemented, that focus on the specific qualities of the whiteboard. For instance: The whiteboard supports to display icons with a matching label, individual formatting and linked to other elements. Within the whiteboard icons function as a link to other areas or documents. Drawing elements also contain manifold formatting properties.

For the export this has been implemented as follows: A grouping tag "g" has been assigned to the specific drawing object. This grouping has been instantiated with the link and the display of the icon as a "href"-tag. The icon label is passed as "text" or "tspan". Help methods have also been written for the link's ("href") properties that focus on the specialties of the export. These will be detailed in the following paragraph.

These methods generate a string that is processed in two ways. The first option allows the creation of an SVG file on a local system, to store a copy of the area. The second option is to create an object with SVG identification on a sTeam server.

A lot of other such help methods exist, but their description would exceed this article's function.

3.3 Storage options for SVG files

3.3.1 Locale Storage

After running through the generator class the generated string is saved into an SVG file, that is then saved to the respective system. Graphics contained in the area are saved as well and are linked into the SVGs. These graphics exist as objects on the sTeam server. These are transformed into image files, appropriately named and saved to the same directory as the SVG file. Corresponding to these names the images are linked in the "href" tags of the file's source code. Links on any kind of document however still point to the sTeam server to avoid unnecessary file transfers.

The rationale behind this storage option is a data preservation of an area on a local system.

3.3.2 Storage on a sTeam Server

This more interesting part of the port serves to make areas available to a wide range of students.

The created string is saves as an object to the displayed area and can subsequently be called via a unique object id of the server. Contained images in the SVG are similarly available in the form of objects on the server and are linked within the SVG file with their respective object id. Other documents again remain on their corresponding server and are just linked normally. The same methods are used for this that are applied when making a local copy.

The port allows displaying the respective areas in a browser using their ids. Data that is needed for further use (like the background colour of an SVG, or its width and height) is appended to the area. These data are needed for further optimal processing by the sTeam system. To allow for an easy embedding the next step uses the sTeam systems feature of accessing and editing object data and attributes automatically via style sheets. This will be discussed later.

3.3.3 Storing into other data formats

A wiki-document within an area has to be selected. A simple click does the following: An SVG object is transferred to the server as described. Simultaneously the wiki-document is loaded into the memory. A line is added to the document that enables the wiki to display the newly created SVG. The wiki document is then transferred back to the server.

wiki.jpg

Figure 2: Extract from the wiki code

Thus a simple mouse click has created a wiki-document with a SVG mind map that can be navigated.

The following paragraph will shortly describe the further usage of a created SVG. We assume that the SVG file has been exported to a sTeam server.

3.4 Integration into Stylesheets

One of the many qualities of the sTeam system in the area of web display and content management is the option to display contents via style sheets. In the properties of an area the user can define if and what style sheet should be used for display when the area is called.

This style sheet (xml/xsl format) allows for directly accessing, checking and displaying almost any object. In the case of displaying an SVG the following happens:

The administrator can efficiently write a style sheet that checks whether the mentioned SVG objects exists within an area. If negative the view can be changed to a separate http/https display. If positive the style sheet reads the set attributes (width, height and background colour) and uses them to fill the usual "embed" tag for inserting an SVG.

Thus the open sTeam server can automatically check an area for the existence of a graphical environment and display it accordingly. The only action the user needs to perform is to actually export the area to the server once it is created. If a style sheet has been created for the current area, the SVG is displayed within this style sheet.

In the following figure a whiteboard area is depicted (upper left) which has been transferred into an SVG and is displayed in a browser via a style sheet (lower right). The background colour has been set to white here.

Browseransicht.jpg

Figure 3: Whiteboard Area – Browser view

The main advantage of this development is the interaction of the server with the locally installed browser, which enables an appealing and graphically optimized representation. Only with the style sheet the SVG can be displayed (ergonomically and expediently) corresponding to aspects of modern design.

4. Prospects

The goal of this development is to display a graphically editable version of the created area directly within the sTeam system without detours through the shared whiteboard. Since SVG holds all required functions (server based communication, calculation within SVGs, etc.) an implementation via SVG is a worthwhile conclusion.

All graphical design options need to be ported into SVG to assure a later graphical editing in the server view of the sTeam system. Graphical editing, file upload and storage of contents need to be carried out by the SVG files. The goal is to allow for spatial arrangement, text input and graphical structuring of the areas directly with the SVG, using its animation features. This part of the port requires a javaScript based animation engine within SVGs that allows for moving several areas and adding new graphical options in the form of toolbars and buttons.

Also required is an interface within the SVGs that saves all modified attributes and objects, as well as the SVG code itself to the server. This guarantees the needed persistency. A preference would also be if it was possible to implement the described procedures in a way that makes them multi-user suitable.

A problem in the practical adoption is the sluggish development of viewers and the non-existent standard compatibility of browsers. Thus installation of a plug-in is still required to display SVGs. Hopefully SVG-support will become a an integral part of all available browsers over time.

The function of SVG export is a possibility for the informatics and society chair to bring further functions into browser views that could otherwise only be realised with a lot of programming effort. This should be treated as a constantly evolving process only restricted by the W3C specifications of the SVG format. Based on evaluations at the university of Paderborn and practical experiences with the technology it can be said that the SVG-extension of the whiteboard has brought forth an easily usable web content management system. The system combines everyday suitability and innovation and marks an important step towards a knowledge and working space that can be structured graphically in any desired way.

Bibliography

[www]
http://www.mecxpert.de/svg/slider.html
[www]
http://www.w3.org/TR/SVG/
[Büse, D.]
Konzeption und prototypische Umsetzung eines Shared Whiteboard für eine kooperationsunterstützende Lernumgebung, November 2001
[Hampel, T.]
Virtuelle Wissensräume. – Ein Ansatz für die kooperative Wissensorganisation, Universität Paderborn, Fachbereich 17 – Informatik, Dissertation, März 2002.
[Hampel, T., Keil-Slawik, R., Selke, H]
Verteilte Wissensorganisation mit Semantischen Räumen (Distributed Knowledge Organization with Semantic Spaces) i-com: Zeitschrift für interaktive und kooperative Medien, 4(1), 26–33.
[Hampel, T., Keil-Slawik, R.]
Structuring Information in a Team – Distributed Knowledge Management in Cooperative Learning Environments. In: ACM Journal of Educational Resources in Computing 1(2) 2002, 1–27.

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