- Weight: 40%
- Type: Oral
- Grade: Rubric
- Due: 19-10 09:20-14:30 (ID 1), 20-10 11:10-17:50 (ID 2), 18-10 08:30-11:00 or 20-10 08:30-11:00 (ID 3)
- Results
- Grades
In assessment 3 you’ll make multiple interactive visualisations based on dirty data.
We’ll check how you apply d3, whether you understand what’s happening, how well data is represented, and quality of your code and documentation.
It’s important that you show how you clean data, use data joins (enter, update, exit), and represent data in multiple visualisations. Understanding is measured through an oral exam.
For this assessment you’ll build a project in a fork of
cmda-tt/fe3-assessment-3 (not our course repo) and
host the project through GitHub Pages. First, fork the repo. Then,
work on your project and upload the final results to your fork either using
Git or the GitHub interface as covered in class 1. You do not need
to create branches for this assessment. You should upload files to the root
directory.
We will download your code when it’s due and check your assessment on GitHub. You do not need to create a pull request. You’ll present your knowledge in an oral exam by answering questions in such a way as to demonstrate sufficient knowledge of our course’s goals.
Assessment 3 tests that you’ve attained the following knowledge:
Multiple means data can be explored through more than one visualisation. The visualisations must interact. For example, this includes interacting with one element in one visualisation causing another one to appear or update, but excludes two visualisations showing different data and not affecting each other.
Interactive means non-trivial interactivity: data changes and uses enter, update, and exit. For example, this includes sorting and filtering and excludes zooming and tooltips.
You may use recommended data. You may use other data, provided you ask a lecturer and they give an ok. You must provide a link on how to download the data. You must clean data with code and provide that code with your assessment.
You may not use data given in previous assignments or assessments. You may not use data provided in d3 examples. You may not use random data.
💁 We don’t like plagiarism and report it to our assessment committee (examencommissie in Dutch). See ¶ 6.1.2 of Teaching and Examination Regulations (TER) for a full definition, but here are a few cases that count as plagiarism:
a. using or copying someone else’s texts, data or ideas without a full and correct acknowledgement of sources; b. presenting the structure or central ideas developed by someone else as your own work or ideas, even when a reference to other authors has been included;
[…]
e. copying (parts of) media files or other sources, software source codes, models and other diagrams of other people without acknowledgement and allowing it to be held as your own work;
[…]
g. copying the work of fellow-students and allowing it to be held as your own work;
[…]
| 1-2 | 3-4 | 5-6 | 7-8 | 9-10 | |
|---|---|---|---|---|---|
| Representation | There is no data, less that two visualisations, or data is barely used in the visualisations (if at all) | Data and more than one visualisations exist but interpreting the visualisations is harder than interpreting the data itself | Dirty data is displayed in multiple interacting visualisations that are not basic examples | The visualisations go beyond examples; Interaction contributes to gaining insight in data; There are demonstrable additions and the student can name them | 🎓 Several of the data’s dimensions are beautifully visualised through interaction |
| Application of subject matter | d3 version 4 is either not referenced or not used | d3 version 4 is either used to load data, clean data, or to make less than two dynamic visualisations; there is no signification interaction using data joins | d3 version 4 is used to load data and clean data and to make multiple interactive visualisations with data joins | The visualisations contain well-chosen features and interaction methods | 😱 The way the student applies d3 is more advanced than what they were taught in class; let’s switch places |
| Understanding | There is either no substantial code or the student cannot explain the code that exists | The student cannot explain parts of the code | The student can explain every part of the code, describe why it’s used instead of alternatives | The student can explain every part of the code, describe why it’s used instead of alternatives, an can make live changes | 🤓 The student understands JavaScript and d3’s programming principles and a geeky / nerdy conversation can be held about these principles |
| Quality | The project is handed in late, broken, undocumented, not on GitHub Pages, or otherwise not proper | Code style is inconsistent or code is partially documented | Code adheres to standards and docs cover what the project is and does and the student’s process | Code quality is consistently good and docs are professional | 📚 Code and docs both read like great books |