Documentation:Course Delivery Requirements

From Kumu Wiki - TRU
Revision as of 15:50, 20 October 2014 by Idevries (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Beginning...

The purpose of this space is to start creating a working document that describes what Open Learning needs in terms of Course Delivery on the web. The document should consider all aspects of Course Delivery from development, student/open learning faculty member experience, to maintenance. The goal is to create a framework for guiding technological decisions.

Meeting notes

Course Content Delivery Requirements

Below are a series of questions to drive discussion (bit of brain storming by C.Teare)

  • What are pedagogical requirements? (What types of course content to we need to support now/in future)
  • Are there some specific tools we must be able to have as part of course delivery (content only)
  • Are there some key features we must have (eg. easy to adapt to our needs now and in the future)
  • How important is that there are between content links?
  • How do we want content entered/stored/maintained? (eg. focus on dedicated staff or more a global approach)
  • Are we willing to lock into a particular format? (eg. content stored in a format custom to system not pure HTML)
  • Is customization now or in future important? (eg.Look/structure)
  • Do we need to control versioning? To what level? (snapshot on release, constant..., none)
  • Are there other overriding criteria for platform source? (eg. Open Source, Same as Campus, Cost basis?)
  • Does is have to be one product/platform that does everything or can it be split into parts?
  • Does is have to tie to other institution systems?(which ones, eg. automatic enrollment)
  • What are the requirements for Open Learning Faculty Members?


To provide context our current delivery system might be described as such:

    • Text focused (many page of just text) with limited use of media or interactive components
    • Interface fairly static and clunky (poor refresh rates, issues with how embedded media handled in certain browsers)
    • Availability of interactive components within platform (Wikis/Blogs/Discussion Forums/Journals/Groups/Assessments)
    • Can interlink content within text page (either to other text pages or internal or external documents) - web of information
    • Ability to highly control release of content
    • Security Model (need password to access content)
    • Can format independently from system (CSS external)
    • Content is independent of platform (HTML pages)
    • Workflow is designed for easy and efficient to upload content– by dedicated staff
    • Workflow is optimized for internal changes (dedicated staff) to content, external changes possible but daunting to uninitiated.
    • Versioning possible through creating a copy of master only - no page versioning within system even if we used that option
    • Multiple distinct copies can be easily made (one for every Open Learning Faculty Member without harming the integrity of the content)
    • Basic interface allowing a degreee of structure customization of content but limited control of certain elements
    • Connected to Banner system to load students only
    • No connection between gradebook and MyTru portal (official grades)
    • Gradebook partially used - grades display but up to Open Learning Faculty Member to customize
    • Supports grading rubrics
    • Looks the same as campus interface (unless someone picks different theme/display options)