For each app we worked on this semester, there is one type of user (volunteer and admin) per app. The volunteers will continue to use the existing deployed volunteer portal while the admin will now have their own admin portal.
Access
The Admin portal will be deployed as a separate app, so a URL link to a deployed web app will be provided to the admin and the admin can access the portal just like how people can access any website.
Video
We plan to conduct a run-through of the administrator portal via Zoom. This will be recorded so that the client can view it after the meeting. This will let them ask any questions they may have and refer to the recording later if need be.
Manual
We will create a document (manual) that guides them on how to access their admin portal and some of the features that we’ve created. We also plan on using the landing page of the admin portal, or another page on the website to provide a quick guide on how to use it, so the admin will not have to open the provided manual frequently and can access the most important information immediately from the web app.
FAQs
There will also be an FAQ section of the manual that we create so that if there are new admins that need access, they can have their commonly asked questions answered. This FAQ will also likely be included on the landing page of the admin portal so the admin will not have to open the document when it comes to the most common questions they may have.
Developer Docs
Our client is a repeat client from last semester, so there is a possibility that the client would want to extend this project’s work with another COMP 523 team in a later semester. To prepare for this, we will clean up the code once all functionality is implemented and write up a readme doc on Github, as well as put comments in the codebase. Currently, a lot of the code is not optimized for performance and extendibility, so if we are unable to address those issues by the end of the semester, we will make a note of it in a separate doc that will be shared to future developers to get them up to speed on things that can immediately be worked on. In addition to pointing developers towards immediate fixes that can be made, these developer docs will also explain what each component in the code does at a high-level to avoid having to write length comments in the codebase.
Existing Docs
For the volunteer app, we only made performance and UI improvements, so the volunteers will access and use the app in the same way they are currently using it. The following information is the documentation for the volunteer app from last semester’s team (who created and deployed the volunteer app):
————————————————————————-
The following are items for them to have a well-informed user experience:
Access
The WakeSmiles web application will be linked on their own homepage, so there’s no need for a document that can help the volunteers access the webpage.
FAQs
We will post an FAQ on the WakeSmiles homepage so that if there’s any questions about how to set up their account and access items, we can answer them directly. For visual learners, we will have screenshots and arrows pointing to items that we’re referring to.
After talking to our client, she requested a blurb with “Please note” statements for volunteers to note before entering the platform.
Video
We will also conduct a run-through with the client and the client’s intern and show them the volunteer end so that they’re able to answer any volunteer questions if need be.
Services Document
We will also leave word documentation of any services that we’ve used so that if there are any problems that arise after our semester is over, the administrators may be able to refer to it to fix the problem.
After talking to our client, she requested for this document to only be visible to the administrators.
For the admin portal, the following resources will be available to help the admin use the new portal, as well as enable future work on this project.