Mapping mobile learning

During January and early February I helped run a field trial of an android app for  the MASELTOV project.  The app is know as the MApp (short for MASELTOV app), and the aim of the field trial was to answer some research questions about participants’ use of the app to support their cultural and language learning (there’s a a quick overview of the trial and a report that include some initial data analysis).

We have collected a huge amount of  data from participants’ phones during the 3 weeks of the trial, and having done some analysis of participants’ self reports of what they did I  am now startting to look at quantitative data collected from their phones. This includes identification of particular MApp services being used, and where and when they where being used.

So I’m straing to think about how best to preent this data, using maps, and sequences of maps over time, and my intial ideas are…….

  1. A map showing each participant’s use of various tools over a day.
    So will have 17 (participants) x 21 (days) maps = 357 maps.
    Each map would show use of a variety of services over time and space.
    * Aim: to understand each individual’s overall usage of the MApp
  2. A map showing use of a particular tool by all users over space and time
    E.g. for the forum tool, show where and when all participants are using it over a day (or longer?)
    * Aim: to inform devlopment of particular services through knowledge of their usage patterns
  3. A map to show locations that participants frequently access (particular) services
    * Aim: to compare with interview data, and to test our implicit assumptions
  4. A map to show services which are used when participants are on the move
    i.e. which service is being used, the mode of transport, and the journey undertaken.
    * Aim: to compare with interview data, to test our implicit assumptions, to see if there’s anything surprising occurring.

Some notes about processing the data

I expect that there will be fewer changes in location than there will be events related to services used. With this in mind

Loop through location events;

For each location

identify if service was used by comparing timestamp and duration of service with timestamp of location event



Posted in Uncategorized | Tagged , , | Leave a comment

Cloud storage options for sharing SVG (and other ) files

I’ve been looking at a few cloud storage providers, with a view to seeing which one(s) might be best (in terrms of usablity of client interface , and openess of access to files and data ) for sharing SVG files which reference and use Javascript. The motive is to find a provider which is easy to use both for the end user, and for Nick Freear‘s oEmbed service.

Until recently I had beeen using Dropbox, but it now produces a ‘share link’ usig https (e.g. ) instead of the http link it used to. This seems to be because DropBox have changed the way users can share files (see, 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. does what 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 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” –
For Wuala there are similar problems to DropBox in that the default share link forces a download e.g., though as with Dropbox this can be avoded through editing the link Wuala generates and removing the ?dl=1 parameter:

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:

Please noteYour browser can not display SVG so you will not see the interactive CompendiumLD map that should be shown here.To see the interactive map, please use a browser which displays SVG, e.g. Chrome, Firefox, Opera, Safari or Internet Explorer 9 and above.Thank you.

Posted in svg | 3 Comments

Temporary embed test

Another embedding test.

Please note
Your browser can not display SVG so you will not see the interactive CompendiumLD map that should be shown here.

To see the interactive map, please use a browser which displays SVG, e.g. Chrome, Firefox, Opera, Safari or Internet Explorer 9 and above.
Thank you.

Posted in Uncategorized | 1 Comment

Test of embedding SVG

Test of ways of embedding to keep whole image visible in embedded window across different browsers (following on from previous post).
New way using div to specify height and width (as suggested by Christoph Henkelmann and Erik Dahlström):

Your browser can not display SVG. Browsers which display SVG include Chrome, Firefox, Opera, Safari and Internet Explorer 9.

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)

Your browser can not display SVG. Browsers which display SVG include Chrome, Firefox, Opera, Safari and Internet Explorer 9.

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

Your browser can not display SVG. Browsers which display SVG include Chrome, Firefox, Opera, Safari and Internet Explorer 9.

Posted in Uncategorized | Tagged | 1 Comment

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.


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.

Schematic showing the structure of the panes within a CompendiumLD SVG interactive map window
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.


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).

Your browser can not display SVG. Browsers which display SVG include Chrome, Firefox, Opera, Safari and Internet Explorer 9.

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
Posted in compendium, svg | Tagged , , | 2 Comments

Capturing events on group elements in SVG

I’ve had some trouble with the SVG versions of CompendiumLD maps I’m (still) developing this week. The problem was occurring when I tried extracting data from a mouse click event, for mouse clicks on a CompendiumLD icon. It seems that because the icon is defined as a SVG group element (<g>) that the target of the event (i.e the click) is interpreted by some browser’s Javascript engine as being the group as a whole, and by others as being the specific SVG element within the group upon which the click actually occurred.

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 ‘ 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, 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?

Posted in Programming, svg | Tagged , | 3 Comments

Learning outcomes, concepts and media

Some quick notes about mapping relationshops between learning activitites, the media through which activities can be delivered, the concepts that  the activities are intended to teach, and the learning outcomes that are presented to students.

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.

Posted in compendium, learning design | Tagged | Leave a comment

Open Learning: Bridge to Success – reflections after meeting with Gary and Guy

The module Y162 “Starting with Maths” ‘ requires use of a scientific calculator. The course material includes a guide to the TI-30XA calculator which explains how to use it in the context of the module. Here is a picture of the course materials, just after I’d opened the package as delivered to students.
The Y162 course materials, just opened after delivery
If we’re opening up Y162, I think we’re going to need to provide alternatives to this specific calculator, including an online equivalent such as this one from

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:

Guy's sketch showing options for the content development process

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

Posted in learning design | Tagged , | 1 Comment

Open Learning: Bridge to Success – notes from first meeting

I’m starting to work on  the “Open Learning: Bridge to Success” (B2S) project, and had my first meeting with Gary (project manager) and Patrick (OU lead) today. These  are my notes.

Da VInci Arched Bridge - success! (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.

Posted in openlearn | Tagged , | 2 Comments

Coding Compendium / CompendiumLD links and transclusions in SVG

This post follows on from my last one, adding some thoughts about the way Compendium links can be encoded in SVG, a way that permits the links to be straight lines or any sor of arc or curve. There’s also a bit more scripting: a first go at handling links to transclusions of a node. This post includes svg code for the links and an example image.

Link Code

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

<!– Link actvity and learning outcome –>

<g id=”link1″ class=”link”>

<!– Use title to describe the link or human consumption, in the manner that the link label is used in Compendium and CompendiumLD. The desc element used to store the from and to nodes –>

<title>Link between learning outcome and activity</title>

<!– Use the <desc> element to specify the ids of the from and to nodes; could also state the node labels. –>

<desc>Link from node activity1 to node learningoutcomrome1</desc>

<line x1=”240″ y1=”116″ x2=”93″ y2=”116″ class=”link” marker-end=”url(#mArrow)”/>


<!– End of link –>

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.

Your browser can not display SVG. Browsers which display SVG include Chrome, Firefox, Opera, Safari and the beta version of Internet Explorer 9. I suggest you try one of these to view the examples.

Embed this map

(copy the code below and paste it into your web site (note this does not seem to work for some WordPress blogs, not sure why, perhaps a plugin is needed?):

<object style="border-style:solid;border-width:1em" data="" width="350" height="300" type="image/svg+xml">
Your browser can not display SVG. Browsers which display SVG include Chrome, Firefox, Opera, Safari and Internet Explorer 9.

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.

Posted in compendium, learning design | Tagged , , | 1 Comment