Here's the first update on the status of Curriculum, a Polyxena production kindly brought to you by Carl Robert Blesius and the Medical Faculty of Heidelberg. All feedback from the community is welcome.
The work that's been done:
So far, a week into the project, we've made an initial stab at the data model and user interface. Some of this code has been committed to the CVS head; the rest will be committed when we've fixed a few showstoppers. As soon as we have something intelligible to show, we'll do so in a public demo where you can all try out the package as it develops - and influence its development, of course. The demo server will run the latest Curriculum code committed to the CVS head, and will be updated weekly or so. It'll be up some time this week, I imagine.
The UI consists of two distinct parts: one for teachers making curriculums and another for students taking curriculums. The teacher or admin user interface is mainly the add-view-edit ("ave") forms for defining curriculums and their learning elements, plus their metadata. This course design work has a publishing workflow managed by the great new Workflow package. The student or end user interface consists of a presentation of the published curriculums plus a user tracking feature that is handled by a user-element mapping table. On the index page the student gets a detailed view of the curriculums and her individual progress and options. In the curriculum bar widget shown on all templated pages she gets a more condensed version of the same info.
Problems encountered:
As has previously been discussed, when visiting external URLs that are learning elements the curriculum bar is out of the picture, literally. The tracking will still work, using clickthrough, but it is only when the user (without guidance) returns to the site where the curriculum is published that she gets to see the curriculum bar again - now with the visited element checked. We will try to find a way to suck the external web page into the curriculum's site and thus template it, as suggested by Malte Sussdorff. We can easily do this with ad_httpget, all right, but relative links and (thereby) CSS style sheets on the external page freak out in the process.
Apart from those URLs outside of the curriculum's server, we may also want to define URLs outside of the curriculum's subsite as being (in one sense or another) external. There can be only one Curriculum instance per subsite, and currently the curriculum bar will appear only on the curriculum's own subsite. In addition, there will be some confusion whenever an element is found on a neighboring subsite with a Curriculum instance of its own. The student will then be presented with the curriculum bar belonging to the foreign subsite's Curriculum instance. We have thought about solving this by registering a filter or proc for each element URL that is internal to the site but external to the subsite of its Curriculum instance, making its curriculum bar display on the foreign subsite. These are just loose thoughts at this stage - we'll attack this problem later on.
Outlook for the future:
We are currently ahead of schedule, with most of the more delicate problems solved, but a few difficulties remain before we can attend to the last details - that is, put on the makeup. The next few weeks we will spend our time:
- Integrating the publishing workflow process.
- Solving all aspects of the external URL problem.
- Creating applets and portlets for dotLRN subsites.
- Analyzing and perfecting queries and caching of data.
- Improving the usability and beauty of the interface.
- Writing user documentation.
- Drinking coffee.
