With WIP-II course requirements mostly coming from, and being delivered through, COO the 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": A challenging assumption
- Keith Bolland (Unlicensed) after the discussion with Ian I realise more input is required on subjects. I have put the task ico at the "ratioinalise" only as an indication of one decision point. Please lend some assistance and let Chrissi Dean (Unlicensed) know how we can best draw the core team in here. By
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:
- 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);
- 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.
- 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.
- 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.
- 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 underwhelming
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:
- Accurate at a point in time: Therefore gradually becomes inaccurate. This is probably due to some process gaps and also lack of "rules" on what ought to be referenced as a subject.
- Subject data surfaces in different places: And does not always seem to be from the same master, leading to confusion and a poor impression.
- Different paths to subject give different results: Maybe the same as above.
- Alternative terms are not handled well (seems to be a hang-over from a paper listing, nit designed for the web.
- Related subjects seem to be manually entered and are used inconsistently (although consistency is higher with a faculty).
- Is sometimes a "hybrid" subject, leaving the reader uncertain if it is a subject with more than one term/focus, two subjects or something else.
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 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.
Conclusion
I suggested that we:
- Ask schools if the subjects that they already have "approved" are the correct ones and update as we work with each school.
- We can posit ways to "rationalise" and listen to the feedback)
- 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.
- Take the sum of the subjects offered by each school as the subject listing.
- 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.