Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Task marked complete

While waiting for a decision on the delivery approach (and maybe to inform this, if not yet decided) I have started mapping out the chunks of work, key questions and noting critical path (or high importance areas). I suggest that we identify actions/tasks based on the content of this page but will not do so until I have discussed this with Chrissi (and maybe she is better placed to do so anyway).

...

  1. Identify the functionality set areas (maybe these are the epics) based on the information we have.
  2. Efficiently determine if we believe they are in the "Must" or "Should" category.
  3. Use team expertise to identify which ones we need stakeholder input on and which we can do without other parties being involved.
  4. Establish a "product owner group" for one functionality set.
  5. Work closely together for a short period of time to determine the requirements, and ideally demonstrate a solution.
  6. Any solution must be a reusable block/tool/widget that can be deployed all over the site (beyond even a faculty site). This point applies even back at the first point when we identify the functionality set.

 

CSP

Courses

  • Let COO run its course (pun intended). I have concerns over the delivery date (when each story gets done) and the prioritisation process (with David and Angela)  from a WIP perspective in as much as we need to know what COO will give us, so we can either assume it will be there in time, or deliver it in WIP if we really need it.
  • Does WIP want to deliver some of the COO stories (earlier, as WIP)?
  • WIP has some additional course requirements in the backlog and might yet draft some more (as our understanding grows).
  • Will a user want to see all courses:
    • Related to a subject? But which subject list is used for this, given that the course attribute "subject" is based on the Banner codes and this is not a great match to our web subject? Further, if we abandon the Banner subjects in favour of marketing/recruitment oriented areas of study and subjects we will no longer be able to express this relationship.
    • Related to an area of study? See definition below. Would be an inheritance approach or a search based on a join, with the results normalised.
    • Taught by a certain staff member?
    • Taught (by staff) in a certain school?
    • Required for a programme? This touches on where is the master of this data, can it be accessed as a feed, is it understandable by a human, etc? 
    • Related to a specific course? Still need to define related but I think of same subject or area of study, same level plus or minus one level,  
    • Recommended by others? Still needs defining but I think of a recommendation engine hooked in to either the enrolment data or GSA

...

  • Could be at the same level as areas of study (where there is only one in an area of study) or lower. What will this mean for content plans?
  • Might require a related subjects list (currently manually maintained)
  • Is related to a school (and through this to a faculty)
  • Can be studied through one or more programmes (maybe we show advantages of each, if more than one)
  • Could display the "associated staff", based on roles (e.g. teaches this courses related to this subject, researches in this subject area, is librarian with responsibility for this subject area). All this might also apply to area of study.
  • Could display research opportunities: Based on research interests of staff (see above bullet point), research projects (especially if funded), institutes/centres/chairs, etc. All this might also apply to area of study.

 

Programmes

  • Assuming we market programmes, is there room to improve the information about them?
  • Expressed the mapping to subjects in reverse?
  • Do students want to know the courses required by the rules of a programme? (also covered in the courses section above)
    • This touches on where is the master of this data, can it be accessed via an API or ingested somehow, is it understandable by a human, etc? An important question, that could take some time to answer. 
    • Would this also need improved data quality in course outlines, which in turn would mean a design of the Banner form/screen for data entry?
    • This could be a lot of information, so careful UI design is a must. Josef, enter stage left.
  • Are administered by a faculty

 

Where does the 1 October date come from?

I have picked this date up from two sources, both with a similar focus:

  1.  COO set this as their target date to have course outlines for 2016 available online via the new, centralised publishing model.
  2. Tash stated that this is date as though it was the commonly accepted date for the start of the recruitment/admissions/enrolment season for 2016 (and maybe the summer trimester, that I don't know).

Given the reason behind this date, and that the course outlines will all be on homesite, having subjects and programmes also on homesite means we significantly reduce the "bouncing" of students between two generations of our templates and brand.  The key information that students need from the website in that busy season would all be served from homesite templates.

Given that this target might be challenging it seems reasonable to focus it on undergraduate first, as this is the bulk of the users and the vast majority of the future students (who have not yet learnt how to navigate our mixed site.

 

...