lab4.md

DSCI 532 Lab 4

General Lab Instructions

rubric={mechanics:2,writing:4,reasoning:4}

  • Ensure your lab meets these basic lab requirements: https://github.ubc.ca/ubc-mds-2016/general/blob/master/general_lab_instructions.md
  • Ensure that the low-level flow of your writing is appropriate, with full sentences and using proper English, spelling, and grammar.
  • Ensure that the high-level structure of your solution is clear and thorough for each answer, with a well-thought-out organization of concepts that avoids repetition.
  • This assignment is to be completed in R, submitting both a .Rmd markdown file you create in RStudio (you can add your answers directly to this one) along with a rendered .md AND .pdf file.
  • Ensure that your markdown submission as a whole is easy to read: use appropriate formatting that clearly distinguishes between our questions and your answer, between different sub-parts of your answer, and has visible differences between code and English.

Feedback Session Instructions

In this lab assignment, you'll be improving your shiny app from Lab3 after an in-lab peer-review feedback session.

We'll run two feedback sessions, 40 minutes each. Within each, you'll do two cycles of 20 minutes each: one where you give feedback, and another where you receive feedback. Each time, you'll be paired with a different peer. So, you'll be doing four cycles. You'll be assigned partners randomly.

Each cycle has four components to it:

  1. Fly-on-the-wall: The reviewer explores the creator's shiny app without any input from the creator, while the creator watches. The reviewer is encouraged to talk (speak your thought process -- "think out loud"), but the creator can't talk, and can't even gesture! 5 minutes
  2. Informed-run: The reviewer continues to explore the creator's app, but this time with input from the creator. 5 minutes
  3. Written feedback: The reviewer and the creator writes feedback (to place in Exercise 1). These will probably be similar, and that's OK, but be sure to write the feedback yourself. 10 minutes
  4. Exchange: The reviewer gives the creator their feedback.

Tips on giving feedback:

Your feedback only needs to be a "brain dump" (doesn't need polishing). But it should still be thoughtful and useful. Here are some tips on giving feedback:

  • State what's good about the work. Why is it good? State what needs improvement. Why does it need improvement? But never charge those things with emotion. Be objective.
  • Feedback that goes above and beyond also offers suggestions on how to improve.
  • There's always something that can be said! If the app is great and needs no changes, say why (however, an app can always be improved). If there's nothing learned in the "informed-run" portion of the feedback, say so, and say why.

Exercise 1: Giving Written Feedback

In this exercise, you are to record the feedback that you wrote as both a reviewer and creator. We aren't checking for a polished piece of writing here -- what's important here is the content. You do not need proper English, spelling and grammar here!

1(a) Feedback as a Creator

rubric={reasoning:12}

Write feedback on your own app here.

Feedback from Session 1

Reviewer's Name:

Your feedback here

Feedback from Session 2

Reviewer's Name:

Your feedback here

1(b) Feedback as a Reviewer

rubric={reasoning:12}

Write feedback on your peers' apps here. be sure to include:

  • the creator's name, and
  • a link to the shiny app being reviewed (make sure it's the proper version).

Feedback from Session 1

Creator's Name:

Link to shiny app (Lab3 version):

Feedback:

Your feedback here

Feedback from Session 2

Creator's Name:

Link to shiny app (Lab3 version):

Feedback:

Your feedback here

Exercise 2: "Pre-hacking" reflection

rubric={reasoning:13}

In this exercise, you are to reflect upon the usefulness of the feedback you received, and decide what to do about the feedback (i.e., what you intend to change). Report this in a written discussion.

Note: You might modify this discussion as you work on improving your app in Exercise 3. For example, perhaps a change you intended to make is not realistic.

Here are some questions that you may (or may not) want to address:

  • What things did you hear that's similar across reviewers? Is there a theme here?
  • From the feedback, what things do you think are appropriate to change in your app, particularly given the time frame you have to improve the app?
  • What is unreasonable to change, and why? Time restraints? Too technical?

A theme to include in your discussion is the usability of the app, such as good and bad design. Ideally, your app should "just make sense". Does it? Can it? Why or why not? What sort of things are in the way of making your app "just make sense", if it's lacking that?

The length of your response is not important -- we're looking for a reflection that is thoughtful and touches on several aspects of your app and the feedback. We're imagining something like 200-500 words, but again, this is certainly not strict.

Exercise 3: Improved Shiny App

rubric={code:5,viz:30,reasoning:5}

Take the feedback you received about your Shiny app and use it to make improvements. Changes should be documented in Github, and you should tag a new release once you have finished these changes (don't replace your Lab3 version). Remember, your goal is not to create the perfect shiny app -- it's to make the most critical improvements that you can using the time allocated to Lab4. There will probably be some amazing features that you'd like your app to have, but would take a very long time to implement -- these aren't the changes we're looking for. You can comment on things like this in Exercise 2.

Exercise 4: "Post-hacking" reflection

rubric={reasoning:13}

Write a reflection on the effectiveness of the feedback and feedback process to give an improved app. Some questions that you may (or may not) want to consider are:

  • What feedback was the most/least valuable?
  • What part of the feedback process was most/least valuable?
  • What did you learn from your experience being a "fly-on-the-wall". Was this useful? Why or why not?
  • If you were to make the app again from scratch (or some other app in general), what would you do differently?
  • What were the greatest challenges you faced with this process?

A theme to include in your discussion is whether the feedback process lead to an improved app. What parts were valuable? What parts were not valuable?

The length of your response is not important.