Because a bit of transparency is a Good Thing, I thought I'd put our for JISC's dev8d 'developer decatholon' submission online.
Name of team: Three Lazy Geeks
Names of team members: Ian Ibbotson, Mia Ridge, Peter Sefton.
Name of prototype: "LazyLecturer" - a tool to ease the collection and aggregation of internet resources into deliverable learning resources.
Tags for prototype: LazyLecturer LearningObjects ResourceAggregation LOM ContentDisaggregation ORE reuse socialbookmarking recommendationengines
Short description of prototype: LazyLecturer is essentially a tool which assists teaching staff in collecting and assembling learning objects from network accessible resources.
From the lecturers' point of view, the process involves 'shopping' for online resources, using the LazyLecturer bookmarklet to tag possible resources as they look for material. During the 'cooking' process, they can confirm their selection of resources before the application downloads and inserts them into a presentation document. They can prepare their slides as usual, organising and adding additional text and resources before 'serving' their presentation to their audience. Finally, they can 'save and share' their recipe - generating a list of resources used with associated attribution or citation data, and depositing their final resource.
In automating the process LazyLecturer starts to address deeper issues in the construction of reusable learning objects, and of learner engagement. Teaching staff are freed from the burden of attribution of images and other internet based resources which may compose their presentations.
A lecturer having used LazyLecturer will have created an aggregate learning object which will also available as a uniquely identifiable set of bookmarks in the social bookmarking web application delicious.com. Moreover, those resources are conceptually part of a hierarchically arranged set of delicious tags which could form a unified set of atomic resources used as components in the assembly of presentations for a taught course. From this, learners are able to serendipitously discover relationships and citations from referenced resources. Aggregated tags can be used to recommend similar resources discovered by other delicious users.
The prime goal of LazyLecturer is to ease the construction of learning objects, but in doing so it opens the door to content disaggregation and transparent reuse of learning materials.
'LazyLecturer' is a working title - as programmers, we consider laziness a virtue if it drives one to work hard in the short term to avoid more work in the future.
The prototype created:
Problems addressed: For teaching staff, the most immediate and tangible benefit is trivial assembly of reusable learning resources into a composite resource.
For developers: We see many touch points with existing systems, for example, automatically registering presentations in VLE systems, automated deposit of resources where required, alerting of the presence of new resources. There are many, many integration points where this tool could be used to orchestrate other services in the learning delivery process.
We see one of the real strengths of LazyLecturer being that it addresses and delivers a simple teaching need, whilst transparently moving towards a reusable / open learning objects framework with little or no extra input on the part of teaching staff. In fact the teaching role is made easier not harder by integrating with this new tool in this new environment. It also encourages behaviours that benefit the wider organisation.
How the prize money will be used to improve the prototype: In the original prototyping phase we constructed bookmarklets, a Drupal-based web service, and extensions to 'The Integrated Content Environment' (ICE) (http://ice.usq.edu.au/) for constructing learning objects based on a given delicious tags.
The prototype is purely "Happy Path" and would need much work to become a rounded system. Specifically the first phase of development would need to address production issues such as per-agent profiles for entities such as institutions, departments, courses, modules and lectures. This would allow the web service to pre-populate much of the information needed to interrogate and assemble a specific learning resource based on specific needs. Our prototype does not address the use of internal resources available only on local or networked drives.
We would like to improve the bookmarklet, and augment the "Selection" process with profile information from the web service. We need to design a very user-friendly solution to resolve issues around delicious' use of HTTP-auth and integration with either a central delicious account or helping people work with their existing accounts. We would also like to consider integration with Zotero, but initial investigation suggests this requires some coordination with the Zotero development team that would fall outside the scope of this project.
Much work could be done on the "Cooking" or "Assembly" phase where resources are collected from tag-sets and learning objects constructed. The Django/Google app engine web service makes extensive use of the pydelicious library. We found authentication issues between the Google app engine and Delicious API when deploying the project, and are talking with pydelicious developers about the problems (outside the scope of #dev8D, but good community building all the same) and how they can be addressed in the Google app engine environment. In the meantime, we have been working with a service deployed locally at http://office.k-int.com:8080/ and http://office.k-int.com:8080/select/
A particular area of interest was construction of other object types. Initially, PowerPoint represented the requirement from our user, however, we quickly realised the potential for other learning object types, LOM descriptions, Common Cartridge assembly items and many other learning formats. We also quickly established the possibilities of integration with an API for JISC Transcoder to automatically re-package and deposit the constructed resource in multiple back-end repositories using the SWORD API.
Our usability testing amongst friends and colleagues also make it clear that usability testing to ensure the use of language, instructions and processes is as easy to use as possible would be vital. Given the huge range in technical skills amongst teaching staff, we want to make the process seem as un-technical as possible, possibly following existing online metaphors and UIs to take advantage of existing knowledge of related applications. The paper prototypes were tested by a number of colleagues and academic friends for usability and validation of the core concept. The initial responses have been very positive and have validated our understanding of the underlying processes.
Link to screencast of prototype: http://www.youtube.com/watch?v=OLqE9D5dW7U
(We apologise for the low volume on our screencast, but Pete is currently in the air somewhere over Australia so we can't re-record it before the submission deadline. Also, the screencast doesn't explain that our sample user is a vet - this will explain the references to dead cats!)
Links to other artefacts that influence the creation of the prototype (frameworks, software, etc): The code for the projects components can be found at http://github.com/ianibo/dev8d/tree/master (Sorry it's github rather than dev8d code lib, happy to copy code to dev8d repo as needed, we had problems with wireless access briefly and git let us work a little easier locally)
The code for the ICE plugins which assemble the bookmarks into a reusable learning object will be uploaded to GoogleCode or the github repository within the next few days.
Here are some photographs of our paper prototypes and other docs: http://www.flickr.com/photos/_mia/sets/72157614023680652/
The link for the bookmarklet is here: http://miaridge.com/projects/lazylecturer/
Here is the github page showing the readme for building: http://github.com/ianibo/dev8d/tree/620d13677af7421f697558923db08a79bba1f33b/LazyLecturer