...
Academic Staff vs General staff vs Postgraduate Students
There is the issue as to whether we should be creating staff pages for general staff or not.
From a technical perspective, I believe it will be more work trying to filter out which staff members are Academic and making sure only they have access to staff pages. The results from the GSA currently don't seem to distinguish between them, and it gets even more complicated when you try and accommodate staff members with Academic roles as well as General roles.
This will possibly mean that general staff members are provided with options to list "Research Interests" or other Academic values. However, I believe that this will be unlikely to cause an issue, and may be beneficial to a few of the general staff members who may have publications or research interests that may be of value.
Migration to new system
By default, once the new system goes live, everyone who has an entry in vicPhone will have access to a staff page at the new staff-directory location.
This will be automatically populated with values that are currently existing in vicPhone, for example phone numbers, addresses, research interest (definitive list to come).
However, the majority of content on existing staff pages is manually managed within squiz, as such there doesn't seem to be a clear way to automatically migrate this content across.
Because of this, the new staff pages will not be accessible via search until the staff member goes to the page and edits it for the first time. This will then tell the GSA that this page is now live, and will supercede the old staff pages.
If a faculty is being replaced, all staff will be alerted that they have a deadline for them to migrate their content to the new system. Once this date has passed, the staff pages in the existing faculty sites will no longer be accessible. (Technically, the pages will still be in squiz, but will no longer have a url associated with them, meaning that if required the web team will still be able to access the archived pages, however we are hoping that this will be used only for exceptional cases)
Otherwise, all staff members will be able to access their pages to update them. The issue here is that this content will then need to go into their old staff profile pages before their Awesome new Faculty pages arrive. I believe for this we could do something similar to the existing stafflist functionality. On existing staff pages, the existing content could be replaced by [newstaff] Andrew Bredenkamp [/newstaff]. This will be a custom interface that will return html of new custom content in the staff directory and embed it in their page. Like the stafflist, this will be dynamically generated, so that if the staff member were to change their details in the new staff directory, the changes will be automatically updated on their existing staff pages.
Issues
For editing a staff page, would it be better for
A) a staff member to be presented with their page and editable fields as shown in the picture above
B) go to a central 'update my details' form (similar to how it is managed now)
They are both good options, but I believe this comes down to a usability issue. Joe Lobotka (Unlicensed) Would you care to weigh in on what you think would be best?
How will searching manage new and old staff pages.
Once the new system is live, and we have a mix of new and old staff pages, what happens when someone searches for a person who has new and old staff pages.
One of the main goals of this project is to remove duplication in the search results. I think the idea that, if staff pages exist already and a staff member has not edited or marked the new staff profile as live, only the old pages are shown in search results. Once the page is made live, old pages are removed from the GSA, and it only returns the new staff-profiles options. UNLESS the search is initiated from within the new staff profiles system.
Other staff widgets
I.e. featured researcher widget. Existing stafflist functionality.
Can we develop this new platform in such a way that this functionality remains without needing to rewrite /rework them all? I believe as we are only adding to values in the database, not removing or modifying them, that the existing widgets should work more or less the same.
I am concerned though that there may be other widgets or functions that we are not aware of that could be affected.
Workflow
Having a staff member be able to edit only their page seems like it would be relatively simple. We can (hopefully) use the F5 to authenticate whether the user is logged in and provide them editing options as a result of this. However, we will most likely want staff pages to be editable by administrators in their school/faculty. This is normally handled well in squiz, but if we are using a new platform we would need to work out a new permissions and workflow system to manage this. Could this potentially be done with groups in Active Directory?
URL
How should the URL look. a pretty minor detail, but would it be better for instance to have www.victoria.ac.nz/staff-directory/andrew/bredenkamp or andrew-bredenkamp. Or perhaps staff.victoria.ac.nz/andrewbredenkamp?
Searching by Roles
Currently if you want to list the head of a faculty, you make a stafflist, and put the email address of the faculty head. It seems this could be better managed if we could change this to simply be [stafflist] Head of Psychology [/stafflist]. We could also use this to automatically provide a list of all lecturors in a department, all administrative staff etc. The details of how this would be managed are still to be ironed out, but I feel it could be a very useful feature that could cut down on labour for the web team in the long run.
Staff members with the same name
If we are to use the name as a unique identifier for the system the situation arises that two separate staff members with the same name will end up sharing a staff page. The current solution for this seems to be simply using the initial of their middle name:
http://www.victoria.ac.nz/search?q=michelle+clarke&site=people_search_collection
Howver, this is doesn't cover the issue of staff members not having, or sharing a middle name as well. This is really an issue with the underlying system and not something we have much control over, so it may simply be that the staff profile page for michelle d. clarke is staff-directory/michelle-d-clarke, and if someone were to go to staff-directory/michelle-clarke there would be a link up the top saying "Did you mean Michelle D. Clarke?".