update slides for lecture 1

_config.yml

@@ -62,7 +62,7 @@ sphinx:
       COURSE_CODE: "DATA 551"
       SECTION: "001"
       CREDITS: "1"
-      TITLE: "Dataviz I"
+      TITLE: "Dataviz II"
       PREREQS: "All of DATA 534, DATA 543, DATA 550."
       COREQS: "N/A"
       TERM: "2021 Winter Term 2"
@@ -74,7 +74,7 @@ sphinx:
       # W_DATE_2: "11:59 PDT on November 12, 2021"
       # W_DATE_3: "November 12, 2021"
       # EXAM_PERIOD: "Saturday December 11th - Wednesday, December 22"
-      CANVAS_ID: "86767"
+      CANVAS_ID: "86697"
       CANVAS_LINK: "https://canvas.ubc.ca/courses/CANVAS_ID" # {{ '[course website]({link})'.format(link=CANVAS_LINK.replace('CANVAS_ID',CANVAS_ID)) }}
       ZOOM_LINK: "[Zoom](https://canvas.ubc.ca/courses/CANVAS_ID/external_tools/15408)"
       ANNOUNCEMENTS_LINK: "[Announcements](https://canvas.ubc.ca/courses/CANVAS_ID/announcements)"

_toc.yml

@@ -30,8 +30,10 @@ parts:
   chapters:
   - file: class/labs
     title: Accept the Labs
-- caption: Project milestones
+- caption: Block Project
   chapters:
+  - file: class/project
+    title: Project Overview
   - file: class/milestone1
     title: Milestone 1
   - file: class/milestone2

class/Lecture1.md

@@ -2,4 +2,4 @@
 
 Introduction to Dash and Dashboards
 
-Download slides for [Lecture 1 here](../lecture1.pdf).
+<iframe src="../lecture1.pdf" width="100%" height="800px" frameBorder="0"> </iframe>

class/labs.md

@@ -6,14 +6,13 @@ We are using GitHub Classroom to provision the labs.
 You will first need to accept the invitation to join our GitHub Classroom.
 Once the lab is ready for you to accept, click the below to accept the lab:
 
-| Lab               | Due Date                 | Link to Accept       |
-|-------------------|--------------------------|----------------------|
-| Milestone 1       | Tuesday Mar 2 at 18:00  | [Accept Python Repo](https://classroom.github.com/g/gKfZq8j3)       |
-| Milestone 2       | Tuesday Mar 9 at 18:00 | N/A Submit link to release  |
-| Milestone 3       | Tuesday Mar 16 at 18:00 | [Accept R Repo](https://classroom.github.com/g/tTvZFvur)        |
-| Milestone 4       | Tuesday Mar 23 18:00    | N/A Submit link to release      |
-| Teamwork Document | Tuesday Mar 23 at 18:00 | [Accept Teamwork Doc 1]() |
-
+| Lab               | Due Date                | Link to Accept             |
+|-------------------|-------------------------|----------------------------|
+| Milestone 1       | Tuesday Mar 2 at 18:00  | [Accept Python Repo]()     |
+| Milestone 2       | Tuesday Mar 9 at 18:00  | N/A Submit link to release |
+| Milestone 3       | Tuesday Mar 16 at 18:00 | [Accept R Repo]()          |
+| Milestone 4       | Tuesday Mar 23 18:00    | N/A Submit link to release |
+| Teamwork Document | Tuesday Mar 23 at 18:00 | [Accept Teamwork Doc]()    |
 
 Once you click the link, a repository will automatically be created for you with some starter code.
 You can now work on the lab, make commits, and push them to GitHub as you please. 

class/milestone2.md

@@ -1,28 +1,16 @@
 # Milestone 2 - App development and deployment
 
-In this milestone,
-you will finish develop a prototype of your app
-and deploy it on Heroku so that it is publicly accessible.
-This app should be usable even if it does not have the full functionality
-outlined in your proposal.
-You don't need to implement all the feedback you received from your TA yet,
-but it can be a good idea to get started on some of it
-since you will need to have a addressed it all in milestone 4
-(either implemented it or motivated why not in an issue).
+In this milestone, you will finish develop a prototype of your app and deploy it on Heroku so that it is publicly accessible.
+This app should be usable even if it does not have the full functionality outlined in your proposal.
+You don't need to implement all the feedback you received from your TA yet, but it can be a good idea to get started on some of it since you will need to have a addressed it all in milestone 4 (either implemented it or motivated why not in an issue).
 
 ## 1. Submission instructions
-rubric={mechanics:4}
 
-- [Click here to view a description of the rubrics used to grade the questions](https://github.com/UBC-MDS/public/tree/master/rubric).
-
-### Canvas submission
-
-- Once you have finished the work for this milestone
-  **you must create a release on GitHub.com before the submission deadline.**
-    - Please [read the GitHub documentation on how to create a release via the online interface]( https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/releasing-projects-on-github). Name your release with the respective milestone name.
-    - We will grade all files in the repo at the state they were in when you created the release.
-      This means that you can continue to make changes in the repo without worrying about messing up your grading for the previous milestone.
-- **The only thing you need to submit to Canvas is a link to your Github release**
+- In the [UBCO-MDS GitHub organization](https://github.com/ubco-mds-2021-labs) on github.com, setup a public repository with a reasonable name for your project.
+    - We need a public github.com repo for deployment. This will also make it easy to share a link to your work as part of your portfolio.
+    - This also keeps milestone requirements separate from your actual code-base. You will be making Github releases of your own repository rather than committing to the milestone repository.
+- Pick a suitable licence. MIT and BSD-3 are common good options for open source projects. [The carpentries has a short primer on licenses](http://swcarpentry.github.io/git-novice/11-licensing/index.html) (optional read).
+- You will submit your repos on Gradescope, as usual.
 
 ### Tips for working collaboratively on GitHub
 
@@ -39,34 +27,23 @@ rubric={mechanics:4}
       or fork the repo and work on a branch in your own fork.
 
 ## 2. Deployment on Heroku
-rubric={accuracy:8}
 
 - Deploy your app on Heroku
   and **include the link to your deployed dashboard clearly visible near the top of your README**.
 - Don't push to Heroku after the milestone deadline.
-    - We will compare the milestone release commits with the deployed app
-      so updating it after the deadline will give a late penalty.
-      If you want your newest changes online,
-      you can create a new heroku repo.
-- Since your `app.py` will be inside the `src` folder,
-  you need to change the `Procfile` to `web: gunicorn src.app:server`
-  instead of what it is in [the dash deployment docs](https://dash.plotly.com/deployment).
-- I recommend creating `requirements.txt` manually
-  and only fix the versions of dash and plotly.
+    - We will compare the milestone release commits with the deployed app so updating it after the deadline will give a late penalty. 
+    - If you want your newest changes online, you can create a new heroku repo.
+- Since your `app.py` will be inside the `src` folder, you need to change the `Procfile` to `web: gunicorn src.app:server` instead of what it is in [the dash deployment docs](https://dash.plotly.com/deployment).
+- I recommend creating `requirements.txt` manually and only fix the versions of dash and plotly.
     - Don't forget to include `gunicorn`.
-- Don't wait to deploy until the last minute
-  after you have implemented every single feature you want.
+- Don't wait to deploy until the last minute 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.
-    - After making the milestone2 release,
-      make a final push to Heroku to redeploy the miletone2 app.
+    - Deploy early and check that things are working, then redeploy every now and then, especially after adding new package dependencies.
+    - After making the milestone2 release, make a final push to Heroku to redeploy the miletone2 app.
 
 ### GitHub folder structure
 
-Since we now have a mix of many different file types,
-let's tidy things up a bit.
+Since we now have a mix of many different file types, let's tidy things up a bit.
 Use a project structure similar to the example below:
 
 ```
@@ -84,37 +61,21 @@ project/
 └── LICENSE.md
 ```
 
-The difference between the `reports` and `doc` folders
-is that the former contains analytic reports often involving code
-(such as notebooks)
-whereas the latter is more project documentation.
+The difference between the `reports` and `doc` folders is that the former contains analytic reports often involving code (such as notebooks) whereas the latter is more project documentation.
 So where should you put your project proposal and reflections?
-I would suggest the `doc` folder,
-but remember that these are guidelines and not a strict rule, there are other sensible folder structures too.
-You can upload any analysis you do along the way to explore the data in the `reports` folder,
-but the analysis itself will not be reviewed by the TAs.
+I would suggest the `doc` folder, but remember that these are guidelines and not a strict rule, there are other sensible folder structures too.
+You can upload any analysis you do along the way to explore the data in the `reports` folder, but the analysis itself will not be reviewed by the TAs.
 
 ## 3. Interactive Dash app in Python and Altair
-rubric={accuracy:10, quality:5, viz:15}
 
 - Implement the dashboard you outlined in your proposal.
 - Keep your usage scenario and target audience in mind when designing your interface.
 - Aim to implement most of your dashboard's functionality, but not everything.
-    - Since the complexity varies between proposals,
-      the rough goal here is to have around 3 plots
-      and most of their widgets
-      and interactivity implemented
-    - The app should be clearly usable,
-      so focus on the most important things first.
-    - In the upcoming milestones you will have time to improve your app
-      based on your proposal and the feedback you have received.
-    - The TAs will give you feedback on how to adjust the overall complexity
-      of your final app for milestone 3 and 4 (if needed). For this milestone,
-      use the above directions.
-- Your interface should be as self-documenting as possible,
-  with appropriate labels for panes and widgets,
-  legends documenting the meaning of visual encodings,
-  and a meaningful title for the app.
+    - Since the complexity varies between proposals, the rough goal here is to have around 3 plots and most of their widgets and interactivity implemented
+    - The app should be clearly usable, so focus on the most important things first.
+    - In the upcoming milestones you will have time to improve your app based on your proposal and the feedback you have received.
+    - The TAs will give you feedback on how to adjust the overall complexity of your final app for milestone 3 and 4 (if needed). For this milestone, use the above directions.
+- Your interface should be as self-documenting as possible, with appropriate labels for panes and widgets, legends documenting the meaning of visual encodings, and a meaningful title for the app.
 - Note that TAs will be grading your app on Heroku in a full-screen window
 
 It can be easy to get sucked into a rabbit hole when trying to implement a stubborn feature (I know this all too well myself =p).
@@ -125,39 +86,28 @@ if you're struggling with a particularly tough problem,
 save it for later and ask a TA for help!
 
 ## 4. Reflection
-rubric={reasoning:6}
 
 In this section, your group should document on what you have implemented in your dashboard so far and explain what is not yet implemented.
 It is important that you include what you know is not working in your dashboard, so that your TAs can distinguish between features in development and bugs.
 
 Reflect on what you think your dashboard does well what its limitations are, and what are good future improvements and additions.
 This section should not be more than 500 words and the `reflection-milestone2.md` document should live in your GitHub.com repo in the `doc` folder.
 
-## 5. Improve the README (Optional)
-rubric={reasoning:2}
+## 5. Improve the README
 
 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
-(on bigger projects these can be separated and put in different files):
+For your project, your README should cater to at least two groups of people (on bigger projects these can be separated and put in different files):
 
 1. Those potentially 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 and the deployed link.
+    - 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 and the deployed link.
     - [This is a good example](https://github.com/KirstieJane/STEMMRoleModels)
 2. Those interesting in 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 and how to run it locally
-      (maybe they are great in Altair but have never used Dash).
-    - Suggestions for what you would like help with and how to work in your project,
-      some of this can go in contributing also.
-    - [This is an example of a program I made as part of my thesis](https://gitlab.com/stemcellbioengineering/context-explorer/-/blob/master/README.md).
-
-Including a table of contents can be useful,
-as well as a short GIF of your dashboard doing something impressive.
-No matter how many nice words you put down,
-seeing the functionality right when they land on your GH page
-is very useful to evoke interest.
+      but also need to know how they can install your app and how to run it locally (maybe they are great in Altair but have never used Dash).
+    - Suggestions for what you would like help with and how to work in your project, some of this can go in contributing also.
+    - [This is an example of a program a colleague made as part of their thesis](https://gitlab.com/stemcellbioengineering/context-explorer/-/blob/master/README.md).
+
+Including a table of contents can be useful, as well as a short GIF of your dashboard doing something impressive.
+No matter how many nice words you put down, seeing the functionality right when they land on your GH page is very useful to evoke interest.