Child pages
  • Site Info & Worksite Set-up Wizard Changes
Skip to end of metadata
Go to start of metadata

Site Info & Worksite Set-up Wizard Changes

Capitalizing on the now available SIS data through the CM API, changes will be made to the Site Info & Worksite Set-up Wizard. This new functionality will provide for hierarchical course sections to be displayed and selected on the legacy Creating a New Course Site "Select classes/sections..." page. Also, a course broswer will replace the course, number and section text fields on the Creating a New Course Site "Enter class information..." page.

Project Plan

8/22 - initial pec posted (Daphne Ogle)
12/1 - v.2 spec posted (Marc Brierley)
12/14-31 - have DAO objects (???) ready before Xmas
1/2-2/16 - coding (Daisy Flemming and Duffy Gillman)
2/20- 3/2 - need QA resources for CM Browser (Margaret Petit)
3/5-14 - bug fixing (Daisy Flemming and Duffy Gillman)

UI Design

The current UI design is attached to this page here:

  File Modified
PDF File newCourseSiteInWS.graffle.pdf Initial spec posted 8/22/06 Nov 27, 2006 by Marc Brierley
PDF File New Course Site Wizard Changes.pdf 4/4/07 version Apr 10, 2007 by Marc Brierley
  • No labels

4 Comments

  1. I would like to give you some feedback on the new course site wizard (version January 22) from an European perspective (the Netherlands). I don't know if this is the right moment or subject to give feedback upon, but please consider this as a contribution and not as an intrusion.

    Let me first give you some background information: at our university (Twente) the courses correspond with your 'Simple Course Pattern'. We don't use the concept of 'sections'. Each course has its own site (only one). In most cases a course is offered only once a year. Our academic year is divided into two semesters, each divided in two 'quartiles'. So basically, we also have four 'terms' a year but we don't call them 'Fall', 'Winter" etc.
    In the present situation, we don't have a connection between our SIS/course catalogue and the learning environment (which is not Sakai yet, we are in a pilot phase with 2.2).

    About the new course site wizard: this looks like a real improvement, both the 'SIS import' part and the manual entering of the course characterictics. It is more suitable for the Dutch situation than the current wizard. However, I do have some questions and suggestions.

    • I don't know if the values of 'term' (Spring etc.) are configurable now, but it would be great if they were, because we don't use Spring, Fall, Winter and Summer. For us, a term could be '2006-07 semester 1' for example.
    • We don't use sections: I don't know what will happen in this wizard if the SIS doesn't contain information about sections (errors?). For us it is important not to be 'bothered' by the sections in Sakai. Maybe the use of 'sections' should be configurable in Sakai (yes/no). Of course, this has impact on other tools as well...
    • p. 7: Is it correct that this is a list of all courses (in one term) for the entire institution? It could be very long and the user would have to scroll down a lot. Have you considered to use the Find course interface (p. 13) as default 'starting page' instead?
    • p. 15: is it possible to use a dropdown menu for 'Department'? If no SIS integration, the list of departments could be configured in Sakai.
    • p. 16: The title format <Term> - <Course subject & catalogue number #> - <section #> is not common in our institution. We mainly work with a 6-digit course number and the full title. Suggestion: the title format should be configurable.
    1. I don't know if the values of 'term' (Spring etc.) are configurable now

      Terms are configurable in sakai.properties now, and will be configurable in the DB when CM is fully integrated.

      We don't use sections: I don't know what will happen in this wizard if the SIS doesn't contain information about sections (errors?). For us it is important not to be 'bothered' by the sections in Sakai. Maybe the use of 'sections' should be configurable in Sakai (yes/no).

      It looks like we didn't go far enough in our attempt to be vague and generic with our nomenclature (sad) Sections are a required part of CM, but you don't have to call them sections. If the groups of users (which are currently labeled "rosters" in the Site Info UI) that you attach to sites are called something other than "sections" in Europe, just start doing a mental swap for the term section. Maybe you call them "classes"... so what the new UI allows you to do is attach one or more "classes" to a site. Further, you can configure whether you want the users in these classes to be automatically grouped together for use in the group-aware tools.

      p. 7: Is it correct that this is a list of all courses (in one term) for the entire institution?

      It is a list of sections (or courses or classes... whatever word means a group of users that get together to teach and learn) for which the current user has a certain role, as determined by the group provider. If your institution does not have information on who teaches what, this UI could definitely be problematic.

      p. 15: is it possible to use a dropdown menu for 'Department'? If no SIS integration, the list of departments could be configured in Sakai.

      Departments can be modeled as "Course Sets" in CM. See p13 for an example of using course sets as a filter.

  2. p. 7: Is it correct that this is a list of all courses (in one term) for the entire institution?

    It is a list of sections (or courses or classes... whatever word means a group of users that get together to teach and learn) for which the current user has a certain role, as determined by the group provider. If your institution does not have information on who teaches what, this UI could definitely be problematic.

    What we'd like to do is to present a list of courses that are organised by the department(s) of which the current user is a member. In 2.3, it seems to me this would require us either to 'hack' the tool, or to model all members of a particular department as instructors of all courses held at that department for the single purpose of being able to offer a sane way of creating course worksites. None of these 'solutions' seem ideal.

    1. I believe one way this can be accommodated is to load all faculty within a department into all the be course/sections in the CM data as "owners". That way when they come to the course/section selection page, they'll see everything available to them within the department.

      This is the strategy we are trying to accommodate dept. or "local" admins. Josh and/or Casey can correct me if I'm wrong.