Hi Greg,
Thanks for this suggestion. I've had a quick look at these tools, and I can see value in them for an environment like LAMS. In an ideal world, we'd be able to easily drop them in and get maximum value from using them, but in reality this leads to some challenging integration issues that I discuss more generally below.
In terms of actual tools to add to LAMS in the near future, I'm keen to hear suggestions from the community. Personally I think there are still some simple general tools that we need to include in LAMS before we get to more specific examples like those you mention. Some of these simple general tools could be:
- A "Task Completion" tool, where an author can set one or more tasks that need to be completed (typically offline of in a software system outside of LAMS), and students click a checkbox when each task is completed. A teacher could then set a minimum number of tasks to be completed before a student can move on to the next LAMS activity. Another option could be that the student has to upload a file as part of checking the "completed" box. From another perspective, this tool could be very useful for RAMS (the eResearch version of LAMS) to allow users to indicate that a goal has been achieved. This "goal completion" tool could indicate true completion of a sequence in which people can cycle back through activities many times even after they've reached the final task (and hence are thought to have "finished" when in fact they are still debating in forums, etc)
- New features for the Voting tool to allow for ranking and related tasks, including features like the first Intel tool and the ideas Leanne mentions
- A tool that combines Q&A and Vote - many people have asked for a tool that allows students to put forward an answer to a Q&A, and then the next task uses all these answers as the choices for a group vote to see which answer gets the most support. This tool would used the new LAMS V2 ability to combine tools, as well as being a "packaged" example of passing data from one tool to another, which we are working on for V2.1
- A simple image gallery tool, which allows students to easily upload one or more images that are then viewable by the group. An optional add-on to this could be voting (similar to Q&A and voting above).
- Voice chat as an advanced option for the text chat tool (only enabled when appropriate by the author)
- A "backend database" half-tool that you can build Flash/Java Applets over the top of. The backend could store student progress or similar information sent to it by the client side Flash/Java Applet (see below for details).
We look forward to other suggestions! Others are already building interesting new tools, such as a scientific simulations tool under development at Oxford University.
In terms of the wider question of tool integration with LAMS, especially in relation to portfolio export, here are my thoughts on different ways to do this:
Simple URL link
The simplest "integration" option is just to link to external tools like this via a URL (could be via the URL option in Share Resources, or a URL link incorporated using the Rich Text Editor now in all LAMS V2 tools). A related advanced option would be to embed the external tool into a LAMS page via an iFrame. This approach could work for any tool that can live at the end of a URL, including the Intel tools (I think).
Pro: Easy to implement, no backend integration needed - allows LAMS users to try out these external tools with LAMS to see whether further integration would be worth the effort
Con: LAMS doesn't "know" anything about the external tool, so it can't record student data, can't provide a portfolio export, can't author directly through LAMS, etc; the student experience may be a bit clunky (different look and feel, maybe extra login screen, etc)
Simple integration using a LAMS "data storage" backend tool
A number of LAMS users have suggested a kind of "half tool" for LAMS which would have no front end, but would provide a backend with a standardised approach to data storage. This is particularly applicable to Flash tasks (and other client side tools, eg, Java Applets) that would like to save information about how a student has used them (eg, quizzes, multi-level games, these Intel tools). The benefit of this functionality is that you could allow students to leave the Flash task and come back later, and continue from where they were (because the system can save their position), instead of starting all over again (as happens with, for example, Learning Federation objects). The same feature could also help minimise student frustration with computer crashes (as they're past work/position would be stored). Even with short tasks this feature could be valuable, as you keep a record of the student's work (which could then potentially be part of a portfolio export as suugested). NB: the Flash task would have to be built to connect to this data storage backend tool (ideally through some standardised way of doing this that would not be LAMS specific, maybe IMS Shareable State Persistence?).
Pros: Allows Flash task to record student activities for later use or portfolio export; doesn't require Flash tool to "know" anything about LAMS other than the data storage interface; doesn't assume Flash tool is open source
Cons: Doesn't address authoring of the Flash task itself (and this might create problems for teacher sharing of a sequence that uses the Flash task, as authoring data for the Flash task might not be saved with the LAMS sequence file); Portfolio export may still need some work to ensure the recorded data is meaningful to a student (if presented raw) or is usable by the Flash task (if the Flash task itself is also exported, and then reads information from the Portfolio export package - instead of the server).
Open source tool integration with LAMS
If you can get the source code to tools like this, it would be possible to investigate how the code relates to the LAMS Tools Contract (this defines how Tools interact with the LAMS software - see http://wiki.lamsfoundation.org/display/lams/Tool+Contract ). Ideally you'd be able to do a mapping of the Authoring, Management (ie, Monitoring in LAMS) and Learner environment in the tool to the LAMS Tools Contract so that the tool could be directly integrated into LAMS as if it was a "LAMS tool". There are levels to which this can be done - for example, you might work out how to invoke the tool's authoring environment from LAMS Authoring, but you wouldn't assume it would have the same features or look an feel as the standard LAMS Tools Authoring template (although maybe you could create a backend mapping that used the LAMS Tool Authoring template for authoring, then it wrote the data out the backend to the external tool's own authoring approach).
The Portfolio Export content could also be more configurable using this approach.
Pros: Can use LAMS Tools contract for deeper integration; more configurable Portfolio Export
Cons: Requires a detailed technical analysis of external tool in relation to LAMS Tools contract, followed by some development to get the "mappings" right; Authoring look and feel might still be quite different
Rebuild tool concept from scratch in LAMS
Even when you can get the source code for a tool, it might be too much work to try to richly integrate it into LAMS compared to the task of rebuilding the tool from the ground up in LAMS itself. In this case, you'd write code in LAMS for a new tool based on the concepts, but not the code, of the external tool. This issue has a long history with LAMS - I suspect it is often easier to build a new tool from scratch (using existing LAMS tools as "reference code" to make this easier) than to try to do the mapping above. Looking at the Intel tools, I'd say this is quite likely for the (relatively simple) Visual Ranking tool; whereas the other two tools look "bigger" and so may have a better case for not starting from scratch. Hard to say with any certainty unless someone can look at the code.
Sorry for such a long reply, but this touches a much wider point that will be important for the future, so I thought I'd write up these wider thoughts.
Posted by James Dalziel
