Amazing work Group 6! I really enjoyed going over your Dashboard. It is very well structured and presented, and your topic/motivation is very inspiring.

Below are a few thoughts on how the dashborad could be further improved:

• Layout of the bar chart on the right: As I navigated different countries, I noticed that the order of country vs average keeps flipping depending on alphabetic order. I thought it might be easier for the users to understand the context if you fix the average at the top or bottom, and fix the country on the other.
• Colouring of the bar chart: With the colouring, you can consider making it consistent with the colour scheme you are using on the map. So whichever is higher, average or country, gets a darker green and the other gets a lighter green.
• Content of the bar chart: I thought it might be helpful to also include the average of the continent the country is located in. For some values, there is some obvious variation across continents (for example, access to electricity is higher in NA and Europe, compared to Africa for sure), so we might be more interested in comparing the country-specific value against the continent average.
• Minor Layout change: Since you used a dark green background and white font for your title, consider changing the format of the cards' title to make it align with the overall title.

Overall, very nice work!

1. Create a release for M2, 0.2.0
2. submit one file on Gradescope link-to-release.ipynb, including:

• a single markdown cell with the link to your release on GitHub for this milestone
• also indicate whether you attempted the challenging question or not

make a splashboard and update font and colour

Hi team! I love this dashboard and this topic!
The green colour scheme suits the topic very well!

Here are a few of my thoughts on how the dashboard could be improved:

• Provide context. I think a brief description/overview of the dashboard and the data behind it would be useful, especially for someone who is looking at it for the first time. Your README does a great job of this but I think a little bit of context in the dashboard itself would be helpful.
• Show when the dashboard has been updated. Since there is so much data behind the scenes (which is great!), it takes a while for the dashboard to update when interacting with it. For example, when adjusting the year, it takes a few seconds for the map to update so it can appear as though there is no change from year to year when in reality it is just loading. Some way to show that the map has been updated would be helpful.
• Small aesthetic change. Making the title banner the same width as the cards below or intentionally smaller may look better.
• Minor change for tool tip on circle graphs. Adding '%' to the tooltip on the top right chart would make it explicit to users that "Value" is a percentage.

Overall, it's a great dashboard! Well done!

Major:

• Switch lines chart to two cards
• Color and styling in general, separate columns more clear? Not sure this is needed, but explore and see if you like it more.
• Map outline on hover, map click update right side?

Minor:

• Separation between map and other charts
• Different style for title, not serif font
• Switch map projection from mercator?
• Title mention "consumption" of left donut
• Remove three dots actions buttons because there are many overlapping ones.
• "Selected entity" to cameroon
• Color scale below map

Great job guys! I really enjoyed exploring your dashboard. It was very intuitive to use, and I could immediately understand how each filter interacted with the charts. It was interesting to learn about renewable energy in developing nations, and I can clearly see how your ideal user would interact with the dashboard.

Some constructive feedback:

• It would be really cool if you guys could enable country selection by clicking on a country in your world map. It would also be nice if users could zoom in on your world map, as it is hard to select or see the color of some of the smaller countries (especially in Europe).
• When I selected some countries ('United States' or 'Canada'), the financial flows bar chart did not have two bars, but only the average. It works as expected for most countries, but I noticed these edge cases when exploring.
• I have some concern over the use of the donut charts. It does add some interesting variation to the visualizations, but a bar chart might be a better implementation as it is much easier to visually estimate a proportion from a bar.
• I like that we can filter for dates, but I am curious why you guys chose to limit the filter to 5-year chunks? I understand that this way there will be more data to display, but I can imagine a user who is interested in exploring a more limited date range.
• I appreciate the simple design, but if you wanted to add some more visual contrast I think you guys could add some color to the cards so that the dashboard isn't just a white page with some charts on it. I do like the color schemes you chose for each chart, and I think they help communicate the data's story.
• A more generalized piece of feedback is that your README and milestone 1 proposal puts a lot of emphasis on developing nation's green energy potential, however this separation between developing and developed nations is not clear when using the dashboard. Presumably an expert would know which countries fell under which umbrella, but a layperson might appreciate you laying it out for them more clearly. Perhaps instead of comparing a country's access to energy or financial flows to the average, you could instead compare it to the average of developed countries and developing countries.
• Its not immediately clear to me what is meant by 'financial flow'. I couldn't find a clear definition in the README, and would appreciate a definition used somewhere, as it seems to be a fairly important metric.

Reword the milestone 2 reflection to include last minute changes to the dashboard

The environment configures correctly without explicitly adding a pip dependency, but throws a warning message that might spook potential users

• Add short description of the data and the dashboard's purpose to the dashboard itself. (Ian)
• Add percent symbols to the tooltip display for arc charts (Joey)
• Adjust width of title splashboard. (Joey)
• Prevent order of country vs average bars from flipping (Ian)
• Adjust arc chart colours: not beige also fossil fuel does not equal Other (Haley)

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 1: Motivation and Purpose
rubric={reasoning:12}

In a few sentences, provide motivation for why you are creating a dashboard:

Who is your target audience, and what role are you embodying?
What is the problem the target audience is facing and why is it important to solve?
How can your dashboard assist in solving this problem for the intended target audience?
You can read the Project background section for some rough ideas. Be brief and clear. Example writeup:

Our role: Data scientist consultancy firm

Target audience: Health care administrators

Missed medical appointments cost the healthcare system a lot of money and affects the quality of care. If we could understand which factors lead to missed appointments it may be possible to reduce their frequency and use the saved resources to improve patient outcomes. To address this challenge, we propose building a data visualization app that allows health care administrators to visually explore a dataset of missed appointments to identify common factors. Our app will show the distribution of factors contributing to appointment show/no show and allow users to explore different aspects of this data by filtering and re-ordering on different variables in order to compare factors that contribute to absence.

Meeting minutes:

1. Dataset selection. We decided to use a dataset on global energy data on Kaggle. See https://www.kaggle.com/datasets/anshtanwar/global-data-on-sustainable-energy/data
2. Project scope: We have engaged in comprehensive discussions regarding the scenario, key questions to address, and the target audience for the dashboard.
3. Dashboard design: We had a high level discussion about the dashboard's visual layout and user interface.
4. Team collaboration style: We have reached a consensus on preferring in-person meetings
5. Task allocation: We have distributed specific tasks to each team member.

Tasks are assigned as follows:

1. Get deployment done. Joey
2. Get the dashboard roughly done.

• Left world map. Ben
• Right charts - two bar chart. Joey
• Right chart - one pie chart. Hayley
• Right chart - partition chart. Ian
• compile files and improvement. Ben

3. Readme file - Hayley
4. Reflection - Ian

Improvements based on group discussion.

1. Replace the line chart with cards showing the country's GDP and population.
2. Map projection should be changes.
3. Need better color scheme, title styling.

1. Team reached a consensus on the preliminary sketch, setting the stage for dashboard development
2. Team worked on refining and compiling the project proposal.

• This is a short project, so compromises may need to be made: if you get stuck on a smaller feature, file an issue and move on.

• It's OK if you need to deviate a bit from the proposal during implementation, but make sure to write about it in the reflection section below.

• For this milestone, your app should have a minimum of six input + output components in total (e.g. 2 inputs (widgets) + 4 outputs (charts, tables, text, etc.)), with a minimum of two of each (so you can't have 0 inputs and 6 outputs).

  • Each of these six components should be linked to at least one callback.

• All the elements of your dashboards should be laid out in grid format using rows and columns, while following the best practices we have talked about during lectures.

  • E.g. the individual components should be assigned to variable names, that are then used in the layout.

• Your interface should be as self-documenting as possible, with appropriate labels for panes and widgets, and an overall title for the dashboard.

• Note that TAs will be grading your deployed app in a full-screen window. You don't need to worry about how it looks on a phone/narrow window.

• At the bottom of the page, include a short description of the app, who has made it, a link to the repo, and the date of the latest update/deployment.

• When selecting and implementing visualization, you are expected to follow the best practices taught in 531, or clearly explain in your proposal why you chose to deviate from them.

editing the bar chart callbacks so that the average is always on the bottom

Repository structure

create the following files in your repo root (this will be graded using a similar rubric as for M1 in 522):

• README.md (the project title and a summary of its purpose in ~3-4 sentences)

• LICENSE.md (include the license for both software and non-software content)

• CODE_OF_CONDUCT.md (include a citation if you used a template from elsewhere)

• CONTRIBUTING.md (include a citation if you used a template from elsewhere)

• src/app.py or src/app.R (this file can be empty for now, but indicates which language you are planning to use)

• data/raw/ (should inlucde your chosen raw data file(s); indicate in the proposal if you plan to load from an external source instead)

• notebooks/ (optional: if you start doing EDA, include your notebooks in this folder)

• environment.yml (can contain just the basics for now, e.g. the libraries for the dashboard, data wrangling, and vizualization; include version numbers)

• reports/m1_proposal.md

• img/sketch.png

Use what you learned in DSCI 522 to build a team work contract, formalizing how you will work together during this project.

• Your group should clearly document which parts of your proposal/sketch you have implemented in your dashboard so far and explain what is not yet implemented.
• For anything that you have done differently than in your proposal/sketch explain why (e.g. implementation difficulty, explanation for why the new approach is more effective, etc).
• It is important that you include what you are aware of is not working in your dashboard, so that your TAs can distinguish between features in development and bugs.
• You should also explain if you have intentionally deviated from any of the best practices that we learned in 531 regarding effective visualizations.
• Reflect on what you think your dashboard does well currently what its limitations are, and what are good potential future improvements and additions.
• This section should not be more than 500 words and be written to the file reports/m2-reflection.md in your GitHub repo.

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 2: Description of the data

In your proposal, briefly describe the dataset and the variables that you will visualize:

• Include how many rows and columns there are in the dataset (that you plan to use).
• There should be a clear link to how the dataset and the variables you describe will help you solve your target audience's problem.
• Indicate at least one new variable that you are planning to derive/engineer for your visualizations.
  -- If there are no new variables to derive, indicate what additional information you would have liked to have in the dataset to better be able to answer your research questions (even if it is impossible for you to engineer it).
• If you are planning to visualize a lot of columns, provide a high level description of the variable types rather than listing every single column.
  -- For example, indicate that the dataset contains a variety of categorical variables for demographics and provide a brief list rather than describing every single variable.
  -- You may also want to consider visualizing a smaller set of variables given the short duration of this project.
  To be able to include this information you might wish to perform a brief exploratory data analysis for you to grasp what could be interesting variables to look at in your data. We will not be grading the EDA aspect, but include your EDA notebooks in the public GitHub repo, so that you have everything in one place.

Example writeup:

We will be visualizing a dataset of approximately 300,000 missed patient appointments. Each appointment has 15 associated variables that describe the following characteristics, which we hypothesize could be helpful in determining why patient's miss their appointments:

• Patient demographics (patient_id, gender, age, etc)
• The health status of the patient (general_health_status, existing_conditions e.g. "Hypertension", "Physical disability")
• Information about the appointment itself (appointment_id, appointment_date)
• Whether the patient received a reminder about the appointment (reminder_sent)
• Whether the patient showed up (status)

Using this data we will also derive new variables, such as the time since the patient's last appointment (days_since_last_appointment) and which weekday the appointment was on (appointment_weekday), as it would be interesting to explore if these could be linked to the patient missing their appointment.

Implement one major and all minor

Major:

• #108

Minor:

• #99
• #107
• #100
• #103
• #102
• #101

Expand on the README file to be a welcoming place for anyone coming to your project for the first time. For your project, your README should cater to at least two groups of people:

1. Those interested in using your dashboard

• Include motivation behind your project and clearly explain what problem you are solving and why it is important.
• You do not have to include detailed usage instructions, just high level what they can do in your dashboard and the deployed link.
  This is a good example
• Include a link to your demo GIF in the README. It's sparks interest to see a demo of the app right away.
• Include a note on how to get support (e.g. opening an issue).

2. Those interesting in running the app locally, and potentially helping you develop your dashboard

• Potential contributors are interested in the above as well, but also need to know how they can install your app/dependencies and how to run it locally.
• Include a link to the contributing file, where they can find out more if they are interested in making contributions to the repo.

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 3: Research questions and usage scenarios

The purpose of this section is to get you to think in more detail about how your target audience will use the app you're designing and to account for these detailed needs in the proposal.

For this it can be helpful to create a brief persona description of a member in your intended target audience
Then, think about what they might want to do with your app and write small user story. User stories are typically written in a narrative style and include:

• The specific context/background of the user
• The overall goal of the user
• Tasks needed to reach that goal
• A hypothetical walkthrough of how the user would accomplish those tasks with your app
• The outcome/action that the user would take based on the information they find in the app
• An example usage scenario with tasks (tasks are indicated in square brackets)

Mary is a policy maker with the Canadian Ministry of Health and she wants to understand what factors lead to missed appointments in order to devise an intervention that improves attendance numbers. She wants to be able to [explore] a dataset in order to [compare] the effect of different variables on absenteeism and [identify] the most relevant variables around which to frame her intervention policy.

When Mary logs on to our "Missed Appointments app", she will see an overview of all the available variables in her dataset, according to the number of people that did or did not show up to their medical appointment. She can filter out variables for head-to-head comparisons, and explore which variables are most important in determining whether a patient will show up to their appointment. When she does so, Mary may e.g. notice that "physical disability" appears to be a strong predictor missing appointments, and in fact patients with a physical disability also have the largest number of missed appointments.

Based on her findings from using our app, Mary hypothesizes that patients with a physical disability could be having a hard time finding transportation to their appointments, and decides she needs to conduct a follow-on study since transportation information is not captured in her current dataset.

Note that in the above example, "physical disability" being an important variable is fictional and serves as an example of a possible outcome/action. For this milestone, you don't need to conduct an analysis of your data to figure out which variables are important and which are not. Instead, estimate what someone could find using your dashboard, and how they may use this information in a meaningful way. If you are using a Kaggle dataset, you may use their "Overview (inspiration)" to create your usage scenario.

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.

Following the instructions in the lecture, noting the following requirements:

• You should link your GitHub repo, but turn off the automatic deployment and instead manually deploy the commit that corresponds to this week's milestone release.
  • Updating your deployment after the deadline will give a late penalty. If you want your newest changes online, you can can use deploy previews for PRs as discussed during lecture.
• Set up PR deploy previews and make sure that they show up in at least three PRs in your repo this week.
• Remember to include version numbers for all packages in your requirements.txt file and to specifically include the gunicorn package.
  • I recommend creating requirements.txt manually, but you can use python -m pip list --format freeze > requirements.txt as a starting point, and then remove all the packages that are not required to run your app.
• Don't wait to deploy until Saturday night after you have implemented every single feature you want. You will not have time to solve potential issues.
  • Deploy early and check that things are working, then redeploy every now and then, especially after adding new package dependencies.
• Update the "About" section in your repo (the panel to the right on the repo home page) by clicking on the gear/cogwheel:
  • Include a one-sentence description of your project in the "Description" field.
  • Include the link to your deployed dashboard in the "Website" field.
  • Include ~3-5 keywords in the "Topics" field. For this project, these keywords should be related to the dashboard components and visualizations you are including, e.g. "slider", "dropdown", "map", etc.
• Create an animation of your app in action and save it as img/demo.gif.
  • You can record your screen while demoing how the app updates when you make selections in the input widgets. If you don't have a local program for converting video to GIF, I have found ezgif quite helpful in the past.

something short and sweet like:

This dashboard assesses potential for renewable energy development projects around the world, using data from the World Bank and International Energy Agency. The map on the left shows values of one selected metric for all countries, while the charts on the right show values of each metric for one selected country.

Hi Ben, Hayley, Ian, and Joey! Thanks for sharing your dashboard with me. Overall, I think it looks really good. I especially appreciate its clean design, clearly-labeled plots, and well-described use cases. See below for some of my comments in responses to the prompt questions given by Joel.

1. Is the app overall well-suited to the usage scenario and target audience?
Yes! I really like how the readme clearly states the problem / solution your dashboard addresses. Furthermore, I appreciate the description at the bottom of the dashboard which further addresses the target audience and describes the purpose of the dash. I think the amount of detail is the perfect amount to give an overall picture of the world and also zoom in on a country of interest. Very nice job.

2. Do you see some ways that the dashboard could be extended to better cater to the target audience or meet the specifications in the usage scenario?
I think it could be interesting to compare each country to the global average (within the right column of the dashboard). I think could help the user contextualize the results. Furthermore, I think this would somewhat tie together the left and right panels of the dashboard, just by using a global comparison on the right panel as well. Other than this, I think the dashboard meets its audience well.

3. Was the app intuitive to use? Did it behave as you expected?
My only confusion upon first using this dashboard was that I wasn’t sure which of the top selection tools (metric or country) operated which sections of the dashboard. After not too long it became clear that there are two distinct columns, but it might be worth thinking of a better way to distinguish them. I think either adding some different colorings to clearly separate the two columns, or making the dashboard longer, with the global map on top and the country-level stats below could be helpful. Overall though - very clean formate. I appreciate that it doesn’t feel like info overload.

4. Are the plots or other outputs sufficiently described / intuitive enough for the target audience?
I do think that the plots are sufficiently described! I appreciated the descriptive titles and use of units. My only comments are described above. Great visuals!