As we deploy a new website for a faculty (and the associated schools) in WIP II Phase 2 we will disestablish the old one.This means that any content on the old site must be handled prior to decommissioning, either covered by newly written content (probably either on the new faculty site or elsewhere on Homesite) or dropped/deleted (a legitimate option for some content).
In the current delivery approach:
- Phase 3 covers
- postgraduate information - all postgraduate degrees/programmes, the Faculty of Graduate Research's site and http://www.victoria.ac.nz/postgradlife/
- short courses relevant to postgraduate students run by the Faculty of Graduate Research
- Phase 4 covers
- all (subject to final agreed scope) the sites for research centres, institutes and chairs
- Phase 5 - a number of student information sites.
As the project team's understanding of faculty and schools (current sites and the proposed future sitssites) has grown, we have realised that our proposed delivery approach can be improved.
The main direction for improvement lies in pruning content areas off all the existing faculty in repeat and school sites. This would be done by repeat "by domaincontent area" sweeps and school sites and rewriting it the content for the homesiteHomesite, all prior to redeveloping the first new faculty site.
How much do we prune off all F&S sites before starting to build the first new faculty site?
As we deploy a new faculty (and associated school(s)) website developed in WIP II Phase 2 we will disestablish the old one.This means that anything on the old site that is must be handled prior to decommissioning, with the content either covered somewhere else (new faculty site, or elsewhere on home site, or even elsewhere on the web) or dropped (a legitimate option for some content). Future stages will cover postgraduate information (phase 3), research centres/institutes and chairs (phase 4) and student information sites (phase 5).
Our current plan in phase This pruning, at least in part, will cover content that would otherwise be in a future stage, but where doing it earlier seems to make more sense. Each sweep would reduce the size and complexity of all the faculty and school sites, so that eventually the only content left is that which will be covered on the new site or dropped altogether. The project team all believe that this revised approach is better, as does Nathan.
This leaves some important questions that need answers before an approach decision can be made.
Why are we already planning to approach CSP "by content area" not "by faculty"?
The short answer is because we must. Just think about our subjects on the old school sites (even where on homesite the content is still mastered on school sites). Our new approach is based around topic pages, not subject pages. While most topics consist of subjects from the same school (e.g. the topic Film and theatre contains two subjects, Film and Theatre), others cross schools (e.g. the topic History and classics contains five subjects from two schools), and some even cross faculties (e.g. the topic Environment contains six subjects from two faculties). Add to this the confusion for students deciding on what to study if we "bounced" them between old subject pages and new topic pages depending on what subject they wanted to look at next. As we have already accepted that it makes sense to prune the CSP information off all faculty and school sites, the first "by content area" sweep, the next question is . . . .
What is the most we could prune off all F&S sites before starting to build the first new faculty site?
Our current approach for Phase 2 is that CSP (and staff profile) content would be addressed "by domaincontent area" across all faculties, rather than as we address all the content on a specific faculty site (i.e." by faculty"). By implication, the remaining content on a faculty site would then be considered and either dropped/deleted or rewritten/carried forward. The big question is whether this "by topic" approach should be utilised further, extending this gradual whittling down/thinning/pruning of the faculty sites prior to the new replacement faculty site being developed?The two areas in contention are information for postgraduate students and research information. Should these be tackled "by domain" or
There are currently three areas in contention for also being addressed "by content area" before we start on building the first new faculty site. These are in common to all/most faculties, have a significant volume of content (i.e. number of pages), with clear target areas on Homesite.
- Postgraduate: Programmes, information, forms, etc on faculty and schools sites.
- Excluding Subjects which will be done in Phase 2 and FGR's faculty site and postgraduateLife, which will be handled in Phase 3.
- Research: Information for, on and about research (including funding, etc) that is currently in faculty and school sites.
- Excluding the research centres, institutes and chairs, which will be handled in Phase 4.
- Information to support current students: information that is in common to other faculties and/or has a natural home in the Current Students hub on Homesite.
- Excluding current student information that is unique to a faculty and/or does not have a natural home in Current Students (until more work here is done, be that I/A or refactoring).
- Excluding current student information that is unique to a faculty and/or does not have a natural home in Current Students (until more work here is done, be that I/A or refactoring).
All other content on faculty and school sites will be dealt with on a "by faculty" basis.
How do we decide on where to change from "by content area" to "by faculty"?
In documenting the opinions of the various stakeholders:
The project team members
...
On balance I propose that we approach this in the following, prioritised manner:
...
and Nathan are in agreement to attempt and prune off as much as possible from all the existing faculty sites before engaging with building a new site for the first faculty.
Some guidelines and limits to this view are:
- Follow "by content area" so long as the domain is common to all/most faculties, contains a significant volume of content, and has a clear target area on Homesite where the current I/A and core team resourcing can "receive" this content. If the answer to most of these is not yes then the content could probably stay on the old site until the "by faculty" approach deals with it.
- Content that could not be moved - but ought - can be parked in a temporary and ring-fenced page/section on the new faculty site until resources or timing is ripe to deal with it properly.
- Stand-alone sites that are specifically mentioned in the high level scope for another stage should remain unchanged until that stage.
- Resist the temptation to perpetuate the life of the old sites by surfacing new content on the old faculty and school sites, even if it seems to meet a short term objective. It will be tempting, but is likely to extend the time span for disabling the old site.
- Content with low usage/unique views could be dealt with by any method, any time. If few people are looking at it then lets not stew over how and when to handle it. The lower the usage the less we need to weight or consider the impact on users.
- Avoid having more instances of the truth than we currently have. This means we try to turn pages off as there are replacement pages available and live.
What are the implications of following the "by content area" approach further than initially intended?
- More redirecting: area being pruned will require an audit and plan for the links to that area from elsewhere, especially on the old faculty site it is coming from. Sometimes we might be able to enable the new content on Homesite and leave the old working on the old site without any great disadvantage. Making changes on a stable, albeit old site introduces risk. While testing can mitigate this risk, it costs and is unlikely to entirely eliminate it.
- By domain is likely to extend the elapsed time over which we need contact with the web admins in faculty and schools. However, it will be less intense on any one faculty or person, so on balance is probably a better idea. It also gives us more opportunities to win people over and show what the new content looks like in on Homesite before we disable their old faculty site.
- I am unclear if one approach is more efficient (i.e. quicker/cheaper) over all.
- I am unclear if one approach has less workload impact on the core team. Having said this it is clear that doing things well will place high demands on the core team, both the impact on the I/A work and those curating content on Homesite.
- URL's: We would have less flexibility to reuse existing urls for the new topic pages until such time as the old school and faculty sites are disabled, freeing up some more desirable urls (e.g. www.victoria.ac.nz/design )
When do we require a decision on the approach?
Although it is comforting to have an approach decided well ahead of time (mainly so we can communicate it to others) we are continually learning how to do WIP better and as such might make a better decision if we left it until later. Maybe the best compromise is to have an agreed approach at any stage, yet be open to refining the approach as we learn more. This means we could agree on an approach now (maybe even the old we are already following) but review this as we near the end of CSP.
How do we guide users to new information on old F&S sites?
No matter whether we only prune CSP (and staff) before moving to a "by faculty" approach or do subsequent "by domaincontent area" sweeps we will have to help users navigate between the old faculty site and the new content on home site. The following are guidelines (not rules) on how to approach this temporary transition period:
- Do not display new content on the old sites: We want to move users to the new site, not retain them on the old faculty era sites
- Redirect/guide users to the smallest number of points possible on the new site: Lets minimise the granularity of redirects to be as few as possible, both to save work and to guide users down a small number of supported/scaffolded paths.
And some questions:
- Do we have a preference to leave old content live, in parallel with the new content or to remove as much and as soon as possible and redirect more often?
- How often/granular do we unable new content? For example, would we do it by topic/programme or by megatopic and all related programmes?
...
What content could we move as is? Implications of reskinning pages?
We have not seen any content that we would want to move "as is" but accept that we will move "out of scope" content (e.g. short courses) without any changes. So yes, but only due to scope nit because the quality is good enough.
Other questions from Chrissi awaiting answers:
- What impact will it have on the testing required and how will it influence the remaining test plan
- What impact on delivery/timeframes – can we do this all by the end of 2016? Is there an approach that is quicker? Does that mean we cut corners?
- Content mapping – in addition to the spreadsheet on F&S v2 page > https://victoriauniversity.atlassian.net/wiki/pages/viewpage.action?pageId=16154703
- Will we still tackle PG sites and any research sites documented for phases 3 & 4 after this or as part of the F&S work?
- Implications of having 2 sites or two lots of content live?
- What content could we move as is? Implications of reskinning pages?
- What are the development views?
- Can we wait until staff profiles and CSP is done?Can we do relative sizing yet or is the approach required upfrontfront?