Working draft: PS revised on 7/1/16
| Proposed order | Project phase | Content area | Current location(s) | Proposed location(s)
| Delivery approach (to move from current to proposed) | Implications | Dependencies | Risks (or in risk register) | |||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Phase 2 | Topics (and associated subjects) | 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 page/content, with "one content (i.e. one "asset ID").
. | Future Students (until renamed Study at Victoria). Will pull through the to VI Either 'Remove'. 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:
| Subjects that are PG only 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
| 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 programme PG pages , until we are able to rewrite them.
| (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.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? | |
| 2 | Phase 2 | Undergraduate degree programme pages | UG degrees exist on faculty sites, school sites, Future Students and Victoria International (VI). They are likely to be based on the same page/content, with "one content (i.e. one "asset ID"). | Future Students (until renamed Study at Victoria). Will pull through the VI. 'Remove'. 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 degreeprogramme 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:
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.
| 8 | 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:
| |||
| 3 | |||||||||||
| 4 | |||||||||||
| 5 | |||||||||||
| 6 | |||||||||||
| 7 | Implication of COO on f&s: Need page/space for outlines until COO is fully operational. | ||||||||||
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? | |||||||||||
| 3 | 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:
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:
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 | ||||||||||
| 4 | Phase 2 | Postgraduate programme pages | PG programmes 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 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)?
| |||
| 5 | Phase 2 | Staff profiles | Staff profiles exist on school and faculty pages (as well as elsewhere), in different places and using different methods | Homesite, exact location TBD | 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).
| |||
| 6 | Phase 2 | Information for current UG students | Information, forms and resources for current UG students exist on faculty sites, school sites, and Future Students. It is unlikely that it is the same content (i.e. one "asset ID") but 'Tash can probably confirm. | Homesite, exact location TBD | By content area: Remove all the UG student information and resources from all old school and faculty sites, sort it to remove duplication, and find a "home" for it on Homesite (assuming that it is not already there). | 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 | ||||
| 7 | Phase 2 | Information for current PG students | Information, forms and resources for current PG students exist on faculty sites, school sites, and Future Students. It is unlikely that it is the same content (i.e. one "asset ID") but 'Tash can probably confirm. | Homesite, exact location TBD | By content area: Remove all the PG student information and resources from all old school and faculty sites, sort it to remove duplication, and find a "home" for it on Homesite (assuming that it is not already there). | 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 | The experience for PG students, an important customer group, remains suboptimal. | |||
| 8 | Phase 2 | Research information | Information for, on and about research (including funding, etc) exist on faculty sites, school sites, and Future Students. It is unlikely that it is the same content (i.e. one "asset ID") but 'Tash can probably confirm. | Homesite, exact location TBD | By content area: Remove all the research information from all old school and faculty sites, sort it to remove duplication, and find a "home" for it on Homesite (assuming that it is not already there). | 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 | These will wait a long time and some are already long overdue for attention | |||
| 9 | Phase 2 | Other content still to be identified. | Information currently on most school and faculty sites, required going forward but unlikely to be located on the new school and faculty sites. | Homesite, exact location TBD | By content area: Remove all this content from all old school and faculty sites, sort it to remove duplication, and find a "home" for it on Homesite (assuming that it is not already there). | A place holder for areas we haven't yet identified, or are not yet well placed to assess. Recognises that we might want to follow the "by content area" approach for longer before starting the first faculty site. | |||||
| 10 | Phase 2 | School and faculty sites | School and faculty information exist on faculty sites and school sites. | Homesite, exact location TBD | Develop new content for the new sites. Any content or media that is "reused" will be loaded again in the new location. | 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. | |||
| 11 | Phase 3 | FGR site and postgraduateLife | |||||||||
| 912 | Phase 4 | Research centres, institutes and chairs | |||||||||