Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

With WIP-II course requirements mostly coming from, and being delivered through COO, COO the CSI focus is now on subjects. This page (and it's children) are to document our analysis around subjects (whereas the analysis of courses is mostly in the COO workspace)

"Rationalise": Challenging assumption

Background documents for WIP-II identified a statement that this project should "rationalise the subject listing for a web/online purpose". In treating this as an assumption (even before figuring out what was meant by "rationalise"?) I was unable to find any written record of why we need to rationalise. Further, there is good work on how this could be achieved (and even a proposed new and shorter subject list) but no compelling reason or driver for this to be an objective or aim for the subject domain. The three best reasons (and a response) are:

  1. The list is too long for on-screen navigation: The length of the subject list is not the problem, rather it is how the subjects are listed on-screen. The solution lies in better UI design and use of tools (e.g. search, filter, etc);
    1. Related to this is how students search for subjects. Do they go looking for German and expect to find it, otherwise walk away. Or would they search for German and be un-phased if it was a specialisation of Language and Culture? Would a student look for science (the highest level), biology or biological science (a mid level term) or, biomedical or biotechnology? While search can relate these and return all/some/prioritised, we may need to put ourselves in the users shoes and pitch it at their level.
  2. Cost/resources to maintaining so many subjects: While there will be a cost to maintain a subject, it is probably very small compared to the cost of maintaining a course, because courses are far more than a web page (i.e. they have staff, rooms, printing, etc). If it were a matter of findings (or even making) savings then subjects is a low return place to start looking.
    1. However, the proposed subject pages would be considerably more expensive to maintain, as they would have data that requires updating more frequently (e.g. income, vacancy, etc). Further, the data sources might not even have the granularity that we require and publishing "aggregate" data on a detailed page does miss the point/mark.
  3. Students, especially at the UG level, are unlikely to have the discernment or awareness required to fully appreciate the differences between closely related subjects. In contrast, after completing a entry or foundational degree students would have a much better understanding of the specialisation available at PG level. This would lead us to fewer subjects at the UG level and more at the PG.

The argument to rationalise the subject list, if this means reduce, is not compelling. However, I believe it is always a good idea to ask stakeholders if their current subjects are working for them and their customers. In this context rationalise might be seen as "review" or "reflect".

 

Two authoritative sources

The initial discovery identified two authoritative sources as contenders for our master list of subjects (note that this is distinct from the content about subjects).

 

Web subject listing

This is really an index of subject pages on our website and the analysis found the following:

...

All that said, this approach has merit and could be made to work.

 

 

Publication subject listings

Subjects are listed in many of our publications (sometimes split in to undergraduate and postgraduate). They are based around "explaining course codes", or at least the first four (alpha) characters. While there is usually a relationship to established subjects (and the nature of this relationship is usually clear upon reading) there is not always one (see this table for an example). The analysis also found:

  • Organised alphabetically by code to support the above purpose, but creating challenges finding an entry if you have a subject in mind.
  • Historic, as in set at a point in time and slow to change. For evidence of this note the modern subjects that do not have a code (e.g.Ecology and Biodiversity)
  • This could means that a modern subect subject has less print exposure than more established subjects
  • Updated inconsistently, as in all schools are given the same opportunity to update content but not all respond with the same energy.
  • Poor link back to the web, because we have not reconciled the differences very well.

 

A challenging assumption

...

Conclusions/Recommendations

I suggested that we:

  • Define subjects as (primarily) a marketing construct. As such it should be driven by the user needs, or at least the University's business needs around recruitment.
  • Accept that there is an imperfect link to the subject list sourced from Banner and the major list for programmes. This means that we can live with differences and an imperfect mapping (if we have such requirements)
  • Obtain student (and student recruitment) input into the subject listing and taxonomy (i.e. how we classify the areas or domains where we offer courses), to balance or contrast the views we will elicit during our faculty and school engagement.
  • Seek to understand the process by which a subject change (new one added, old one removed, or multiple combined/collapsed) is approved, especially the burden of proof or threshold that much be reached.
    • With the aim of "inserting" Marketing in the process (check-list).
  • Encourage schools to reflect if the subjects that they already have "approved" are the correct ones to market, as we work with each school.
    • We can posit ways to "rationalise" and listen to the feedback, as well as offering various degrees of "exposure" (e.g. main subjects might have more real estate than specialisations in a subject (even though these might have their own page for those who searched for a specific term).
  • Explore better ways to use metadata/tags to cover concepts like alternative terms, related subjects, and recommendation systems.
  • Ensure that the UI supports easy navigation.
  • Refine search so that it is powerful, accurate and easy to use.