Skip to end of metadata
  • Created by Former user, last modified by Former user on Sept 25, 2008
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 47 Next »

See also Desired Outcomes, Technical Issues and Project Planning

Topics that should be considered at the Authoring Summit

  • Design for a simple page-composition tool (is it really a tool?) What does calling it a tool mean in a UX context? Does it describe things it can and cannot do? If so what are they? Similarly are there Sakai semantics attached to the use of "Page"? What sort of page are we talking about? I think it would be useful to make different areas on a 'page' editable by different groups of people. Is that in scope?
  • Characteristics of contexts in which authoring occurs in groupware or CMSs like Sakai (or could/should occur). See diagram below.
  • Beginning to specify a UI for templating (including restrictions on scope of edits a la XML Schema. (is skinning separate?)
  • Who is willing AND able to commit to this project?
  • Can we agree to a project plan that is realistic (considers our volunteer model), structured (doesn't skip critical steps), and fair (allows for enough time to perform certain activities)?

Here is a little diagram I came up with on Tuesday. Food for thoughts. Mathieu

Work that should be done to prepare for the Authoring Summit

  • ideally a comparison of pros and cons of different (browser-based) editing tools (TinyMCE, FCK, developed clone of Google Editor (GWT?), etc.) from a UX perspective (including download performance, accessibility, etc.), even better with comparative/comparable testing. Any evaluation of known desktop app/online integrations (can't MS Word do something with WebParts?) (start by comparing editing tools in Authoring Tool Comparisons)
  • write up of use cases and classification according to scope, context etc. (start by adding use cases as children of Authoring Use Cases)
  • articulation of assumptions (e.g. built on Sakai 2.X, or abstract ideal, for use by admin/faculty/students/?) (list assumptions in Authoring Assumptions)
  • preparation of prototype demos (start by adding information about prototype demos and external tools in Authoring Prototype Demos)
  • list all the types of entities and what they should look like.

Proposed features for "web2" authoring in Sakai

Have a feature idea you'd like to share? Post it here:

  • Incorporation of information from other parts of Sakai (active/passive components, what/where, configuration according to page context) and other sources
  • Support for collaborative working
  • What about import/export, reuse of content, versioning, permissions, annotation, etc,
  • Use in other parts of Sakai (e.g. grading)
  • handling of time-controlled release, "Hidden" content
  • handling of user tracking
  • attachment handling (real attachments, not attachments as a means of including static files like image files)
  • should this be used for student work (e.g. creating assignments)
  • autosave
  • Are we interested in MS/Open Office integration, what about offline working
  • Be able to add content pages, dashboard pages and tool pages to your site easily
  • Be able to free form edit a page
  • Be able to place functional "predefined" units anywhere inside your page
  • Make those functional units configurable
  • Be able to wrap the text around the functional units
  • Handle permissions on writing pages, ...
  • Be able to link to other pages
  • Be able to reorder pages
  • Be able to rename pages
  • Support versioning of pages
  • Support collaborative editing
  • Build it on top of the current (new Sakai 2.6) interface
  • Have some basic templates for different site organizations (sets of pages with navigation) for quick start and/or promoting consistency.
  • Have means for the available templates to be controlled up a hierarchy
  • Support simple navigation
  • Be able to support 'tool per page' paradigm of current Sakai for those who don't want to change their sites
  • Be able to support legacy tool pages for tools that don't get migrated in time
  • Countdown feature which could be toggled on or off.
  • Support for authoring Sakai content directly using external tools (e.g., Dreamweaver, Web Expressions), and ability to utilize entities in those tools.
  • Conditional release of entities (must have completed Quiz 1, date and time, name starts with a "S", linked to a Gradebook or Post'Em column, etc.).

Note: only supporting simple navigation (current Sakai has one level only within a site with the left toolbar) implies that complex learning units are somehow 'embedded' in pages and launched from or within a page. I am currently imagining that it will be rare for a site to have more than 20 pages, but we need to think about what we would do if a larger site were really needed.

Links to or screen shots of cool UX examples

Delicious Links Tagged with "SakaiAuthoring08": a fast and easy way to share design examples and features worth evaluating.

  • No labels