What order to we approach each content area?

Topic pages are a new creation and do not currently exist.

Subjects exist on faculty sites, school sites, Future Students and Victoria International (VI). They are likely to be based on the same content (i.e. one "asset ID").

.

Future Students (until renamed Study at Victoria).

Will pull through to VI.

Could pull listing through to school and/or faculty sites, if required.

Approximately 52 topics pages to develop, including a PG only topic (Health) that could be deferred.

At the highest level we either develop all topic and programme pages in private and then go live with them all in one go, or we go live in batches of one programme and the matching topic(s). We can, of course, also opt for a middle ground, a number of programme pages and the matching topic pages in one release. If the later, then as each topic page goes live we:

1. 'De-index (or remove?) appropriate subject pages from school/faculty sites when topic pages go live; and
2. Re-map or re-direct that "subject" on VI to look at the topic page; or
3. Move the asset to the VI page and then 'remove' subject pages from school/faculty sites

Launch the full mega-topic and topic structure with the first topic(s), but with all other topics/subjects mapping to the existing subject pages

1. Remap Future Students and VI to the new topic pages in the same "batches" as we plan to use for go-live on Future Students; or
2. Work in moving old content to a new location, but it would allow us to bundle up all the batches on Future Students to one release for Victoria International.

Rework will be required on other web pages, as we need to (gradually) change most subject references to programmes. An example is the Programmes and courses section of Future students.

Subjects that can be studied (only) at the PG level could be mapped to existing PG pages until we remap them. However, turning off subject pages may, in some case, remove programme rules that are not available elsewhere on the website

In this case we might have to move the PG rules from a subject page to somewhere on the existing PG programme page.

The related topics block might be "messy" until all topic pages are developed. We could map to old subject as an interim or develop the block in a later release.

Knowledge of the topic approach is held by only a few people. Resistance or objection to this direction could, at least slow us down, but might even force a change of approach

Reputation/image during the transition period: Some subjects are covered by new topic pages while others are still on old subject pages.

Faculties' willingness to have the new-old version split live at the same time. Easier to manage when a faculty has a tight offering but difficult for the broad ones.

(No matter how much we try) We will fail to identify all the links that we break when turning old pages off. So long as we fix them promptly when we find them (ideally via a pro-active tool search but at least when reported) it should be okay.

The topic-first approach is not reflected on the website or our publications (not even as subject-first). One university, multiple channels should see that they align. See the Step by step section on Planning your degree and courses. How important is this?

Future Students (until renamed Study at Victoria).

Will pull through the VI.

Might pull listing through to faculty (probably not school) sites.

Approximately 15 UG programme pages (including 3 professional and pre-degrees (need to be taken off school sites but may not always map nicely to a subject), including the Batchelor of Engineering with Honours but excluding the LLB with Honours.

Decommission the old UG programme pages when new UG programme pages go live, which in turn is best linked to then the feeder topic pages go live (see row 1 above and the pseudo step in the row below)

For the record, the UG programmes are:

1. BAS
2. BA
3. BBmedSc
4. BBSc
5. BCom
6. BDI
7. BEd(Teach)EC
8. BE / BE(Hons)
9. LLB
10. BMus
11. BSc
12. BTM
13. CertDeafStud
14. CertEnglProf
15. DipMaoritanga

The main teacher education programmes are postgraduate so will be left for the next phase.

See above

This approach relies on the new programme page containing the "rules" for all majors. I had initially thought that this programme page could only go live once all majors were included, even if those majors are taught by another faculty to that which "administers" the programme in question (e.g. the BA has 40 majors (plus 6 listed minors and "hanger on" subjects), including 8 taught by other faculties).

However, following the same reasoning as captured in the following row, I realised that we probably have some options here. We could go live with a new programme page and the majors it represented by the subjects in the first (few) topic pages maybe one mega-area's worth), while leaving either the new or the old programme page mapping to the old subject pages for all the other majors.

See above

Further, it is unlikely that we can "remove" old subject pages until we have enabled the new programme pages, as the subject page currently has the appropriate major rules. So, our rewrite of the programme page is not only to "refresh" the content but also to integrate all the major rules that are currently on the subject pages but will not make it through to the new topic pages.

Ideally, all courses would have outlines published via COO. We should map to the course finder result, even knowing that it is only a subset of attributes available on an outline.

I believe that we also have to deal with a small number of pre-degree programmes, content about which is only available on current school site (and even then patch and hard to find). I believe that the first three have a topic mapping and the fourth, while awkward, could also if we wanted:

• Diploma in Māoritanga / Tohu Māoritanga (DipMāori / Tahu Māori) on Te Kawa a Māui - The School of Māori Studies;
• Certificate in Deaf Studies (Teaching NZSL) (CertDeafStud (Teaching NZSL)  on the School of Linguistics and Applied Language Studies; and
• English Proficiency Programme (EPP) on the School of Linguistics and Applied Language Studies

The TEC Information for Learners initiative could result in prescriptive requirements for UG degree pages. At the current time, not enough is known to plan for this. Vic has a representative on the working group, but they are not part of Marketing/Web.

There is a risk that programme (or subject) pages on the old faculty and school sites is shared or surfaces in more places than we realise. Decommissioning pages would then cause other things to break. An alternative to decommissioning is to "deindex"(making the page hard to find) and stop linking to it, but leave it "live".

The budget won't stretch to a planning tool, despite our doubts that better content will make sufficient in-roads to the challenges of programme planning. Can we at least include the images of example programmes as is shown throughout GUS?

Can we draft a user story for an online version of the planning form used by Student Recruitment (not sure why we could call it Form A on the website!) and leave it in the back log?

Complexity of the more flexible degrees (especially the BA) may make for a large and complex page. How do we ensure that our approach remains usable, even for 40 odd majors?

This row is not the next step in content deliver, but a discussion on the two rows above. The table as it stands implies a linear approach (i.e. we will do all topic pages before doing the first programme page). My preference is that we do (i.e. research, write, load, and commission) "pairings" or "bundles" of a programme page with the matching topic pages. For example, we do the BAS programme with the architecture topic page, the BBSc programme page with the building science topic page, the BDI programme page with the design topic page. These bundles make up the releases to production, allowing us to deliver early (relatively) and often, so benefits accrue to the users and the university.

This only leaves a transition challenge to deal with. How can we ensure a good experience for all website users from the time we publish the first bundle until we publish the last? It might be many months and users will roam all over the topic-subject-programme offering. No matter whether they are viewing new or old pages they still need to understand where they are and have some unifying elements

I believe the solution is in the new taxonomy. We augment the topic nodes to (temporarily and as navigation only) include the subjects, then map each and every subject to the existing subject pages. This navigation could be integrated to the existing Homesite now (i.e. without any new topic or programme pages) and even deployed in production, dealing with many of the navigation bugs we would otherwise encounter when the first bundle goes live.

Then, as we release the programme-topic bundles we remove the temporary subject navigations and break the links to the old pages, replacing them with the new pages. From the time that the first bundle is live (say architecture) all users can use the taxonomy-based cascading navigation as the unifying element. We can add bundles as and when they are ready, incrementally converting the links from old subject pages to new topic pages.

There are some cases where this mapping is less than perfect, so a little "fudge factoring" will be required, but there is nothing too alarming.

VI might need their own version of this, given that they already have a listing page of sorts.

Another advantage of this approach is that it works well for topic pages that contain multiple subjects but each maps to only one programmes (e.g. Electronics and mechatronics in the Engineering and Computing mega-area). The topic page can go live when the first programme page is ready, with the second programme linking to the existing programme page, until such time as we rewrite the second programme page.

There is an issue where a subject maps to two programmes (Economics and also Public policy in a BCom and a BA; Actuarial science in a BCom and a BSc; Software and computer science, and also Electronics and mechatronics in a BE and a BSc; Development studies, Geography, Mathematics, Psychology, and Education & psychology can all be done in a Bsc and a BA; and finally Music can be done in a BMus and a BA). We are unable to decommission the subject page when the topic-first programme pairing goes live, because the major rules for the second programme would be lost. This only affects 9 subjects, 8 being the BA majors taught outside FHSS (6 of these are also majors in the BSc, 1 in the BCom and music (shared with NZSM and the challenges of another site)) and Actuarial science (BCom and BSc). I have thought of two options to address this issue:

1. Do the BA first: This would resolve 7-8 of the 9 instances, and we then deal with Actuarial science differently, manually. However, this robs us of any opportunity for quick wins, as programme maps to 18 of our 45 topics. It also means we do all our learning on the most complicated and varied of programmes, hardly in line with the agile manifesto, where we want to "fail early so we can succeed sooner".
2. De-index", not decommission: The subject page when we commission the first programme page and topic bundle. This would allow the page to be linked to from the second programme but be more difficult to find on the school site where it is located. Under this approach we would literally leave the BA until last, or at least until after both the BCom and BSc.

The Concrete Problem

The second issue (known as the concrete problem, derived not from it's weighty nature but rather the activity Paul was doing while he thought of it) is that most subject pages also contain a little information on PG programmes for that subject, with links off to appropriate school site pages covering the programme/qualification. If we de-index or remove these subject pages when the topic page and UG degree page goes live where will we direct PG interest to (until we have developed pages for all the PG programmes/qualifications)? There are a few options:

1. The best page on the school site, based on where the Homesite subject page currently links off to
2. A new Homesite PG programme page, based on pulling content through from school sites in to a new/modern style (so PG pages look like these UG ones)

With an approach for these known issues the main risk is going live with (one or more) releases during the main enrollment period. Good testing prior to go-line will reduce likelihood of this risk materialising, and a prompt response will minimise the impact. Maybe we can rate/rank this more formally in the project risk register. We could also 

Discussions with the faculties and schools impacted is important, as they need to understand the implications of the "mixed" user experience, as well as the benefits of having the new marketing material being used for this season's enrollment.

Interim changes to school and faculty sites

Until we redevelop all school and faculty sites we need an approach to keep them "aligned" with our new topic-programme page bundles. Given that they currently master the subjects and programmes, removing them incrementally will "degrade" the completeness of their apparent offering. While we eventually expect that "tags" will surface the list of subjects or topics taught or programmes administered (whether as a list or a widget that then lists) we will need a short-medium term solution. Linking is probably the easiest, with a little "word smithing" to ensure that a list of (say) subjects we teach can refer to those on older styled subject pagers and those on newer styled topic pages.Note that some topic s will contain subjects taught by more than one school, possibly even multiple faculties

Future Students (until renamed Study at Victoria).

Will pull through the VI.

Might be pulled through to a PG hub/zone, if and when one is created

Approximately 120 programme pages that map from topics and subjects (even though this is unlikely to be the primary path to discover them) to develop.

Decommission old PG programme pages when new PG programme pages go live.

Exclude PhD/doctoral/higher degrees, which will be handled in Phase 3 with FGR.

For many subjects there are a large number of PG programme options. We will probably have to help users distinguish/compare easily/quickly. This implies new data and maybe tools, as well as a possibly new "programme set" that should go live at the same time.

There are also pathways of "nested" qualification that will require special attention to display and deliver. An example is that in the same time as it takes to do an MBA one could do a certificate, a diploma and then a masters, giving three exist points and only requiring a small time/cost commitment for each qualification step.

PG user research to identify the user requirements, especially their information needs.

Most international students are PG, so input from the International Office is a requirement.

Needs that are so different that they can't be met by topics and/or programmes, requiring us to develop an entirely new approach.

The sheer number of programmes mean that this task will take quite some time. The Calendar often combines a certificate and a diploma in to the same set of rules. Can we do the same (i.e. combine some programmes pairings on to one page)?

Develop and deploy the templates and technology, then encourage people to start moving. Supported by training material?

All staff profiles must be moved before we decommission a faculty/school site. If we follow an opt in approach, what do we do with the profiles where staff have "created" a new one.

Can be surfaced on school/faculty sites, once these are built.

The current user stories sequence has profiles for general staff (and possibly PG students) available earlier, as they have simpler requirements

Solution for the various edge cases

Support from ITS, possibly Webstruxtures.

Engagement might have additional requirements for profiles?

Our proposed solution, while better and more consistent that the current practice, may still not cater to all types of profile need.

We may, in the short term, further complicate the staff profile space (giving Andrew Bredenkamp a 38th slide for his presentation).

That the content is valuable enough to keep/move and that a place can be found to put it.

If school specific it will be located on the new school site

Would include scholarships, support, etc.

I/A work on the Current Students hub

Core team capacity

Exclude FGR's faculty site and postgraduateLife, which will be handled in Phase 3.

If school specific it will be located on the new school site

I/A work on the Current Students hub

 Core team capacity

Exclude research centres, institutes and chairs, which will be handled in Phase 4, assuming that they are currently in their own site.

Where these entities have a web presence that is not a site, but part of a school or faculty site another approach is required. This would be to leave the appropriate page(s) live but not indexed, while decommissioning the rest of school/faculty site.

If school specific it will be located on the new school site

Engagement work

IA work

Core team capacity

Include the following at this time:

Alumni: Five schools and faculties only; could be moved to engagement hub, if one exists by then. If not, try Alumni,

Overseas exchanges: Move to Victoria Abroad

If COO is not fully implemented/rolled out we will need to create a page/space for outlines, at least temporarily.

Sites of some research centres are very similar to school sites, but we won't consider how to improve them until later.

See F&S proposal: A new approach to faculty and school content (v.2) for other risks related to the implementation of the approach. 

Differing faculty and school sites this long (even though I am not estimating the time) might be a point of discussion, as expectations are for results/deliverables much earlier. 

Traffic to these sites will continue to decline, partly the continued aging, but more so because we are decommissioning the busiest areas in the rows above.