Versions Compared

Key

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

Initial findings from Paul (taken from WIP-29

  • Pages are for use by students, staff and the wider public (media, researchers, staff in other organisations, etc)
  • Their purpose is to allow readers to find staff they are looking for and learn about the teaching/research/publication areas, and how to make contact.
  • The pages are a mixture of information drawn from up to seven (Access Management System, Research Master, Vic Phone, IPFX, MS AD, HR, and Banner) other systems and entered by staff (or administrative support people on their behalf)
  • The creation process is brittle, mainly due to the start-end dependencies of the integrated or up-stream systems but in part due to the complexity of the form and the infrequent nature of using it.
  • Despite the integration with many systems, the University is still poorly serviced by any sensible and authoritative identity store. Instead, different systems all master identity in their own way, all of which have strengths and weaknesses.
  • The core team have many requests for help to create and maintain these pages, each individually small but quite a time commitment in total
  • COO has brokered a deal with ITS to provide more/better identity data so course catalogue can construct a more complete view of a person.
  • Student workshops identified that they value high quality staff pages in course selection/enrollment decision, especially for high level papers and research options.
  • Considerably more important for the PG students than UG
  • Find a Researcher and the Media Guide both require high quality staff profiles to work well (or realise the intended benefits). From a quick look I believe they are probably both delivery poorly on compared to expectations, mainly due to the low/variable quality of the profile information but also due to "clunky" too design. Does anyone have any review results for these services?
  • Consider carefully the 3-tier model that Keith has developed, and if we support it focus on tier 2 and maybe 3. See https://victoriauniversity.atlassian.net/wiki/display/WIP/Examples+of+staff+content
  • Based on the findings I recommend that we seek a scope change for CSI to include staff profile pages as core data.
  • If agreed we would:

Deliver the following in WIP II, Phase II

  1. Build a new form to be used for the creation and maintenance of staff profile information that will:
    1. Draw data automatically where possible (using APIs, etc). For example, Symplectic can offer an API for this, whereas Research Master can not.
    2. Require users to enter data only if it can not be sourced from another system
    3. Can be pre-populated with existing profile information (is this possible? Desirable?)
  2. Produce some artefact to explain why better profiles (the audiences and what they want to see and possibly a small number of good profiles.

Advocate for these to be done elsewhere

  1. Solving the problem of multiple authoritative sources of identity. Our role would be to should lend support to the cause and contribute to any (ITS) project
  2. Encourage (or require?) staff to update their profiles
  3. Produce detailed guidelines and examples

Meeting with Keith B, Paul S and Andrew 20/05/15 (draft notes):


Issues:

  • Providing single authoritative source of data - ITS issue
  • Staff Directory - all written by Ian
  • Multiple sources - would require Ian and ITS resource wise to try and address this
  • IPFX - ITS (usually the blocker) - why is the authoritative source?  Origins as the phone directory.  
    • Could change focus away from this as final piece of data.  Change the relationship around and just take this information when it is available.

Data sources:

  • AMS - campus services
  • Banner = SSIP and SAS
  • IPFX - ITS (Product)
  • VicPhone - SQL DB that is ours (populated out of IPFX) - does not have persistent unique identifier
  • HR Database - ITS and HR (potential main authoritative source - but issues with visitors etc not in this system)
  • AD/Exchange - ITS (assumption this could be minimal data source - majority of staff will have entries in here - noting some edge cases). 
  • Research Master - research office

Options:

  • Could be managed centrally via web to create the profile - would have to be a manual extraction of data initially
  • Need to explore the data that can be extracted from these systems - Andrew could look at some of this?

Other:

  • For staff profiles, anything in additional information would have to fed into Squiz via dept admin currently
  • PBRF - research information could be derived from here going forward
  • Could potentially create a web form for staff to ingest data to be displayed on the site?
  • Web governance will play a big part in how we manage this, and where restrictions are put in place on who can edit what.  What should come from an authoritative central source, what can be managed manually.
  • Keith notes we should be aiming for structured data so we can auto generate, providing light guidelines on compliance, also providing links to staff members own sites as required