Outline

  • Due: 25 October 2024
  • Mark weighting: 30%
  • Templates: template repo
  • Assessment Criteria: Criteria and Rubric
  • Submission: submit your assignment according to the instructions below
  • Policies: for late policies, academic integrity policies, etc. see the policies page

Description

The purpose of the mini project is to evaluate your ability to critically explore a theme through code art and/or code music which will ultimately inform or evolve into your final project artefact. We don’t require the code sketch(es) you produce to be polished for th Mini Project. They should be rough implementations of an idea, just like a pencil-sketch. You will have four weeks worth of class time to work on your code-sketch (You can certainly use time outside class to work on it too). Part of the work you produce for the portfolio will also be research into defining the scope of your design and analyzing the works of other artists, but the portfolio will predominantly showcase your original attempts at designing digital experiences which address the following theme.

Theme: More Than Human

We live on a planet brimming with life. Often our focus is with human concerns, understandably. We forget, or ignore, or even dismiss, our dependence on the the living systems of which we form a part. We also often fail to recognise our position as a living being, evolved from, in an unbroken chain of life, simple single cell life forms. It has been theorised that of the total cells in and on a human body, more than 50% of the cells are other life forms!

We would like you to respond to this provocation.

We are not looking for virtual zoos! We are looking for an artistic response, which uses visuals and/or audio to make an audience member think differently about the world we live in, from a new perspective, which appreciates that the earth does not belong to us, that we are part of interconnected systems, that life has been around for 4 billion years, that evolution is not directed or hierarchical, and that humans form a part of a web of living beings.

Submission deadlines

The Mini Project is due at 11:59pm on Friday 25 October.

In your template repo, you will find markdown files for each portfolio submission under the subfolder portfolio\. You might not have worked with markdown before, so we will give you plenty of support with this stuff. It’s a lot like writing in any kind of text file (like MS Word, but without all the nice formatting). Here are some resources to help you navigate markdown, but you can also just ask us in class if you have any questions. Besides actually writing, committing and pushing the code to generate sketches which you’ll discuss in your portfolio submission, you will only need to modify the relevant markdown file for your fortnightly portfolio submissions.

If you find markdown too challenging, we are open to accepting PDF format documents for the required written responses.

Submission process

You must submit each portfolio entry and the corresponding code by committing and pushing it to GitLab by 11:59pm for each deadline above. You must push it to your fork of the template repo (the same process we use every week in the labs).

Remember: a markdown file is just a file like all the other files (e.g. .js, .html) you’ve had in your template repository every week. You just need to modify the relevant file and commit, then push it up to GitLab as usual.

Once you’ve done that, it’s a good idea to log into the GitLab web interface and check that it’s been successfully pushed.

Specification

Your Mini Project submission should include the following:

  • an outline of your decision making for your code development, including the WHAT and the WHY. Your decision making should be discussed in relation to the four dimensions of the marking criteria below.
  • a history of git commits related to the changes you made for each portfolio entry. Make a new commit for each new idea you try and push your code to git regularly.
  • a photo(s)/screen capture of your work OR any sources of inspiration
  • you can optionally include a video(s) of your work in your entry Videos must be hosted externally.
  • all planning for what you have explored in your each portfolio submission
  • links to any external code/resources you used. This includes code you have already developed in association with this course through weekly classwork or assessments.

The portfolio entries should address the questions posed in each markdown template. Any photos related to your ideation can be a mixture of hand-drawn sketches and code-sketches (screenshots of your browser window), but we encourage you to get comfortable sketching with code this year. You can even include photos of you interacting with your sketch. You will need to host any videos you want to include on a platform like Vimeo or YouTube (it can be private/unlisted) and share a link to it. DO NOT PUT VIDEOS IN YOUR GitLab REPO.

Conforming to the Specification

Conforming to the specification is a critically important aspect of working in computing. EXTN1019 is about creative computing, which allows a greater variation of exploration of ideas and concepts. Even so, there are certain aspects of this assessment which are critical:

  • you must use your gitlab repository for your code, committing and pushing updates frequently.
  • you must acknowledge all sources for ideas and code: you are welcome to build on code found in other places, or provided by your teacher or peers - but you must acknowledge these sources. This includes code generated by generative AI systems.
  • you must interpret the themes provided: your interpretation can be broad, but you must inform the viewer of your system how this relates to the theme.
  • you must adhere to submission deadlines

Non-conformance will result in penalties to your grade.

NOTE: Your Mini Project will form a part of your portfolio of works, which will be hosted on the creative computing course website. All of your portfolio entries will be hidden from public view until the Year 11 exhibition event, so you can go back and modify any old submissions before this date. After this date, the portfolio entries will be made public. If you don’t feel comfortable having your portfolio entry made public, please let me know and I won’t have it listed on the course site.

Marking criteria

The marking criteria are connected to the course learning outcomes (LOs).

[D1] Critical Exploration of Theme and your chosen value system (LO #1 and #4)

  • To what degree have you explored the creative context you are building within? How have you used research and sources of inspiration to explore interpretations of each theme and explore the value systems or beliefs you wish to capture in your work.

  • critical discussion of how the “take-home message” of your work is perceived? This could be through your own perspective, through the perspective of someone who shares the value-system or belief you are designing for, or through a person seeing your work in a gallery.

[D2] Interaction Design (LO #1 and #2)

  • to what degree does your decision making effectively consider some form of interaction between the person viewing your work and the work itself? We say some form of interaction because you can implement explicit interactions where a person clicks, types, moves, produces sound which affects your work, OR you can implement implicit interaction where your work is only viewed by the audience member and your sketch somehow manipulates their expectations.

  • do your code sketches implement the most important attributes of the interactive, visual or sonic mechanism you want to explore? Since you are submitting sketches for your portfolio, we care more about your ability to identify (and implement) the most important attributes of the thing you want to implement.

[D3] Artistic Output (LO #2 and #4)

  • to what degree does the artistic output (either visuals or sound/music) of your code sketch enhance your interpretation of the theme and to what degree does it detract from your interpretation?

  • do your portfolio entries have—a logical structure, easy-to-follow explanations of your design decisions and their relationship to the theme, including both the what and the why of your design

[D4] Computational Thinking (LO #1, #2 and #3)

  • To what degree have you explored and engaged with the technical contexts and approaches we have encountered over the first 6 months of the course (including 2D visuals, data, repetition, animation, collections and audio). YOU ARE NOT EXPECTED TO ENGAGE WITH ALL TECHNIQUES FOR THE MINI PROJECT.
  • To what degree have you developed your own code? Including code from other sources is fine - but you need to acknowledge all sources. You should try to modify, adapt, or evolve the code to fit your interpretation of the theme. Building something new and unexpected from multiple sources also represents creativity.

Note: the mark is for your portfolio entry, not the code itself. However, you must commit and push the code associated with each portfolio entry as well (as stated above) to show us the work that your portfolio entry is based on—if you don’t push the code that will be considered a submission which does not conform to the spec.

Year 11 Mini Project Assessment Rubric

  A Grade
(9-10)
B Grade
(7-8)
C Grade
(5-6)
D Grade
(3-4)
E Grade
(0-2)
D1 [25%] Theme          
D1a [15%]
Interpretation of the Theme
LO#4

how engaging is your interpretation of the theme through your work—does it draw the viewer in and make them want to see/hear more about your work?
there is a unique and surprising interpretation of the theme, which is highly engaging, or has a strong narrative arc there is a clear, creative and engaging interpretation of the theme in the work of art, or clear development of a narrative arc there is a clear interpretation / elaboration of the theme: engagement and connection or narrative arc need further development the theme is referenced, but an interpretation or elaboration of the theme is not developed the theme is not clearly represented
D1b [10%]
Critical Exploration of Theme
LO #1 and #4

How has the theme been explored through your ideation, reflection as represented in your written responses
the theme has been radically interpreted, and critically unpacked, building on references to prior art the theme has been critically explored, with a new and surprising take, building on prior art the theme has been addressed through a basic written response to all questions in the template very superficial or simplistic interpretation of the theme the theme has not been explored
D2 [25%] Interaction Design          
D2a [15%]
Engaging Interaction
LO#1 and #2

how have you included interaction in your work? is it clear what’s going on and does your work look like fun to play with?
highly engaging, innovative and effective interaction, with a high level of attention given to user/viewer engagement engaging and effective interaction, with some development of user engagement effective interaction using basic/conventional modes of interaction limited interaction very limited, or no user interaction
D2b [10%]
Connection between Interaction and Theme

LO#1
is the interaction connected to the theme in a meaningful way?
the interaction strongly connects to the theme, and the interaction makes the thematic message stronger the interaction connects clearly to the theme the interaction shows some relationship to the theme: thematic connections through interaction need further development the interaction and the theme are not clearly connected limited interaction with no connection to the theme
D3 [25%] Creativity/Artistry          
D3a [15%]
Engaging Creative Output

LO#2
are the foundations for an engaging artistic output (either visuals or sound/music) implemented in your work?
strong evidence of creativity to develop surprising, highly engaging and innovative responses evidence of creativity to develop innovative responses evidence of critical thinking with some indication of possibilities for final project develops basic solutions very limited creative output
D3b [10%]
Artistic Intent
LO #2 and #4
insightfully communicates the intent of the work, with clear evolution of designs with well justified decision making in relation and critical exploration of theme effectively communicates the intent of the work, with clear evolution of designs supported by well justified decision making intent of the work is clear. satisfactory evidence of artistic development which includes several variations or stages of evolution intent of the work is not clearly communicated. some alternatives considered, but not much variation or evolution very limited evidence, or no evidence, of artistic development
D4 [25%] Computational Thinking          
D4a [10%]
Use of Coding Techniques
LO #1 and #3
significant evidence of work by the student including something right at the edge (or beyond) the techniques we covered in this course, good abstraction. significant evidence of work by the student and engagement with techniques we covered in this course lacks evidence of significant ambition on the technical side or, strong engagement with techniques through combining three (or fewer) code sources without significant changes the code represents very limited changes to prior work, or uses inappropriate coding techniques it is not the student’s work or is not a work of creative coding as taught
D4b [5%]
Coding Effectiveness
LO#1, #2 and #3

does the code work as it’s supposed to? are there any obvious bugs/janky bits?
employs critical and creative thinking, drawing on data and information to solve complex problems effectively: the polished and well-documented code works as intended employs critical OR creative thinking, drawing on data and information to solve problems effectively: the code works effectively in most cases employs critical thinking, drawing on data and information to solve problems: the code works satisfactorily, but contains minor flaws draws on limited techniques in an attempt to solve problems: the code exhibits major flaws the code doesn’t work
D4c [10%]
Project Evaluation
LO#1 and #3

tell us about your project development process, including alternative solutions you rejected (and why), and how you refined and improved your coding artefact(s) over time
evidence of project development is well documented, showing critical analysis and evaluation of a number of potential alternatives for appropriateness and effectiveness with clear iterative improvement and review analysis of a number of potential alternatives and solutions including the appropriateness and effectiveness of alternative solutions with iterative improvement evidence shows at least 2 potential alternatives and solutions with descriptions of their appropriateness and effectiveness describes one potential alternative with limited reference to its appropriateness or effectiveness very limited identification of alternative solutions with no evidence of iterative improvement or review

FAQ

How do I even start?

If you’re not sure exactly what to cover in your mini project, here are a few questions to help you get started (note: this is not a checklist—just some stimulus material to get the juices flowing).

  • are there any artists/pieces which you’ve used for inspiration? is there a certain aesthetic which you gravitate towards? how will your response explore & extend the things in that work?

  • is there one key interaction idea that’s at the heart of your performance/artefact? or is it about taking two separate ideas and mashing them together? or something else?

  • what’s unique about your interpretation—what is it that makes yours stand out from the crowd?

  • what do you want someone who sees/hears your work to experience—what do you hope they’d tell their friends about it?

What do you mean by “mini project”?

You might be wondering what the difference is between this mini project and the actual final project.

The key point is that it’s something you build (in code) that tests out your design ideas which represent the theme.

It’s not expected to be anything complete or polished, but it does need to work. It’s better to build something small which works (and allows you to see if your idea is cool/interesting/whatever) than to try and build something really big—even “final-project sized” but not get it working.

It can be based on either the p5 visuals stuff (from term 2) or the Tone.js music stuff (from term 3) or both. If you’ve got other ideas and you’re not sure if they fit the requirements, then ping Matthew on Teams and we can have a chat.

How “big” should it be?

We’re not going to set any hard-and-fast “it must have this many lines of code” rules or anything like that (lines-of-code is a pretty bad way of measuring productivity in coding anyway).

Instead, here’s a rule of thumb—it should be a bit more sophisticated than what you tend to come up with by the end of the lab, but doesn’t have to be heaps more sophisticated than that.

Does my Mini Project have to have all the parts that will be in my Final Project?

Ideally, yes. Your final project will have a different theme, and is expected to be complete and well researched and with the theme well-elaborated If your plan for the final project is something with music and visuals, you might decide for your Mini Project to just build a music or a visuals artefact.

Obviously your Mini Project still needs to be an appropriately-sized piece of work, but it doesn’t have to include everything which you might plan for your final project.

How does this “Mini Project” deliverable relate to the final project due at the end of the year?

In terms of scope, hopefully the previous two FAQ entries have clarified what we mean by “Mini Project” (vs the final project).

In terms of marking, your Mini Project (30%) is marked separately from your Final Project (40%).

Obviously there will be some similarity between 2 projects, but the final project will have different marking criteria and rubrics and is a separate deliverable. In general, your final project will be bigger and more polished—it’ll do more, and it’ll do it better.

Will my classmates get to see my work?

Yes, we will share projects in Week 4 of Term 4.

One of the cool things about this project development process is seeing what everyone else is working on and being able to give feedback & encouragement. As you have hopefully figured out by now, we’re a friendly and encouraging bunch, and (as in all things EXTN1019) the course code of conduct applies (short version: be excellent to each other).

You’re not grading your classmates—you don’t give them a mark, and any discussions you have with one another isn’t incorporated into the grades. The purpose of the discussion is for you to help one another out in creating the best creative computing work that you can.

Can I include code/sound files/images from elsewhere in my prototype & demo video?

Yes, you can (although obviously if you just present something that someone else has made without doing any work yourself then that’s not enough to pass the assignment). Whatever you use, make sure that you reference it. You can do this in a comment in your code, or, preferably, in the references.md file you have in your repo.

It matters that you reference it somehow, because otherwise it counts as plagiarism, and that’s something which is taken pretty seriously at the ANU and the penalties can be severe.

This isn’t meant to be scary, I’m sure you all know how to reference things and as long as you don’t try and pass of work by others as your own you’ll be ok. But if you’re not sure if/how to reference something then you need to ask us (early!) on the Teams channel, because “whoops, I forgot” is not an acceptable excuse for not providing a references.

Which sound library should I use?

p5.sound.js and Tone.js both make sound, and they do it in different (and slightly non-compatible ways). The reasons for that require kind of a deep dive into the way the web browser processes audio, but there are a couple of take-home messages:

  • if you try and combine audio from both p5 (e.g. with the p5.sound library) and Tone.js simultaneously, you’ll probably have a bad time

  • if you mostly want to do textural/soundscape stuff (especially if you want that to be triggered by interactions with the visuals) then p5.sound.js is probably the best bet (although Tone.js might be fine as well)

  • if you want to make beats, or any other music where the exact timing of the different “notes” really matters, then use Tone.js

How do I remove the Tone.js from the template stuff if I only want to use p5?

You do not need to.

Can I use code that I’ve already committed & pushed to GitLab as part of one of my labs?

Yep, that’s fine—if it’s your code, you don’t even have to reference it. If it’s code from the template itself, then make sure you make a note of it.

As an example, if you copy the drawPokemon() and updatePokemon() functions from the lab 88 (Pokegardens) template you should say something like this in your references.md file:

The `drawPokemon()` and `updatePokemon()` functions (starting at line 67 of my
`sketch.js` file) are taken from the [lab 88 template repo](https://gitlab.cecs.anu.edu.au/extn1019/2023-2024/year-11/extn1019-2023-lab-8).

Can I play back a sound file using Tone.js?

Yep—more information will be posted (there are different solutions for p5.sound.js and Tone.js).

Please note that all external sound files must be referenced, and, ideally, you have permission to use these sound files.

It’s just a couple of days before the deadline—can you debug my code?

Look, we try super hard to help you out in this class. There is plenty of lab time assigned to development of your project and there has been plenty of time to ask for help.

It’s probably best not to count on us debugging things at the last minute—obviously you can still ask questions on the main Teams channel (other students might have had the same issues you’ve had and be able to help) but “I wasn’t able to get help with my code” isn’t really gonna fly as an excuse for not handing things in.

“how do you add citations and bibliographies in Markdown”

This guide shows you how: https://arshovon.com/blog/cite-in-markdown/

Your Markdown should looks like this:

Raji, et al[^Raji_2021], discuss the dangers of Artificial Intelligence ..

---
**Bibliography**

[^Raji_2021]: Raji, Inioluwa Deborah, Emily M. Bender, Amandalynne Paullada, Emily Denton, and Alex Hanna. “AI and the Everything in the Whole Wide World Benchmark.” arXiv:2111.15366 [Cs], November 26, 2021. http://arxiv.org/abs/2111.15366.

Jekyll will render this as follows:

Raji, et al1, discuss the dangers of Artificial Intelligence ..


Bibliography

  1. Raji, Inioluwa Deborah, Emily M. Bender, Amandalynne Paullada, Emily Denton, and Alex Hanna. “AI and the Everything in the Whole Wide World Benchmark.” arXiv:2111.15366 [Cs], November 26, 2021. http://arxiv.org/abs/2111.15366. 

bars search caret-down plus minus arrow-right times