Hierarchy Notes
UM Attendees: Dick Ellis, Lisa Emery, John Leasia
UMD Attendees: Ellen Borkowski, Rick Moyer
Cambridge Attendees: Aaron Zeckoski

For the basic hierarchy, Aaron will be working on five main pieces:

  1. Interface to create hierarchies
    1. The "super eval admin" would use this page (https://courseware.vt.edu/users/aaronz/CourseEval/Redesign/Wireframe/HierarchyControl.html)
    2. The University level could probably be defaulted in (unless we can think of another use for the hierarchy that is not related to universities)
    3. The interface should allow the user to add new entries for the School level and Department level values (these will be defined differently by each university)
    4. At the Department level, the interface should also allow the user to attach "prefix" codes - these codes would need to map exactly to the code of the course being brought into the system.  For example, if courses are brought into the system as BIOANTHRO 115 001, the Department level for Biology would set up a code of BIOANTHRO.  (more on why we want this in part 3)  The 'Add/Modify' page from the wireframes (https://courseware.vt.edu/users/aaronz/CourseEval/Redesign/Wireframe/ModifyHItem.html)should be modified so that more than one prefix could be added for a Title.  Note:  currently, the 'Prefix' field is labeled as 'Abbreviation'.  
  2. Interface to assign Eval Admins to levels (https://courseware.vt.edu/users/aaronz/CourseEval/Redesign/Wireframe/ModifyUser.html)
    1. Option 1 is to go through the hierarchy and attach users to each level
    2. Option 2 is to look up a user and assign all the appropriate permissions to that user
    3. There isn't a strong preference for one or the other option
    4. There needs to be two options for permission settings.  One is for update access, and the other is for view only access (this is intended for users who need to see reports, but won't be setting up evals)
  3. A way to map courses to the appropriate hierarchy
    1. The preference is to have an automated mapping based on "prefix" codes.  This way, users don't have to map each course to the hierarchy.  The tool could take a course, such as BIOANTRHRO 115 001 and traverse the hierarchy by first matching BIOANTRHRO to the Department level prefix code to determine that this course is part of the BIOLOGY department, which is part of the College of Literature, Science, & Arts, which is part of the University of Michigan.  
    2. There also needs to be a way to override the automated mapping for the case of cross-listed courses.  We are considering this out of scope for the initial implementation of hierarchies.  
  4. A way to flag certain templates as default templates
    1. See accompanying wireframe for potential design ideas (Heirarchy design ideas)
    2. Do we need a warning or error handling if more than one template is assigned at the University or School/College level?  Since access will be limited in terms of who has access to do these, maybe it is not necessary.  This implies that the ability to assign hierarchies would need to be based on permission settings.
  5. A way to flag certain evaluations as 'official' so that they traverse the hierarchy and pick up all the appropriate templates at each level
    1. This would probably just be an additional field to select when setting up the evaluation
    2. When a user takes an official evaluation, it would pick up all the hierarchy items as well as the instructor added questions

Additional issues and points of discussion