Forum .LRN Q&A: Using Xowiki from the Learning Design Player GRAIL
We are pondering a few changes in the Learning Design player in .LRN (package imsld) that I'd like to share with the rest of the community, specially with Gustaf. I also have a question about dependencies.
As of now, the player receives a Unit of Learning (zip file with material and and arbitrarily complex choreography of activities) and creates different "runs" or enactments of such unit. Until now, the resources (for the purpose of this discussion, HTML files) were stored in the CR. This hinders significantly the possibility of making small adjustments to the material. We're thinking on things such fixing typos, rewriting a paragraph, changing an image, etc.
The idea we implemented in a prototype (currently in HEAD) is to import all these resources in Xowiki when the UoL is loaded and allow the teaching staff to manipulate them through the Xowiki interface. We also have a variety of new scenarios in which students also edit and modify other resources, but they are irrelevant for the discussion.
The two issues that we encounter are:
1) If following this path, Imsld will have a strong dependency (as pointed by Gustaf and Emmanuelle) on Xowiki. The alternative would be make imsld sensitive to the presence of Xowiki and fall back to its previous behavior and using CR. What are the consequences if we opt for using only xowiki?
2) Resources are shown by the player through the use of 3 iframes: activity tree, environment and activity text. The last one is rendered using the xowiki interface, but it contains the main-site header and additional information that we would like to hide. Any suggestions on how to achieve such thing cleverly? I think the issue is how to use the functionality to edit pages but embedded in a more complex page (thus ruling the header/tail unnecessary).
Any feedback would be greatly appreciated.
It is very easy to create a form to edit HTML that is stored in the content repository. We do this in LORSM where you can edit HTML resources.
2. I agree with daveb regarding the ease of making it possible to edit HTML without adding xowiki.
3. Xowiki has not been tracking our efforts in accessibility and HTML validation, so use of it will make it more difficult to make IMS LD accessible.
Your addition to IMS-LD sounds very useful. When we worked with IMS-LD about two years, the major show stopper for our teachers was the inflexibility: doing an ex-ante design of a course and having a "player" which does not allow a teacher to make any changes in a running course is not the way professors in brick & mortar universities expect to interact with a learning environment. Most probably, distant universities have different situations and needs. So, any attempt to improve agility is the right way to go, we all know that a wiki offers more flexibility than just HTML editing.
My point of view on the 2 items:
1) i do not know any installation of dotlrn, which does not have xowiki installed. Not being part of the dotlrn core package was at least for me no reason to stop work on something i believe that is useful. The list of packages of what's included in dotlrn and dotlrn-extras is not fixed. If there is interest from the community to extend this list with xowiki/imsd or whatever, maybe the dotlrn consortium will got for it. I won't participate much in this discussion, since i have probably a biased opinion. I think Rocael und Nima have already put some ideas to the wish list https://openacs.org/xowiki/.LRN_2.5
2) Are you referring about the removal of the master-template in the iframe? You could pass to xowiki a different template file, e.g. like in
The view-links template is designed for adp-includes and is just returning the HTML snippet. It should work for most simple applications nicely. For an iframe, i would recommend to provide a custom adp file with an appropriate HTML head etc., such that e.g. page specific css files will continue to work.
So, any attempt to improve agility is the right way to go, we all know that a wiki offers more flexibility than just HTML editing.Yeah, but none of that flexibility fits into the IMS notion of what a course is, which is a set of resources and sequencing information, nothing more. The only thing that makes sense in that context is to be able to edit an existing resource.
If there is interest from the community to extend this list with xowiki/imsd or whatever, maybe the dotlrn consortium will got for it.We're in the last round of adopting accessibility requirements. Meeting those accessibility requirements is a prerequisite for considering xowiki for inclusion in .LRN.
For an iframe, i would recommend to provide a custom adp file with an appropriate HTML head etc., such that e.g. page specific css files will continue to work.IMS resources including HTML files should be standalone, so they can be created using standard course creation tools. The bare-naked HTML - including the HTML, HEAD and BODY tags included within - has to be returned directly with no wrapping by the LMS.
The aDeNu group (UNED) maintains 3 dotlrn sites, none of them has xowiki installed. We have to satisfy accessibility requirements and that's why we don't use it for now.
Note that imsld package is already in dotlrn-extras, it has been added for 2.3 IIRC.
I'm afraid that an automatic evaluation is not enought to guarantee accessibility. A manual revision by some accessibility expert is required.
I wouldn't say "horribly" inaccessible, but it needs some work.
As Olga said, validators are useful but not sufficient to guarantee the accessibility of one page. The "Cynthia says" report leaves blank for the checkpoints that need to be manually verified.
I'm no accessibility expert but a review of the page you mentionned shows a few issues (e.g.: tree doesn't show up when js is disabled, h1 used for the "registered users" box, use of blockquote to indent text, not enough difference in color for links - but that one probably comes from theme-zen 2.4.0, it has been fixed in 2.4.1-, keyboard only users and screenreaders would have to go through all the tree links before getting to the main content).
Anyhow, this is an example of xowiki displaying content, accessibility of the pages to insert and manage content would have to be reviewed too.
Having an accessible wiki would be a great contribution for the community. For this reason, although I have to deal with other commitments, I'm willing to help to address accessibility in xowiki. We can talk about it in Valencia if you'd like.
We use xowiki to produce learning content through the tool we call "content", using the template facility of xowiki makes it easy to concentrate on the content while leaving the layout and navigation features / controls to the application, so those are created dynamically. Also we value the policy feature to allow certain behaviors with the pages. Xowiki also allows to manipulate you the versions and diff, which is good. If any of those features among others are relevant to your needs, then you might consider using xowiki.
We use xowiki to produce learning content through the tool we call "content", using the template facility of xowiki makes it easy to concentrate on the content while leaving the layout and navigation features / controls to the application, so those are created dynamically. Also we value the policy feature to allow certain behaviors with the pages.But in an IMS (or SCORM) course these should be left to the player, using the semantic and sequencing controls that are part of IMS (or SCORM). Or are you telling us that you've written a real IMS content generation/editing tool based on xowiki?
The diff procedures are in acs-tcl
There is a plain old diff and an inline HTML diff.
Nobody claimed that xowiki is the only way to get "things into and out from the database" (use this phrase as a placeholder for the set of related features). No doubt that for some applications it might be simpler to do whatever they want without xowiki, but there are as well some applications where it is easier to achieve the desired behavior with xowiki. This is something an application developer has to decide.
util::html_diff -old "<a href='.'>x</a>" -new "<a href='.'>x</a>"
returns invalid HTML:
<a href='.'> x </span>
If you look at the code, it is clear why (see the final string map). The following trivial example leads to a tcl-error:
util::html_diff -old "ppp" -new "ppp xxx"
which is easy to fix. But nevertheless, I get certain doubts that this code is tested and in use by any application with HTML.
However, i noticed that tagging of
acs-tcl/tcl/util-diff-procs.tcl is unusual/strange/wrong. Although this file is in CVS HEAD, it is tagged with openacs-5-4-compat; as a consequence, it does not show up in a checkout with tag oacs-5-4, but it will be contained in "install/update" from repository. Not sure, who has tagged it with which intentions. Maybe the goal was to include it in oacs-5-4?
In the name of the Official UNED .LRN website (hosted by Innova), I have to say that UNED is using xowiki, at least, in 4 dotlrn sites (plus their development instances). We are planning to use it in another 3 more websites we are developing.
We also use the "content" application Roc's said before.
I think the path we will follow is to maintain the IMS-LD player GRAIL using CR and offer the possibility of deploying resources in Xowiki ONLY if the package is installed and in a per UoL basis.
That way, we take the best of both worlds and maintain IMS-LD backward compatibility.
We might have some time in Valencia to talk a bit further about his topic.