Child pages
  • Authoring Contexts
Skip to end of metadata
Go to start of metadata

I have tried to write down some key points about the different contexts in which we may be discussing authoring:

We haven't touched much on the top level, public presence (mostly) and private presence (a bit) for a programme, or collection of courses. Matthew Bucket's hierarchy presentation at Paris showed something of how useful this can be. Sakai mainly operates at the course/site level and the thinking behind widgets is to move some of the interactive functionality (discussion threads, tests, reference lists, etc.) from this level to the teaching unit level and integrate them with the more traditional teaching unit content. The other attraction of widgets is to enable cross-cutting information to be just as available, like all my late assignments for this programme (collection of courses), student-centred Portfolios across all course work, shared teaching materials, etc. I currently understand Mathieu Plourde's concept as being aimed at a general solution for the teaching unit, Mark Norton's concept as being a more traditional concept of teaching unit authoring, Michael's word plugin as a limited scope concept for part of the course or module authoring context and Noah's concept addressing the cross-cutting authoring context. The 'Edit in Place' or 'Google Sites' concept I was pushing was aimed at the course context, but after drawing this diagram I can see that I was mixing in teaching unit issues. I need to think more about how important it may be to keep these contexts separate.

I hope to review where common technology can help next, by reviewing the way Google has specialised tools for different contexts that all seem to draw on some common technology. I am imagining this could be a way forward for Sakai.

Note: I already know that we don't use FCK editor very wisely. I am pretty confident that we may want to look at Tiny MCE as an alternative, but there could be an argument for writing our own. We should certainly be trying to think about how to analyse the choice.

Note: I also think we should go into this with a lot of secondary issues in mind - e.g. export/archive formats, standards and interoperability, accessibility, internationalisation, adaptability to rapid change, etc.


  1. Note: different levels/types of collaboration and interaction implicit at different levels...

    1. You have shown this as a containment hierarchy in which the "programme" level contains the "course" level and that contains the "teaching unit" level. That hierarchy seems to correspond to the institutional hierarchy, but I wonder whether that is significant to the participants' "authoring" activities. At least part of the distinction between levels is that people use different "systems" in different levels. Is that inherent or just an historical accident?

      Let's say we listed a bunch of authoring activities across all three levels in this hierarchy and characterized them by "levels/types of collaboration and interaction". Maybe that would identify a few common patterns. You seem to be suggesting that we'd find most of the activities at the programme level have one pattern, while most activities at the course level have another pattern and most activities at the teaching-unit level have a third pattern. I'm questioning that.

      1. I was thinking that a quick literature search would turn up some great article that provided a simple yet complete set of characteristics for "authoring" activities and/or collaborative activities that would make it easy for us to analyze the types of activities we want to support. I haven't yet found anything approaching that. I'll keep looking.

      2. Quoting Jim Eng:

        "That hierarchy seems to correspond to the institutional hierarchy, but I wonder whether that is significant to the participants' "authoring" activities."

        Exactly my thoughts on the topic. We might be trying to get too deep into the bowels of Sakai while, in fact, what we need to focus on is an enhanced WYSIWYG editor (FCK, TinyMCE, home-grown, etc.) which can link to entities. Of course, some work will need to be done in some tools that are using the WYSIWYG editor to make sure that the generated HTML code for entities is not stripped-down by the tool.

        Everything else is related to a broader group/user permission scheme IMO.


      3. (smile) I think you are making my point quite nicely. Sakai is designed from a technology (tools) and institutional perspective. I agree entirely that we are likely to find common technology underpinnings. However, I would argue that if we want to develop a good user experience we need to place ourselves in the context of the user (who am I, what am I trying to achieve?). I would argue that thinking of the teaching unit context leads you to solutions like Sousa, which is of very little value in the public course site context because it is optimised for the teaching unit context. By recognising and articulating the different contexts we can evaluate which proposals are context specific and which are generic.

        1. Hi John,

          Following your logic, I think the idea would be to let a parent context use a part of a children one. For instance, the "program" might want to use a part of the syllabus of a "course" in its catalog. It still comes back to defining permissions.

          But reusing content in that sense starts to look a lot like a content management system. Should we think in terms of reusable content unit instead of entities? Would we need to think about an authoring workflow, where users would generate content and others would be in charge of rubber stamping it to be published?

          1. Yes and no (smile) I was not really urging any particular solution, more a framework for analysis. That said, I think a "reusable content unit" is one of the things that a Sakai user might want to 'author'. In my mind this is a different use case to the use case of "assemble text, reusable content, and active areas (like assignment submission) into an attractive and coherent page for students", which I also think of as 'authoring' in Sakai.

            It would be the inclusion of active areas in the page that would set this apart from a more conventional content management system.