Saving and sharing design maps in a browser friendly format

This is an update on work towards exporting learning designs in the SVG format (W3C SVG Working Group, 2011b), and sharing them via e-mail, or by uploading the SVG file to a web site. It builds on earlier posts, and includes some of the points I have made in those, but in  more coherent way. This ‘save as SVG’ functionality will be included in the next release of CompendiumLD.
I describe the motivation for this work, include a few notes about SVG technology , describe the SVG code structure for design maps, describe how linked resources aree handled in CompendiumLD’s SVG output, and give an interactive example. There’s also some details about the SVG code structure for the View Pane; these are included in case for those wo might want to manipulate the images.

Motivation

The motivation for this is to improve the way that CompendiumLD maps can be shared, by

1. Reducing the effort required by users to share interactive maps
   Users can save an SVG file from CompendiumLD. By copying this single file to their own web site, or to a file sharing service such as Dropbox , or by e-mailing the file, an interactive version of nested designs and maps make be shared with other people. The only technical requirement to view and interact with the SVG is a recent browser.
2. Facilitating the embedding of maps in web pages
   The SVG files produced by CompendiumLD include a link which pops-up HTML code, which if copied and pasted into a web page, will embed the interactive SVG map in that page (see section ‘SVG code structure for design maps’ for an image showing the position of the embed link), and the interactive example.
3. Using a file format that other applications can work with
   SVG files may be edited by desktop applications such as CorelDraw or Adobe Illustrator, web applications such as SVG-Edit, and there are several code libraries for developing web applications which include facilities for SVG manipulation.

SVG technology

The technology I have used is the W3C’s Scalable Vector Graphics (SVG) format. SVG seemed an obvious place to start because it is a format designed for 2 dimensional graphics, and almost all browsers now display SVG content, and numerous other applications can open and edit SVG files (including some web based tools).

This quote from the W3C’s site summaries some of the power that SVG offers

“SVG allows for three types of graphic objects: vector graphic shapes (e.g., paths consisting of straight lines and curves), images and text. Graphical objects can be grouped, styled, transformed and composited into previously rendered objects. ……..SVG drawings can be interactive and dynamic”  (W3C SVG Working Group, 2011b).

SVG also supports supporting zooming, panning and scripting and other functionality that encouraged us explore it in relation to interactive maps of learning activities. This exploration has resulted in the definition of an SVG file structure for encoding learning design maps. As SVG is a very flexible format, images with the same visual appearance and interactivity may be achieved encoded using many different SVG elements and structures. Because of this, I have put some thought into the structure of SVG code that CompendiumLD produces, as this  will facilitate its extension and use as, for example, the basis for a browser based learning design editor.

SVG code structure for design maps

This structure is presented as a set of guidelines for encoding design maps in SVG. As the same visual appearance can be achieved using many variations in SVG coding, these guidelines have been developed with the aim of delivering high quality in the rendered image, coupled with a desire to split code specifying the semantics of the map content from code specifying the maps visual appearance and interactivity. Reasons for wanting to achieve this split of semantics from appearance include

• to facilitate the changes in node and link appearance, e.g. changes to node stencils and changes made interactively
• to make text in the maps searchable
• to provide a framework for development of a browser based editor.

Note that these are guidelines, not a formal DTD or schema: CompendiumLD generates SVG content that both conforms to the W3C SVG DTD and that follows our guidelines.

The structure of a SVG interactive image that CompendiumLD generates is composed of six components. Four of these components are generated by CompendiumLD when then user selects the SVG export option. These components represent the map data and are stored in the SVG file that CompendiumLD generates; three of these four components are panes which make up the window which the user interacts with, the other is a set of definitions of icons and other graphic elements. The remaining two components are referenced by the SVG file, but are stored externally, on the CompendiumLD website . One of these components contains the CSS styles that control the look of the SVG image, the other the Javascript code which implements the interactive behaviour of the image. The six components are:

1. A series of definitions of graphic elements including the node icons (theses are contained within the SVG file)
   Each icon is defined as a group of SVG elements in the section at the beginning of the SVG file. Although the SVG specification allows icon definitions implemented in a element to exist in an external file, only the Firefox and Opera browsers currently support this feature. For this reason Ihave included them in the main file, although it would be advantageous if they could be external.
2. Code which specifies the contents of the maps in the “View Pane” (also contained within the SVG file).
   This includes SVG code to specify where particular nodes should be positioned on the SVG canvas, the text and other adornments for each node, and inks between nodes. All the elements in this component are contained within an SVG group element, which is called the ViewPane group (see picture of structure ).
3. Code which specifies the content of a navigation pane (also contained within the SVG file).
   If the CompendiumLD design or map being exported contains sub-maps, it is a hierarchy of maps within maps. The navigation pane allows the user to navigate between the map levels (see picture of structure).
4. Code which specifies the content of a help pane (also contained within the SVG file).
   The help pane (see picture of structure ) contains links to documentation about CompendiumLD, to embed code for the design or map, to download the map, and to show the map full screen
5. Styling information for nodes and links (contained within a CSS file linked to from the SVG file)
   The SVG file generated by CompendiumLD contains a link to an external CSS file located on the CompendiumLD web site. This CSS file contains definitions of styles for text and graphic elements that are included in the view pane, help pane and navigation pane.
6. Scripts specifying interactivity (contained within a Javascript file linked to from the SVG file)
   The SVG file generated by CompendiumLD contains a link to a Javascript file which implements the behaviour of the elements that are included in the view pane, help pane and navigation pane.

The structure is shown in the image below.

The structure of the panes within a CompendiumLD SVG interactive map window

Handling linked resources in CompendiumLD’s SVG output

Resources such as Word documents, PDFs, and other file types may be included in CompendiumLD maps. Typically, the user drags and drops the file of interest from their file manager or finder window onto the CompendiumLD working area. CompendiumLD then creates an icon representing the file, and stores a link to the file so that if the user double clicks on the icon the file is opened in the relevant application (e.g. Word for .doc files, PowerPoint for .ppt files etc.).
However, if the user creates an SVG file and shares that either via e-mail or via the web, any links to local files on the users machine will not work. We therefore recommend that if aim is to share designs with embedded resources that the resources are stored in the cloud. Note that this does not require the resources to be publically accessible, they can still be protected by passwords and visible only to a limited audience. By taking this approach, the control of access to resources in a map can be handled on a resource by resource basis,; the security and privacy of each resource will depend on where it is located on the web. At one extreme on a designer might link only to open educational resources so all the resources will be freely accessible to anyone using the map. At the other extreme, all the resources may be password protected, e.g. in an institutional VLE.

Details about the SVG code structure for the View Pane

The View Pane is encoded as a SVG group element with an identifier “ViewPane”. Each map is encoded as a child group of this View Pane group. The visibility of a map is controlled by its “display” attribute. Initially the top level map is visible, so the value of the display attribute for this map is set to “inline” whilst the value of the display attribute for all other maps in the file is set to “none”.

Each “mapview” group can contain group elements which represent nodes and links. Each node group has a class attribute the value of which is set to the node type e.g. “reference”, “position”, “activity”, “map” etc.

Example

The embedded image shown here was generated using the latest beta version of CompendiumLD. Just move your mouse over it, and click away. Note that on an ipad, you can only click through to lower level maps via the naviagtion panel (it’s on the to do list to fix this).

Using my initial embed code there was an issue with the appearance of the image in Safari in that it the image appeared at full zoom within the embedded window, which meeant that the full image is not visible (this post illustrates the problem). This was only critical on the iPad’s iOS interface becuase on the iOS version of Safari you can not scroll up and down or left and right, whereas you can with Mac OS and Windows versions of Safari. Thanks to Christoph Henkelmann for a nice set of instructions on how to achieve this.

Still to do

• add onTouch event handlers so the maps works on iPads and other tablets.
• Other features to be aded as tsting progresses