Until recently I had beeen using Dropbox, but it now produces a ‘share link’ usig https (e.g. https://www.dropbox.com/s/kjnmthom7qny129/sdfds.svg ) instead of the http link it used to. This seems to be because DropBox have changed the way users can share files (see https://www.dropbox.com/help/16/en), forcing folk to visit the shared page, then download the file that has been shared. I.e. it’s a two click process rather than the one click process that was possible with the public folder. Also the download link (e.g. https://dl.dropbox.com/s/kjnmthom7qny129/sdfds.svg?dl=1) does waht it says i./e. downloads the file to your machine, whereas what I want is to allow people to view it online (you can do this by thaking the ?dl=1 off the end of the URL to produce https://dl.dropbox.com/s/kjnmthom7qny129/sdfds.svg but that’s a step too far for easy sharing for me (and, I guess, other users ).

So I’ve begun to look at other options. The one that looks appealing so far is Ubuntu one. Ubuntu one has clients for Windows, Mac, Android, iOS, and a web interface so might be the best sollution since DropBox now seems to have stopped allowing folk to share files in a truly open fashion.
I have also looked at a couple of other options so far, i.e. Wuala and Google drive (Docs as was). Google drive will not disply a SVG file (“Sorry, we are unable to generate a view of the document at this time. Please try again later” – https://docs.google.com/file/d/0B433yeYVgtlaRTJTS3lTeW1UdTQ/edit).
For Wuala there are similar problems to DropBox in that the default share link forces a download e.g. http://content.wuala.com/contents/andrew_x/Documents/CompendiumLD/sdfds.svg?dl=1, though as with Dropbox this can be avoded through editing the link Wuala generates and removing the ?dl=1 parameter: http://content.wuala.com/contents/andrew_x/Documents/CompendiumLD/sdfds.svg.

So, at the moment, Ubuntu One is my preferred option (thanks’s to Nick for prompting me to take a look at it). Here’s an example:

Old way (still not sure why this does not work in Safari i.e. I can’t see a relevant bug report so perhaps my coding is wrong)

Old way with px specified instead of assumed as units of the object tag:

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

In my code, the ‘onclick’ attribute is attached to a <use> element, so I naiively assumed it would pick up any clicks on whatever the the <use> referred to as a whole. In this case, the <use> referred to the CompendiumLD icon definition. This is a SVG group <g> containing lots of other SVG elements

Teg Lansdell (and Jonathan Fine) helped me solve the problem by pointing me towards the ‘evt.target and evt.currentTarget‘ section in the ‘Dynamic SVG and JavaScript‘ of W3C’s working draft ‘An SVG Primer for Today’s Browsers‘. Here are the relevant paragraphs (the …. indicates that I’ve cut some text out):

“Likewise, we may assign an event handler to the entire group as in <g onclick=”doIt()”>. This generally works well, unless we try to identify the group itself that was clicked on. That is because even though an event handler is assigned to the group, the target of the event ends up being the specific element within the group that actually received the event”.

“The answer to the above issue lies with evt.currentTarget. Its purpose,…….. is to find the superordinate object containing evt.target, specifically the group or other container to which the event listener has been assigned”.

I ran into problems because I used Firefox 9.0.1  for my initial tests, and it returns the <use> element for both currentTarget and target However, Chrome (and Safari) return the <use> element for currentTarget, but an ‘SVGElementInstance’ for ‘target’. Now in the ‘Document Structure‘ section of the SVG 1.1 (Second Edition)’ W3C recommendation it says “For each ‘use’ element, the SVG DOM maintains a shadow tree (the “instance tree”) of objects of type SVGElementInstance“. In then goes on to explain how group elements are handled, using this example

“If the ‘use’ element references a ‘g’ which contains two ‘rect’ elements, then the instance tree contains three SVGElementInstance objects, a root SVGElementInstance object whose correspondingElement is the SVGGElement object for the ‘g’, and then two child SVGElementInstance objects, each of which has its correspondingElement that is an SVGRectElement object”.

To get the ‘real’ element related to a SVGElementinstance, use the ‘correspondingElement’ property, eg.

actualElement = svgElementInstance.correspondingElement;

In conclusion, I’m going to use the ‘currentTarget’ for this particular bit of code in the expectation (and hope)  that it will work across most modrn browsers. A quick check of Safari, Chrome, Firefox and IE9 shows that it appears to for those browsers.

However, I’m perturbed that Firefox seems to be processing the SVG and Javascript differently, and incorrectly?

1 A picture showing the relationships between the learning outcomes for chapter 3 of the Y162 course book, and those for the draft online version (nb. this picture was for a draft online version as of late July 2011).

2 A picture showing relationships between some concepts that the course is intended to teach students, with the learning outcomes that are presented to students.

Web 2.0 scientific calculator

The ‘Starting with Maths’ text book contains 17 mentions of the word ‘tutor’ in its 7 chapters.  The first 8 of these occur within the first chapter, and all emphasise that the student should ask their tutor for help if they”re having difficulty understanding any of the concepts. For example

“If you are still puzzled by it, try discussing the problem with someone else or your tutor”.

The strategy of discussing difficult concepts, skills, or methods is emphasised throughout the book.  When this material is transformed into an open educational resource, how could this tutorial support be prvided?  On OpenLearn Learning clubs and  forums (e.g. the Maths & stats forum) allow learners to connect with other learnerrs.  For the the American Universities involved in this project, is there another way that learners can get support? I note taht the only one of the 7 chapters which does not refer to a tutor is chapter 6 ‘Working with data’: I wonder if there’s anything particularly different about the material in this chapter?

During our meeting Guy sketched options for the content development process as we talked:

One important decisiosn that needs to be taken quickly is who will do the editing/content preparation for the first release. Options include an OU media person, or some one from the US college(s). There are pros and cons for both, and hopefully whichever is choosen there’ll be some info and skills exchange that takes place during the content preparation process. To move things forward,
a meeting including both tech and management folk from all involved parties (inc OU) will be set up for next week

(Thanks to bignoseduglyguy for this picture entitled “Da VInci Arched Bridge – success!”).

My role in the initial stages is to look at the design of the material, to work towards a structure or template for OERs for the project,  and to understand and design the user experience we should be aiming for.  This could should?) involve enhancing existing material rather than creating stuff from scratch. The material structure or template could include intro, learning outcmes, activities, practice material. There is aslo a need for pre and post-assessment, but these might be better delivered as seperate OERs.

The units we’ll be adapting include Y165 “Learning to change” and Y162 “Starting with Maths”.  Both Y165 and Y162 are in the process of being released as an OER. It’s an openings module, intended to build learners confidence, before they move on to other study with the OU. It includes very little algebra, so for the purposes of B2S it might be necessary to add in smome material that deals with algebra, e.g. from M125 or via OERs originating from other sources.  There’s an OU ‘Design team’ for the project which includes Guy Barret (lead tech developer from LTS) and Hilary Holmes (senior lecture from MCT, author onM125?). Guy is managing the B2S area of the OpenLearn site (that should be labspace? – need to check).

IET’s role in prroject (and hence mine) includes

• making it work!
• evaluating, gathering evidence, working it if/how it can be repeatted

Elipda’s offered to contribute to the researchj methodology, Simon will bring in his knowldege from the OpenEd project.

Issues – units eg. £ vs $, metric measures.

Bear in mind [points made by  Dave Pritchard at the OCW conference (as blogged by Parick) and summarised by Patrick: teachers love to teach theory, people love to learn practice. Bear this in mind when developing openings  materials!

Deadline to get stuff up live inLabspace  is 1st September 2011.

Labspace will get the RAP updates but with a delay (not sure how long a delay).

Over the next couplke of weeks I need to work with Guy, towrds a template (am confused by this term).

Ormond Simpson is involved – hee help develop Learning to learn and Learning to change modules,  as an external consultant on Y165.

Link Code

Here is the code used to draw the link between the activity and learning outcome nodes:

The link is coded as a group (<g>) of elements, includinga title and a description. In this example, the rendering of the link graphic (i.e. the arrow between the nodes) is coded as a <line> element. However, it could be coded as a <path>: SVG paths can be any arbitrary line, arc or curve. The <desc> element holds the ids of the nodes that the link connects between that could be used by both people and algoriths processing the map code. The <title> element is a title intended primarily for human consumption. This group of elements is identified as being a ‘link’ by the class atribute i.e. the code:
<g id=”link1″ class=”link”>.

Displaying transclusions

The ’2′ at the bottom right hand orner of the learning ourcome node indicates that this node appears in 2 maps; it is transcluded to 2 maps. If you hover your mouse over the ’2′ , you wuill see the titles of the two maps that this node appears in. One is ‘This map’, the is a link to the other map that the same node appears in.

I’ll add some notes about the coding of the transclusions later.

Finally, a note to myself. To make these SVG maps it editable in Inkscape, the CSS style information must be embedded in the file, not linked externally.

This general category of ‘visual representation of linked ideas’ includes any sort of concept map (including maps produced by Compendium the application on which CompendiumLD is based). The examples I give are CompendiumLD maps because CompendiumLD is the application I’ve been working on, but I have made some notes about how the ideas I present are applicable to other applications.

The post is broken into chunks: motivation, an example, some notes about the coding, a bit about mini previews of maps, and some thoughts on opportunities, possibilities and prerequisites.

Motivation

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

1. facilitating the embedding of maps in web pages
2. using a file format that other applications can work with.

The technology I’ve used is the W3C’s Scaleable 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” (about SVG). It supports supporting zooming, panning and scripting and a whole host of other functionality that encouraged me to explore it in relation to maps of learning activities.

Example

Here is an example of a CompendiumLD activity map coded in SVG and embedded into the page using the HTML <object> tag. Note that you will need a browser that can display SVG to see this (fyi I’ve jotted some notes about SVG support in browsers and other applications).

This example is very basic. It contains just two nodes and one link to keep the SVG code simple as I have written it by hand as a way of exploring the features that SVG offers, and to think about the way that CompendiumLD nodes and links could be encoded in SVG. There is no reason why these SVG renderings could not be generated by an application such as CompendiumLD if or when it is decided that this would be a useful thing to do (e.g. by the OULDI and/or other projects).

This map features two nodes from the OULDI learning design stencil, an activity
and a learning outcome
, connected by a link. If you hover your mouse over the asterisk (*) in the example a window should pop up displaying further details about the learning activity. If you click on the learning activity node you will see a map of the learning activity itself within the same window fragment. You can also see how the maps will appear when displayed at high or low levels of magnification by zooming in or out (e.g. use ctrl ++ to zoom in , ctrl — to zoom out). One of the things I’m thinking about doing is to pop up and mini preview of a map nodes contents when you hover the mouse over the node, allowing you to glimpse its contents before deciding whether to click and explore it in detail (more on mini previews).

CompendiumLD and Compendium already offer ways to share map data (via the Compendium XML format or SQL), and interactive (but not editable) web renderings of maps (see ‘Middle east role play’ example, or other examples). When coding the SVG version of the CompendiumLD maps I have tried to keep the code related to the semantics of the map separate from code which describes the visual style One of the ways SVG facilitates this is by enabling the look of elements to be specified via CSS. This is work in progress, and I have not been entirely successful so far, but here is an explanation of my coding and thinking.

By the way, I can see there’s an issue with the text layout when this example is rendered by the Chrome browser in that the first line of text for the task node is left aligned with node, rather than being centred on node. I’m not sure why this has occurred, could be my SVG or CSS, could be the Chrome’s rendering engine, it looks fine in other browsers. I will investigate.

Coding

The SVG rendering I have created consist of four components

1. A series of definitions stating what the nodes should look like (theses are contained within the SVG file)
   Each icon is defined as a group <g> of SVG elements in the <defs> section at the beginning of the SVG file.
2. Code which specifies the contents of the map (also contained within the SVG file).
   This includes where particular nodes should be positioned on the SVG canvas, the text and other adornments for each node, links between nodes. I could have used XML from other namespaces (e.g. the Compendium XML DTD) to include Compendium specific information. I have avoided doing this with the intention that all the information that Compendium or CompendiumLD needs can be encoded using SVG, meaning that a user (e.g. a programmer) only needs to understand SVG to make use of the file. This decision needs further thought as I progress with these experiments!
3. Styling information for nodes and links (contained within a CSS file linked to from the SVG file)
4. Scripts specifying interactivity (contained within a Javascript file linked to from the SVG file)

Here is a fragment of code from the first SVG file shown in the example i.e. this SVG code, annotated to further explain my thinking, and it shows some of the things I’m not sure about.

The idea which I think is applicable to other idea and concept mapping applications is the use of group elements and class attributes to hold the semantic information about specific components of a map. In the way I have used it in the code fragment above, the class attribute enables scripts to find the data related to specific concepts (e.g. activities or learning outcomes) in the case of CompendiumLD maps, because the relevant information is an a group element (<g>) with its class attribute set to ‘activity’ (see the code for the activity group or for the learning outcome group).

Mini previews

A few paragraphs back I mentioned the idea of mini previews i.e. miniature versions of maps that pop up when a user hovers their mouse over a map node. Here is an example of the kind of mini preview that could be generated for a relatively large and complex map (here’s the full size map).

I generated this from CompendiumLD using Apache’s Java SVG toolkit, Batik in an initial experiment I did in July 2010. The SVG produced by Batik looks fine when rendered by a user agent such as a browser, but it’s structure is not, e.g. the groupings it produced do not map to CompendiumLD’s semantics i.e. the nodes and links. However, to generate the SVG of this I took the simplest route I could which is essentially ‘painting’ the map as SVG using Batik. Further investigation is required to exploit Batik’s capabilities given that it seems to support most of SVG 1.1.

Opportunities, possibilities and prerequisites

The SVG format is designed for describing 2-D graphics, so any linked-node style of map should be realisable using SVG, including things like curved links which are introduced in Compendium 2.0 beta and of course raster images can be included in SVG (all the nodes in the mini preview example are raster images). And of course, SVG can be edited using a variety of tools, albeit general purpose SVG tools may not preserve the semantic attributes in a CompendiumLD SVG file, but would at least allow people to use an off the shelf (or web) tool that they’re familiar with. General purpose graphic design apps that can manipulate SVG will not offer all the functions that Compendium or CompendiumLD do (e.g. transclusions), but will offer a way for people to manipulate maps without having to install or learn how to use Compendium/CompendiumLD.

As my examples show, once a SVG rendering of a map (or a set of nested maps) exists, it is possible to embed it into a web page at different sizes, and to do user friendly stuff like small versions within the page and full screen versions, similar to the way that Slideshare slideshows and Youtube videos may be be embedded. However, the examples I’ve produced so far are either hand written with ‘good’ semantic structure (example) or program generated with little or no semantic structure (mini preview example). So, if this SVG approach is to be used, the first step needed is some more work on the structure of the SVG to make sure most user reqs are covered, probably via a mixture of hand coding and prototype program generation of example maps to get feedback on (the same goes for the CSS styling, scripts, and SVG definitions i.e. work on these four components). Note, this jQuery SVG plugin might be useful for the scripting.

Then there needs to be a way of making SVG versions of maps available, so that there is a source to be embedded. A relatively quick way would be to build on the shared MySql database already provided by Compendium and CompendiumLD (see Collaborative Compendium). This approach would require Java coding to automatically generate the SVG for each map, but use Compendium/CompendiumLD as the editing tool. I’m not sure, but a format like oEmbed might be useful to facilitate the embedding of nested SVG maps (more thought, playing around, and chats with Nick who has used oEmbed, needed).

Now some very brief thoughts about options requiring more effort e.g. a browser based editor. Use HTML5 (build on SVG edit code base?). Such an editor could ‘save’ locally to browser database, ‘publish’ to web site.

Notes about SVG support in browsers and other applications

The only current desktop browser that does not display SVG is Internet Explorer, but that will change when version 9 is released (summary of browser & plugin’s SVG capability as of 30/8/2101). If you are using IE9, make sure the brwoser mode and document mode are set to ‘IE9′ other wise you will not see the examples!

Note added on 15/9/2011 from SVG-developers mailing list:

"I think IE9 demands that you use a standards based DOCTYPE in the html in order
for iframe, object, embed etc to support SVG content".

For mobile devices, Apple’s iOS browser already handles SVG, and SVG support is here or coming for other mobile platforms (it’s coming in Android v3.0, and via Webkit for other platforms e.g. Blackberry, Symbian etc).

Desktop applications that can edit SVG include

• Inkscape (open source)
  well worth a try if you haven’t already imho, and also
• Adobe Illustrator
• CorelDraw.

Web based tools include SVG edit.