(temporarily housed here until a better location can be thought of)
New Staff Profile Page
Following on from the work Paul Seiler (Unlicensed) has done here:
WIP-248 - Getting issue details... STATUS
This page will discuss the technical details of the options or providing these services.
A new staff page will look something like this:
It will provide separate areas for the different roles people will have. It will allow for extra roles/contact details for a staff member to add. As well as allowing for custom values such as About Me and links to other websites, it will include automatically generated values such as "Currently Teaching" and "Publications". If any of these values are empty, they will simply not show on the site. (in the picture, Publications hidden is provided simply as an example. This will not show in a live version).
If a person is logged in and they have permissions to edit the page (it is either their page, or they are an administrator of that staff member), they will see an "Edit" button allowing them to edit the page.
The 'Edit Page' will look (very roughly) like this:
Values that cannot be edited on this page will either be greyed out, or surrounded by a red border with a message linking them to information on why these values are not editable, and how they can go about getting them updated.
Our goal is to try and have as few non-editable values as possible, but due to the restrictions on the data sources, it will unfortunately be inevitable.
All other values will be input fields, which will be automatically populated with existing content (or left blank where there is none).
A future feature that is displayed here is the option for a staff member to make certain sections only available to students and staff members, staff members only, or not visible.
Technical Information of new system
Following on from the success of COO, I think Staff Profiles could follow a similar process.
Each staff member page is really a call to the GSA to get a staff profile based on the parameters passed in by the url. E.g. victoria.ac.nz/staff-directory/andrew-bredenkamp would ask the GSA to return the staff profile page for all staff members in the "staff directory" collection matching the name Andrew+Bredenkamp. Putting aside the issue of staff members with the same name (which I will deal with below), this will return either one value with all their staff information to display, or multiple values for each of the roles this person has. The page will then interpret this data and display it accordingly. It will use the 'primary' role as the repository of new custom information, and use any extra returned values to create contact details 'cards'.
Potential issues with this model:
If someone associates all their data with a role, which then later gets removed/turned into another role, all their customisations could dissapear.
- Potential solution: ensure that roles have a grace period before they are removed from the database, and alert a staff member of the issue and make sure they select a new role as their primary so the information is not lost
Requires a new JSON blob to be added to the VicPhone database.
Another potential option for the way staff are stored in the database, is to find a reliable definitive list of all staff members without duplications and use this to create a new clean database of staff members. When a staff page is accessed, do another call to the old database to get the details of the multiple roles they may have. The staff member will then also be able to mark which of these roles is their primary role when they edit their staff page.
E.g. Staff page for Andrew Bredenkamp is loaded - First call goes to vicPhone.cleanDatabase which returns the new information for the Staff Member of Andrew, not including any information about existing roles. The page then calls vicPhone.oldDatabase for a list of all the roles Andrew Bredenkamp is associated with. This returns "Andrew Bredenkamp, Extreme Mountain Boarder. Ph 04 123 4567" as well as "AProf. Andrew Bredenkamp, Deep Sea Roller Blade Enthusiast. Ph. 04 532 2345. Address 12 Ocean Avenue, Pacific Ocean". These are then turned into contact cards and inserted on Andrews Staff Page. Andrew decides that, while his love of roller blade-ing is astounding, it is his work at Mountain Boarding that people will most be interested in, so he selects that as his primary role.
Potential issues with this model:
Requires creating a new database of staff members
- This may also turn out to be a benefit, as it will be a database we have control and access over, meaning we will have complete control over what values are stored and accessed, something we are very limited in with our current model. However, it will increase development time.
A new database means yet another repository of staff information
- Totally valid concern, but this really just taking the blob that would be in vicPhone, and allowing us to have more control over it.
Would require us finding a clean, maintained list of all staff members.
- Does this even exist??
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.