Skip to end of metadata
Go to start of metadata

UI Design and Functional Specifications

Here you will find details about the form and behavior of Course Management-related tools.

  File Modified
PDF File gap_42.pdf spec on which Home Tool is based Aug 07, 2006 by Marc Brierley
PDF File Edit Roster.graffle.pdf New Edit Rosters Mock-ups - Pinto+ Aug 17, 2006 by Daphne Ogle
Microsoft Word 97 Document CM Design_Requirements Wrkg Doc.doc Requirements, scenarios & progress per tool (working document) Sep 14, 2007 by Daphne Ogle
Microsoft Powerpoint 97 Slideshow UCB Stanford Scope Mtg.ppt Summay of user research findings and design direction suggestions Jan 31, 2008 by Daphne Ogle
  • No labels


  1. On page 3 of newCourseSite1.pdf, there's a problem with the notion of a site being "already created" for a course offering. If a site exists with only a single associated section out of multiple possible sections, does the "Site already created" message appear for the user?

  2. Good question. In this case we would want to show the "already created" information at the section level. We can assume that more than one site is being created for the coure offering in this case the finer grain will be necessary.

    Make sense?

    1. The mockups indicate that the checkboxes for the course offering and for all of its sections should not be rendered when the course offering has already been associated with a site. This is more of a problem than just where to place the "already created" message.

      One option is to render only those sections that have not been associated with a site. But are you really sure that this is a valid business rule? It can also imagine this making the auto-gray-out/auto-check behavior pretty confusing when some of the checkboxes are not there.

  3. When a user does the following:
    1) Clicks show all terms
    2) Selects some sections in non-current terms
    3) Clicks show current terms
    4) Clicks show all terms

    Do the sections in non-current terms (those that were hidden then redisplayed) retain their state?

  4. The mockup contains references to 'instructor of record' which we (and other universities) do not necessarily have. Let's not embed assumptions like that in the design, or about the approval workflow for associating Sakai course sites with SIS student enrollment.

    Also the mockups seem to imply a 1:1 relationship between courses in the SIS and Sakai course sites. In theory there's no reason why there couldn't be > 1 course site for a course in the SIS.

    1. Hi Stephan - We will not exclude the workflow for setting up sites in a more manual fashion when the instructor of record is not known. This initial workflow just focuses on that case. Question: do you never know who the instructor of record or is it just that way in some cases?
      As to your second statement, these initial mockups focused on one:one. Actually, the revised version attached to this page shows more types of associates like you will find here. We will also support what we call cross-listed courses. Please see the Cross-Listed Course Patterns. Is this similar to the use case you are considering?

  5. This looks good Marc! One concern of mine is the location of the important but fairly static information – course information vs. the location of the fairly dynamic information. I don't think people will see the synoptic tools at the bottom of the page. There is not a driver for users to scroll down the home page after they've seen the course information (so maybe 1 or 2 visits).

    I think synoptic information is trying to serve a very important purpose of helping users know what to pay attention to – what's new. Would you think about moving them back to the right colum?