A test in learning widgets

In order to explore how widgets can work in teaching and learning practice, I’ve been blue-petering a one-off formative assessment widget. That little exercise uncovers a couple of interesting issues to do with usability, security and pedagogy.



  • Google docs account
  • Sproutbuilder.com account
  • Mediawiki account with friendly administrator
  • Moodle installation with administrator access
  • (optional) iGoogle account, plain html site, Apple Dashboard, Windows Vista Sidebar, etc.

Take the Google docs account, and create a new spreadsheet. Rustle up a form from the toolbar; you have a choice between simple text, paragraph text, multiple choice, checkboxes, choose from a list and a scale. The questions will be added as columns to the first sheet. To calculate marks from the returns, use sheet 2 (the answers from the form will brutally overwrite anything on sheet 1). Refer to the cells in sheet 1 from the formulae in sheet 2. Finish with inserting widgets or charts that sum up your calculations. Send out the form via email, and let the sheet stew.

Google widget

In the mean time, soften up your mediawiki instance by asking your friendly administrator to allow img and object tags in pages. Make sure that the wiki isn’t very public, or you might get burned. To embed the form, go to sproutbuilder.com, and create a widget with the google form as content. Publish the sprout, and copy the object tag code, and trim off the single pixel image code on the end. Stick the object tag in the wiki, et voila.

To display the results, go to the chart in the google spreadsheet you prepared earlier, and publish it. Stir the resulting img tag you will be presented with into the wiki, and enjoy.

The outline for a Moodle instance is fairly similar, but allows greater freedom in what gets mixed in, where- provided you have administrator privileges. The form widget, for example, can be called directly in the iframe Google provides, which can be put into a Moodle html block. Likewise, results gadgets can be stuck in an Moodle html block as the javascript concoction Google dispenses.

Usability and security

As the recipe indicates, the deployment of widgets could be much easier. Getting rid of the copying and pasting of gnarly bits of code is only a minor aspect of this issue; security is the much bigger aspect. The hacking of the mediawiki instance is a tad questionable from that point of view, even if the wiki isn’t open to all miscreants on the web. There is a mediawiki extension that takes care of the trusting and embedding of widgets, but it doesn’t look particularly easy to use.

Much the same goes for deploying widgets in a Moodle instance, even if Moodle’s more fine-grained controls over who has which privileges over what, makes things rather easier. I had a quick look at a web platform like Facebook, and couldn’t find a way in there for my gadgets at all. A lame list of my Google documents was as far as it went.

What’s required here, IMHO, is plug-ins to these web apps that allow administrators to set trusted domains of origin for widgets. That way, regular users can stick in homebrew and pre-packaged widgets from these trusted domains into their favourite platforms without stuffing up security.

When inserting the assessment widget into the VLE, it also struck me that it wasn’t offering a whole lot more functionality than was already there in Moodle. I can imagine that using the Moodle question forms is easier for some people than wrangling spreadsheet formulae too. Still, there are important advantages of using a web app like Google docs or Zoho. Most importantly, the fact that it allows learners and teachers to pick their favourite tools to a common environment. But that does presuppose that deploying the various channels in and out of the docs web app is easy.


As is usual with a newly found hammer, you start looking for nails that may or may not be there. My first effort (Gadgets and mashups 101, log in as guest) therefore resulted in the shiniest widgets piled on top of each other. There is no indication of the right answer on submission, and the fact that the scores of everyone is plain to see, may not have been the best way to approach the learning activity, though.

The second effort was better, I feel (Gadgets and mashups 102, log in as guest). In this version, there is at least some feedback on submission, and an indication of which questions people struggled with, on average. Even so, using email or a link directly to the form on Google may be better still, with just the average score on each question as a gadget, and a list of respondents just for the teacher.

The spreadsheet can be viewed on Google docs.

You can see what the widgets look like in mediawiki on the CETIS wiki.

2 thoughts on “A test in learning widgets

  1. Pingback: Widgets, web 2.0 and learning design @ CETIS08 | Sheila’s work blog

  2. Hi Wilbert,

    Have you made the code that you used to get the Moodle activity available anywhere? I would be interested in checking it up.

    It pays off to go one level higher. To write widgets in a way that they can easily be exported into a google widget…. but can also be integrated in other environments if suitable. We live in a rapidly changing world, where new devices and new interactions emerge rapidly.

    I have given it a shot with the widgeds projects – http://widgeds.wikispaces.com/. Widgeds can potentially be integrated in any CMS that accepts iframe embeds (Moodle, Mahara, wikispaces, google gadgets embedded in spreadsheets), published as standalone activities on the cloud (dropbox account, google gadgets on a iSite) or any offline device application. It’s the very early days (I have been thinking about the problem for some years but committed full time to it only recently). Feedback welcome.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>