We were able to incrementally re-structure the previous front-end of the website to adjust for the multidashboard feature. We would show our client and our users the updates on a weekly basis, to ensure that the fine details and design choices were up
to standard and provided a good user experience. We also included better media queries to support different mobile devices which have varying screen sizes.
For some visualisations, such as displaying tables with many coloumns, mobile devices would need to rotate their screens, therefore if there was a way to indicate (via an alert dialog) to the user to rotate their screen, it would
improve the overall user experience of our web application.
Furthermore, the overall theme was kept consistent and the dark mode works as expected and is intuitive to use. Where possible we tried to reduce the amount of whitespace, but there is still improvement in this area.
Overall, we successfully focused on usability while maintaining HCI design principles such as visibility, consistency, and mapping throughout the front-end development of the web application.
All requirements of our system have been met, and clinicians can begin using the system. Our application is scalable which means that platform adminsitrators can easily add new health boards and hospitals into the system and their respective users to
control their accounts. From which Health board users can add new hospitals and Hospital users can create new departments. Finally, Department Managers can add new clincians. All invitations are done by superiors sending a single join
url to their staff and the registration process is carried out by keycloak. This could have been improved if the invitation system was handled automatically by our system via an email, rather than the user having to manually do it
themselves, which would save time for users.
All dependencies used in our web application are popular and open-source. Our authentication and role-assignment processes are offloaded to Keycloak, which is also open-source, making it highly improbable to have security vulnerabilities.
Overall, our application is stable and is able to run smoothly on all devices. The tests written to render individual front-end components help to support the stability of the application.
The application is currently running on a Linode server with only 1 Core and 1GB of RAM. Therefore, it is limited in terms of handling a high number of requests to the server. In the future, upgrading the current server to a new
one with more processing power and storage space will be a priority.
Other factors that can rarely affect stability on the user's end include:
- poor internet connection
- poor system hardware
- Accessing the web application on an unsupported web browser
From our requirements we wanted our web application to be responsive as most users will be using it on range of devices. Therefore, we were able to achieve this using media queries.
Our project aimed to be accessible by all clincians via most web browsers. Currently, our end-to-end tests use the puppeteer api to instantiate visual tests of the firefox and google chrome browsers. From our tests, we can conclude
that our project is compatible with chromium web browsers. For future development, we could conduct the same tests for other web browsers(such as Safari) to ensure full functionality accross all web browsers. In terms of accessibility
we could have improved our project by using the ARIA and WAI-ARIA standards. This would have been a priority for future development.
Going into the project, we knew that the level of code quality had to be maintained and improved where necessary. We wanted to prevent any confusion for future developers who undertake the next iteration of the project.
Technologies used to help maintain code quality:
a) Prettier - To ensure code formatting was kept consistent (spacing, line wrapping, indentation) accross most files in our project.
b) Eslint - To detect and fix general quality issues, such as unused variables and functions, missing semicolons, etc.
Along with our code quality tools, we further extended our documentation on our github repository in the form of README files, which highlight the architecture, deployment and getting started for the next developers who take on
the project.
During development major changes were made to the backend, therefore using swagger and the OpenAPI specification we could document the REST API including the responses and parameters. It is currently hosted on our github pages
and can be found
here
We also included workflows built in to our github repository so that changes made to the main branch would automatically generate documentation for our API, Test frontend components and deploy to our linode server. We could have
developed this further to include automated tests for the backend and e2e. Although, on our local machines we are able to pass all unit tests.
We primarily used trello to communicate with our client about general updates and and to keep track of our progress in stages. It also helped us monitor completed tasks from each member during the development of the project.
The team created our own telegram group chat for effective daily communications
For immediate responses to our client we used a whatsapp group chat.
The team would meet via zoom to discuss about deliverables needed for the module, conduct pair programming and talk about future steps we would take in order to achieve our goals.
While we thought that the team had continuous and effective communication with one another, we encountered bugs during our development stage. Therefore, the use of github issues would have been great to keep track of new tasks
and existing bugs on our system.