Forum .LRN Q&A: Using Xowiki from the Learning Design Player GRAIL

Hi.

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.

Regards.

1. If you make it strongly depend on xowiki, it will not be included in .LRN. This probably leads to a fork of the code.

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.

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.

hmm, somehow i get the impression that some people think that xowiki is horribly inaccessible. Not sure, where you got this impression from. According to Cynthia Says, the xowiki documentation (an xowiki application, http://alice.wu-wien.ac.at:8000/xowiki-doc/book) is compliant with WCAG 1+2, and section 508.

Hi Gustaf,

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.

Of course, revisions and diff are core features of OpenACS as well, so you can use those features with or without xowiki.

dave, where is "diff" part of OpenACS? Of course, xowiki uses the openacs content repository, so every feature available in xowiki can be programmed again and again without using xowiki in various apps. The point is, that xowiki provides many useful features already, and seemingly some people find it more productive to use these than developing it on their own. In some respects, xowiki (as a framework) unleashes some of the power of openacs at a higher reusable level.

Despite my prior impression, this thread has some value. I was obviously not aware of this functions (although i have changed a few lines in it). It strikes me that i must have obviously forgotten that it exists. Sounds like a sign that i should take some vacation.....

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.

Just a followup to my own posting: i fixed three bugs in util::html_diff (see commit log http://cvs.openacs.org/cvs/openacs-4/packages/acs-tcl/tcl/util-diff-procs.tcl?view=log) and commited to CVS HEAD. For some random examples, the output seems now quite ok. I'll add some optional support to xowiki to use it.

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?

Is more a learning content editing tool that also generates the navigation automatically using templates, so you can create pages with one click rather than using complicated tools such as reload.

Thanks for the feedback on this issue.

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.

Regards.