Scratch and Tactical Design
Charlie DeTar (one of our Media Lab colleagues) recently facilitated a Scratch workshop with participants taking a course (Advanced Seminar in Networked Cultures and Participatory Media: Tactical Design for Cooperative Agency and Disruption) through the Art, Culture, and Technology (ACT) program at MIT. I'm always curious about how Scratch is received in different contexts. So, I was thrilled when I received a detailed description from Charlie after the workshop. I asked him if it would be OK to share his notes with the ScratchEd community. Here's our exchange about the workshop and ways of thinking about success…
-------
From Charlie:
Just wanted to send along some notes from today's workshop, as it sounded like you'd be interested in details. :)
We started off with a couple of quick demos which I had created -- one was a little game that lets you be a reporter throwing a shoe at George Bush (basically, a clone of http://bushbash.flashgressive.de/ ), and a little spirograph-ish pen drawing thing. I then had people follow along as we did some very basic mechanics of dragging blocks out and plugging them together, and doing a couple variants of making the scratch cat walk around the screen drawing with the pen.
We then jumped into the first exercise: having people create their own "culture jam". As an example, I started off with a sprite of Mubarak moving around the screen -- this example probably influenced people's thinking a bit more than I'd liked it to have, because for the rest of the day most of the projects involved world leaders of various types.
After working on their projects for about 30 minutes, we had people move over and work on their neighbor's project for about 15-20 minutes. I'm not sure how successful this was -- I think people got the idea and were able to read their neighbor's projects, and to add interesting modifications, but the modifications they made were perhaps less sophisticated compared with the things they had done on their own in the same amount of time previously. We then did a quick show and tell, and took a 10 minute break.
We then split into two groups of 2 and one group of 3 to build a project that was supposed to be share-with-the-world-worthy. We gave people the option of using the PicoBoards (with the intention that they would make some installation-style piece), or not (with the intention that they would make something web-shareable). Most of the time seemed to be spent figuring out the sensor boards, and dealing with data inputs (including using operators to scale values and such). Only one group did something "installation"-like -- the others made little games that treated the sensor board basically like an NES controller.
The hardest parts seemed to be:
- Getting drivers for the PicoBoards working. There was confusion among us non-experts about "pico board" vs. "pico cricket", which are different drivers. I didn't anticipate this, as it "just works" under Linux.
- While adding blocks is easy, the mechanics of disconnecting blocks from each other are a bit confusing. Everyone seemed to trip up repeatedly when trying to plug and unplug sets of blocks. This is a small thing because everyone would eventually get it, but it's bothersome that a basic mechanic like that saps resilience otherwise usable for exploration.
- Understanding how to use the value that is in a sensor took a bit of work for folks. Most people seemed to expect the sensor to "output a value" instead of "being a value" -- that is, the default understanding of a sensor block seemed to be that of a forever block surrounding a sensor block. They had to learn to add the forever block. People also had some basic difficulty understanding what sensors were doing. We ended up checking the box to display the sensor values on each person's environment, and once done, everyone seemed to depend on it and never turn it off. It seems like some basic sensor debug info like that would be a useful part of the environment, rather than the board.
My biggest takeaway is the need to prepare more different sorts of examples of using scratch for culture jamming/tactical media/etc., so that people can see more possibility.
It's also interesting to see the types of things that the programming environment lends itself to easily -- namely simple games with moving sprites. Trying to imagine how to use Scratch in a way that breaks out of that (for example, using it for projects without a screen, to visualize data, to compute things, etc.) seems like an important exercise for breaking out of that mold. Since examples that you see right before you start work seem to have so much power, it might be interesting to show examples of completely un-Scratch-like things first, and then start using Scratch right away.
-------
From me:
So, overall, did you think it was a success?
When people ask me about how I evaluate the success of my own workshops, I usually talk about three dimensions:
- Did the participants have positive design experiences during the workshop itself?
- Was there diversity in what was created, or did everyone create the same thing?
- Did the participants leave with a desire to learn more, to explore more?
I'd be curious to know how you think about success!
-------
From Charlie:
So, overall, did you think it was a success?
It might be. I think we'll have more info on that as project assignments start coming along, and we see what people come up with to do. This week we'll be doing some basic Arduino programming.
When people ask me about how I evaluate the success of my own workshops, I usually talk about three dimensions:
* Did the participants have positive design experiences during the workshop itself?
I think mostly yes, though perhaps not as much so as the design experience we had with just foam blocks in the E14 atrium the previous week.
* Was there diversity in what was created, or did everyone create the same thing?
There was a fair amount of similarity, though a small sample. 2 of the 3 groups' projects at the end of the workshop were variations on punch the monkey. The third group's project was more interesting and out of the mold.
* Did the participants leave with a desire to learn more, to explore more?
We'll see! I did get the sense that people would be able and interested in picking it up again if they want to do something that they think Scratch could accomplish. I think there was enough variety in what we ended up with to show people a range of possibilities.
I'd be curious to know how you think about success!
I've been struggling with that question myself -- it's a research interest of mine. :) If I want to do art/politics-situated technology for activists in the context of a research institution, how does that work? I don't have a good systemic answer for you. I went to the "Art as Research" talk last night, and the speaker proposed a manifesto which provided the following criteria for defining "Art Research":
- "Art as Research" presupposes an epistemic interest!
- The epistemic interest is clearly stated!
- Knowledge is formulated within the respective art form.
- A grouping according to subjects complements the classification by form of representation and disciplines.
- Research is done by many people, not only one person!
- The evaluation of results is carried out by experts!
- Quality criteria are agreed upon for the discussion of research results! At least, it must be discussed.
- "Art as Research" takes into account the "State of the Art"!
- "Art as Research" can take up the solutions scientific research offers and bat them back up as questions!
That's more a specific set of criteria for defining Art Research, rather than the specific question of how to evaluate it once you're clear that that's what you're doing. It would be "carried out by experts", but it's not clear how.
At any rate, in this particular case, I think I'd be most excited to see the students produce compelling projects that excite me. I think of them pretty much as peers, and so if they produce something that I would be excited to have produced, it seems successful.
