Models for Content Authoring

Based on a discussion at the Sakai Planning meetings after the 2008 JA-Sig Spring Conference I thought I would take a stab at outlining several different models for Content Authoring that were discussed.  One of the salient points from the meeting, strongly and correctly emphasized by Jim Eng, was that we need to be careful about proliferating too many types of content authoring in Sakai.  This will lead to usability problems not to mention potentially wasted effort. With this in mind, I've been thinking about where and why we want to author content in Sakai.

These aren't meeting notes, exactly, but rather my thinking as it has evolved from reflecting on the meeting. This isn't a set of use cases or requirements, either. It's just me trying to sort through my own thinking on this topic. 

Styles of content authoring

The following is an attempt to classify the different "styles" of content authoring that are available. 

• Structured Inline Editing -- The overall theme here is to allow a user to edit content in a real WYSIWYG fashion.  Not just for the bit of content that is being edited but the entire page that it (may be) situated in. There is no "edit-save" cycle for the particular bits of content that are being changed (although there may be a "save/cancel" option for the page itself...see "saving/reverting" below")
  1. plain text editing.  I'm not sure we do much of this in Sakai. The best example I have of this is google calendar where you simple click on a text element and can edit it in place. There is no "save" or "submit" action that takes place. The form isn't doing any validation other than generally limiting the size to what fits on screen.
  2. rich text editing. Same as #1 but with formatted text (html). I'm not certain there is a meaningful difference here but there could be.  The added interface elements needed for formatted text editing could make this impractical in many circumstances.
  3. Inline structured form. The best example I have of this is, again, google calendar. If you click on an event date you're presented with a date editing form. Data validation is included. Pretty slick, I think.

• Unstructured inline editing -- This is google word processing. It's really a special case of inline editing but I'm calling it out separately because it "feels" so different. There is no distinction between viewing and authoring.

• Unstructured "Edit-Save/Cancel-Publish" editors. This is how the FCK editor is used in many cases. You have a bit of content that you want to author/edit.  You enter edit mode on the entire block of content and are presented with an interface that, while it may be WYSIWYG in terms of the bit your editing, it isn't really WYSIWYG from the context of the where that block of content is presented to users. The best example I have of this is a wiki or blog.
• Multi-step Form/Wizard-based editors. Samigo is a good example of this. You fill out a series of forms to create structured content. In many cases the forms you fill out don't resemble the final product at all. If the structure is easy to understand this doesn't present a problem--the author can easily imagine what the end result will look like.
• Edit mode editors. Click an edit button on the page and it turns on editing features. This is very similar to "Structured Inlined Editing" in many ways. Melete is an instance of this, I think. Moodle uses this mode for editing the course home page.
• Offline authoring and posting. You author your content in an offline tool like MS-Word or FrontPage and publish the resulting file (usually) HTML to the system. This can be done either via a filu upload or a cut/paste into another tool. This obviously creates a potential distinction between how content gets created and how it gets added to a site. Theoretically, any of the "styles" could be used in an offline tool and then uploaded in a variety of ways.

I think it is quite possible to have a number of different special purpose authoring tools and still have a coherent user experience if we can agree on a few preferred styles and then develop common conventions for those styles. This, in fact, is my suggestion for the next UX mini-project.

Back to my use case

My "Content Authoring" use case is for a site author to create a structured "home page" for their course that is organized by topic or week (or other organization) and includes links to the needed resources (images, slideshows, movies, reading materials), activities (tests, discussions, etc) and events (office hours, lab meetings).

I would like to see this use case addressed by an "unstructured inline editor" supplemented with a set of templates. There are a few reasons for this, not the least of which is that we already have a good tool that enforces a structure (Melete). But, more fundamentally, I want to address the needs of those folks who want more control of what the page looks like. So give them a starting template but allow them to break that template.