Documentation:Course Delivery Requirements

From Kumu Wiki - TRU
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.


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)