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).

Faculty and School (that is not CSP)

Assuming that CSP proceeds as core data, this component of the (current) Faculty and School HLS area can be though of as only loosely coupled to the rest of the F&S work, which in turn can be though of as comprising activity in the following areas:

• High level IA and site structure: Changing this is always easier before a major project rather than during or after. As such we urgently need direction or answers in this area. I think it sits with Nathan (and 'Tash for a few more days) to advance but I can not see a delivery date for a new IA. I am encouraged by the feedback of workshop participants with the direction of "audiences and their needs first", a pillar of how we think about the website and how we approach our work (but the devil might yet be in the detail). This is now on the critical path and maybe even a blocker, in that the following bullets are all reliant an a decision at this higher level. 
• Lower level site structure and content plans: Well advanced by Anne, but potentially requiring rework depending on the high level IA work. Needs socialising with stakeholders, as it is currently a straw man or proposal. Workshops to date indicate an acceptance from half the faculties and a willingness to discuss from the others (but please do not mistake this for an agreement or willingness to implement). I suggest we have follow-up conversations with any faculty that does not seem onside with the "folding of school sites into the faculty site", meaning VBS and Science so far.
• Navigation: From simple (page sections, hyper-links, etc) to more complex (contextual search widgets). Can we identify some more complex ones early, with sufficient knowledge of their importance that work can start on them now?
• Functionality: I feel strongly that this area has to push ahead faster, partly because it is mostly new to the website (so therefore has a higher risk until we understand it better) and also because I am (or soon will be) half way through my contract and we have not yet built any new functionality, and this is an agile environment). I am thinking about this category (as tagged by Sam in Reframer for workshop observations) in terms of:
  • Engagement: The more simple, one-way functionality that allows the user to do stuff he/she wants with our content. Client-side, not restricted (much) by Squiz, generic/modular (in that it could be placed on any/all pages as required). Examples include share, print, book mark, download, etc. Can we identify some more complex ones early, with sufficient knowledge of their importance that work can start on them now?; and
  • Online Services: More complex, two-way, transaction-based functionality that allows the University to deliver a service to an audience online. Examples include buy, ask a question, subscribe, rate, register, change my details, etc. Can we identify some more complex ones early, with sufficient knowledge of their importance that work can start on them now?

We expect to start working intensively with FHSS on content but these may not require workshops (Anne and Sam to decide). However, in working on the first faculty (no matter who it is) there will be specific functionality required that is also required for (many/all faculty sites. Advancing this with only one faculty involved is short-sited (the requirements are likely to be incomplete and the solution sub-optimal and with less than ideal buy-in). Involving all faculties has challenges of the number of participants and can partly reduce the risk of disengagement of faculties we must leave waiting for many months until we can work with them on a new site.

Sam, Anne and I realised yesterday that the next round of "workshops" could well be functional requirements for a specific feature set (or set of related widgets). We could define an epic (e.g. events, course finder, change my details) and gather a small group of interested people (a core from FHSS and a smattering of other interested/knowledgeable representatives from some/all other faculties). This group could meet a few times, probably quite frequently, over a short period of time, until at least the stories are written, but ideally until the widget is built. As a group they would have the role of "product owner" for the feature set in scope.

After discussing with Andrew and Nathan I would modify this approach to the following steps:

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

Subjects and Area of Study

Area of Study

• The proposed term to cover a cluster of related/similar subjects (can also be though of as "topic" or "area of interest/enquiry')
• Would be a starting point for a future student who is exploring what to study
• Would map to subjects, programmes and maybe even courses (issues here listed in course section above and subject and programme sections below)
• All work to identify these (including if they will work) is on the critical path.
• Where the mapping between area of study and subject is:
  • One-to-many: Use area of study before they move to subjects, 
  • One-to-one: Use area of study instead of subjects.
• Could be related to a faculty (or two)
• Could be related to one or more schools

Subjects

• 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.

• Chrissi Dean (Unlicensed) note the explanation that you requested.