INFO30005 2022 Group Project: Instructions page 1 INFO30005 Project: Instructions In this semester-long group project you will practice the skills and tools you learn in class by doing web design and development with a team. Your task is to design and build a web application that meets the requirements provided to you in the separate Business Requirements document. Your Group Projects will be conducted in groups of 5 students. All group members must be enrolled in the same weekly tutorial, and must attend the tutorial every week. (Absences must be justified in writing.) Groups will need to do substantial work outside tutorials as well. Deliverables: overview To help you make continual progress, and to provide multiple opportunities for feedback, the project is divided into three deliverables. All of these are group (rather than individual) submissions. They sum to 50% of your whole- of-semester assessment. # Deliverable Due % 1 UI prototype + some HTML / CSS files week 4 10 2 One complete feature: client + server + database week 8 10 3 Complete web app + source code week 11 30 Each deliverable is due by midnight Friday of the relevant week, Melbourne time. Technologies and Tools For equity reasons, you must use technologies taught in INFO30005 to build your web app. the web stack is: Node, Express, Handlebars, MongoDB supported by: authentication using Passport, database access using Mongoose the programming language is: JavaScript codebase is maintained on: GitHub web app is deployed to cloud platforms: Heroku, Atlas. For prototyping we recommend and teach Adobe Xd, but will allow alternatives such as Figma on these conditions: alternatives will not be taught or supported, requirements for the deliverable and marking standards will not change. Figure 1: web dev team at work INFO30005 2022 Group Project: Instructions page 2 Deliverable 1: details Your first deliverable is: Design your web app’s UI, and make a clickable prototype using e.g. Adobe Xd (7%) Implement two of the web pages in HTML and CSS (3%) Make clickable prototypes of both the patient and clinician systems. Include all of the screens required to fulfill the business requirements. The patient prototype need only show phone- sized screens, while the clinician prototype need only show desktop-sized screens. Implement in HTML/CSS the two static webpages “About diabetes” and “About this website”. They should share the same external CSS file. Submit via Canvas: a link (URL) to your Xd prototype a screenshot of your Xd project showing all artboards a link to your GitHub repo containing two HTML files and one CSS file. Your work will be assessed according to these criteria: All business requirements are captured in the prototype Realistic data are shown on screens Interaction design and screen layout are of good quality HTML and CSS code is of good quality. Figure 2: Example screenshot of artboards in an Xd project INFO30005 2022 Group Project: Instructions page 3 Deliverable 2: details By the end of week 8, i.e. midnight on Friday 29th April, you should deliver one working end- to-end feature in your application, which enables a patient to enter some health data, and their clinician to see the data. For D2, your app should support the following scenario: Patient Pat has logged in and is viewing their home screen. Pat decides to enter today’s blood glucose data, with an accompanying comment. This data is stored correctly in a MongoDB database on Atlas. Pat’s screen changes to show that today’s glucose data has been entered. Clinician Chris views their dashboard and sees the new data that Pat entered. The number is highlighted if it is outside Pat’s safety threshold. Note that many aspects of your app are not yet required in Deliverable 2: Logins (authentication via Passport) are not required in D2. Instead, you can simply hard-code Pat’s and Chris’s identities in your code. Validation of data entry is not required in D2. Your app can assume that Pat enters appropriate data. Software features described in the Requirements document but not listed on this page of the Instructions are not required in D2. You may manually place, in your database or screens, data other than what is entered in the scenario above; for example, Pat’s safety thresholds, or other patient details for display in Chris’s dashboard. Your group should submit a single PDF that contains: Group name / group members / tutorial and tutor details The URL of your patient home screen, running on Heroku The URL of your clinician dashboard screen, running on Heroku The URL of your repo on GitHub. Tell us which commit in your repo you want to be marked. (It must be dated before the submission deadline. This is so you can keep building D3 while we mark D2.) MongoDB connection string that allows the marker to inspect your database on Atlas. This is a group deliverable. It should be submitted by just one member of the group. Your work will be assessed according to these criteria: Markers can use your app to successfully step through the scenario above. UI design is of high quality. The patient UI works well on phone and desktop screens. HTML, CSS and JS code is high-quality. The database design (structure of data in MongoDB) is high-quality. See the submission page and rubric for further assessment details. INFO30005 2022 Group Project: Instructions page 4 Deliverable 3 details By the end of week 11, i.e. midnight on Friday 20th May, you should deliver
the final version of your web application, with source code, offering the features described in the Project Requirements document. Prepare your database for testing Make sure your database contains at least the following data for testing purposes: At least 10 patients, including patient ‘Pat’ At least 2 clinicians, including clinician ‘Chris’ Pat is assigned to enter some but not all of the 4 possible time-series At least 2 patients including Pat have made at least 10 daily data entries Pat has > 80% engagement rate and is ranked in the top 5 patients At least 5 comments have been entered by patients Submit one PDF that includes: Group name / group members / tutorial and tutor details URL of your patient login on Heroku URL of your clinician login on Heroku, if different to patient URL Usernames/passwords for patient Pat and clinician Chris URL of your repo on GitHub. State which commit should be marked. MongoDB connection string that allows the marker to inspect your database on Atlas. The app will be tested using the following procedure: Patient UI (10 marks) Item Description Max marks Log in Entering incorrect details should result in an error message, while correct details should proceed to the patient app 1 Info pages The two ‘about’ pages are visible, whether the patient is logged in or not. 1 Health data entry Data entry form only allows entry of time-series that have been prescribed for this patient. 1 Health data entry Patient can enter today’s data, and can attach a comment to each number. (Markers will enter data that are both within and outside this patient’s safety limits.) Data are stored appropriately, linked to patient, and timestamped. 1 Health data entry Patient doesn’t need to enter all today’s data at the same time. 1 View data Patient can view health data they have already entered, via an easily understandable layout, with dates/times visible. 1 Zheng Li D login & Security %Yi Assignment 2 2mprove went lnjia ☆ note & Message Bowen Boo Engagement related wage € New page for basic function : E G- INFO30005 2022 Group Project: Instructions page 5 View support messages Patient can see the current support message from their clinician. 1 Engagement badge Patient sees a badge if their engagement rate is over 80%. 1 Leader board Patient can see a leaderboard showing the top five patients by engagement rate. 1 Change password Patient can change their own password 1 Clinician UI (10 marks) Item Description Max marks Dashboard Shows a table-like display with one row for each of at least 10 patients, one of whom is patient Pat. 1 Today’s data In patient Pat’s row we can see the numbers that Pat entered today. Missing data, and numbers outside Pat’s safety limits, are clearly marked. 1 Manage patients Clicking on patient’s name takes clinician to a page that allows them to see that patient’s data. 1 Manage patients Clinician can change which time-series a patient can record. 1 Manage patients Clinician can change the safety limits for each of a patient’s time- series. 1 Support messages Clinician can change the current support message for patient. 1 View data Clinician can view each patient’s historical health data. 1 Clinical notes Clinician can view existing clinical notes and enter a new one. Notes are tied to a specific patient, and timestamped. 1 View patient comments Clinician has a page that shows all the recent patient comments. Clicking on a comment takes clinician to that patient’s page. 1 Register patient Clinician can register (add) a new patient to the system 1 Overall quality (10 marks) Item Description Max marks Security App uses Passport for security and authentication. 1 ☆ Boo Boo : Boo Boo Boo ☆ G- : D INFO30005 2022 Group Project: Instructions page 6 Password safety Passwords are encrypted in the database using bcrypt. 1 Input validation Data entry is validated, both client- and server-side. 2 Database structure Information about each user is stored as per Requirements. 1 Usability Usability is good, navigation between screens is logical. Date/times are displayed in a user-friendly way. 2 Screen design Screen design is of high quality. Patient UI is responsive. 2 Code Code is of high quality. 1 Bonus features Item Description Max marks Charts Numerical time-series can be viewed as charts. 1 Live alerts Clinician UI shows an alert if any patient enters data outside safety range. 1 Custom colours Patient can choose a colour-scheme for their UI. Preference is saved to database on a per-patient basis. 1 Bonus marks cannot increase the total mark for D3 beyond 30. A note on calculating engagement rates There is a potential problem regarding how to calculate a patient’s engagement rate. It is made complicated by another feature in the app – clinicians can change a patient’s data-entry requirements over time. This means that a patient’s engagement rate on a given day depends on the history of clinician actions regarding that patient, which requires a complex calculation. In response, teaching staff have decided to simplify the definition of engagement, as follows: On a given day, a patient is considered to have engaged, if they entered any data that day. Thus for example, if a patient has been registered for 20 days, and entered some data on 16 of those days, their current engagement rate is 80%. This will simplify what had become a complex calculation. [end of Instructions document] G-