The proposal should be written as a markdown document in your repo (reports/m1_proposal.md), be max 1,000 words in length, and include the following sections:
Motivation and purpose
Description of the data
Research questions
App sketch and description
Section 4: App sketch & brief description
Create a sketch of what you envision your app to look like. Your sketch can be hand-drawn or put together using a graphics editor or slide show software. The sketch should be saved as img/sketch.png and linked in this section of the proposal so that the image shows up when reading the proposal on GitHub.
Complement the sketch with a high level description of the main components in the app interface and how the user will interact with it. You are not required to use terminology specific to Dash/Shiny (i.e. widgets, components, etc...).
Remember to be realistic about your expectations and plans since you will actually be implementing this app (but again, you will not be penalized if you need to adjust a bit in later milestones). It is better to design a slightly more limited app that you have time to implement well, instead of a complicated app that you don't have time to finish. At the same time, you cannot just make a single bar chart and call it a day; the app needs to have several input and output panels. You can view the dashboards from previous years students in the DSCI 532 showcase (might take several seconds to load) as a complexity target and to get inspiration for your final app. Your TA will be able to help you with this as well, and provide feedback on whether your app is too simple or too complex.
Example description:
The app contains a landing page that shows the distribution (depending on data type, bar chart, density chart etc) of dataset factors (hypertension, physical disabilities etc.) colored coded according to whether patients showed up or didn't show up for an appointment. From a dropdown list, users can filter out variables from the distribution display, by patient demographics (i.e. only show female patients), by appointment data (i.e. if SMS was sent), and finally by the date range of appointments. A different dropdown menu will allow users to re-order variables according to the probability of patients being a no-show or in alphabetical order to comorbidities. Users can compare the distribution of co-morbidities by scrolling down through the app interface.
yhan178
commented
8 months ago
The proposal should be written as a markdown document in your repo (reports/m1_proposal.md), be max 1,000 words in length, and include the following sections:
Motivation and purpose Description of the data Research questions App sketch and description
Section 4: App sketch & brief description
Create a sketch of what you envision your app to look like. Your sketch can be hand-drawn or put together using a graphics editor or slide show software. The sketch should be saved as img/sketch.png and linked in this section of the proposal so that the image shows up when reading the proposal on GitHub.
Complement the sketch with a high level description of the main components in the app interface and how the user will interact with it. You are not required to use terminology specific to Dash/Shiny (i.e. widgets, components, etc...).
Remember to be realistic about your expectations and plans since you will actually be implementing this app (but again, you will not be penalized if you need to adjust a bit in later milestones). It is better to design a slightly more limited app that you have time to implement well, instead of a complicated app that you don't have time to finish. At the same time, you cannot just make a single bar chart and call it a day; the app needs to have several input and output panels. You can view the dashboards from previous years students in the DSCI 532 showcase (might take several seconds to load) as a complexity target and to get inspiration for your final app. Your TA will be able to help you with this as well, and provide feedback on whether your app is too simple or too complex.
Example description:
The app contains a landing page that shows the distribution (depending on data type, bar chart, density chart etc) of dataset factors (hypertension, physical disabilities etc.) colored coded according to whether patients showed up or didn't show up for an appointment. From a dropdown list, users can filter out variables from the distribution display, by patient demographics (i.e. only show female patients), by appointment data (i.e. if SMS was sent), and finally by the date range of appointments. A different dropdown menu will allow users to re-order variables according to the probability of patients being a no-show or in alphabetical order to comorbidities. Users can compare the distribution of co-morbidities by scrolling down through the app interface.