...
When a policy maker checks the severity of one specific county, there is one customised colour bar with discrete number as indicator shown below the risk level graph. It can use colour to differentiate the severity among all counties
When a policy maker hovers on the specific county, there is one small black box pops up. It describes the risk level of that county in a simplified way.
When a policy maker clicks one specific county on the graph, there is one side bar on the right-hand side pops up, it contains three parts, first part above is including county name and risk level latest update date. Second part middle includes a status bar that shows the severity of that county based on the risk level. As well as infection rate and other related information. Third part at the bottom exists one line graph which records the change of the number of epidemic cases in past few days. This detailed information can bring a clear overview of the county during pandemic which gives policy maker makes appropriate decision.
When a policy maker checks the vaccinated rate of one specific county, the map type would be switched to Vaccinations graph. There is one customised colour bar from light colour to dark colour to indicate how large the vaccinated rate is. It uses colour to have a clear comparison of vaccinated rate between adjacent counties.
When a policy maker checks how many empty beds left, the map type would be switched to Staffed Beds graph. There is one customised colour bar from light colour to dark colour to indicate how many beds left in each county. It could make it possible for distributing medical power between counties because the complete data analysis of staffed beds and risk level provided in the visualisation. The policy makers can compare the risk level of the county they live in with their adjacent counties, as well as comparing the staffed beds left between them. Thus, it could show the possibility to borrow some beds from one county to another which dealing with the insufficient supply of beds for that county.
When a policy maker first go to the page of our website, it would pop up a model which contains the da link and confluence link. Thus, they can download the data as they want.
Limitations:
Problem 1:
Users cannot be alerted with risk level changes.
...
Responsibilities of Each Member
Roles | Member |
|---|
...
· Mashira was our main coder for the project, making up most of the backend work, which included the API connections and parsing data from the API to something that the frontend can use (usually involving converting it from JSON)
· Lin was one of the designers of the application, setting up and creating the front-end prototype of the website, as well as cleaning up and advising features that might have been either good or possibly unneeded. He also was the one who did the clean-up and Q&A of the program and the report.
· Avijit(?) was the one who worked on the API the most and created a new dataset and algorithm which allowed us to display all the information on the map.
...
Responsibilities Expected | Responsibilities Delivered | ||
|---|---|---|---|
Project manager |
|
| |
Frontend Developer |
|
| |
Backend Developer and Software Architect |
|
| |
Business Analyst |
| ||
Risk Analysis and Testing |
|
|
https://unswseng.atlassian.net/jira/software/projects/SENG3011/boards/46/roadmap
Deliverable 1
Lin mapped out the report, and was tasked with keeping everyone up to date and coordination of resources, and as such mapped out the project plan.
Mashira and Avijit were making plans for the API and the basic code, while Zifan was tasked with justifying the language and development environments.
...