 |
Author |
Topic: eureka! (Read 1527 times) |
|
arielm
|
eureka!
« on: Nov 23rd, 2003, 2:37am » |
|
it took me some time, and a respectable amount of neurones were sacrified to this task, but i finally start to understand something about what it takes to make a successful processing workshop!
okay, it's not a secret... casey, amoeba and others definitely put these things into every-day practice, but this could be helpful for people who are going to be stuck at some point with the following kind of questions:
on Oct 23rd, 2003, 10:46pm, arielm wrote:| frankly, do you think it's possible to make an interesting processing workshop (~ 3 x 7 hours) targeted to total beginners in programming |
|
at that time, i guess i was stuck because i started to put on paper all the basic programming concepts (not specific to processing) i could think of, e.g.:
- structure (comments, flow...)
- variables
- arithmetics and operators
- conditions
- functions
- iterations
- input/output...
the problem with this approach is that if you really want to teach all these concepts in an effective way, you need:
- time, lots of time (nothing less than weeks) for people to really digest and practice things.
- super motivated people (i.e. that won't drop in the middle).
in addition, it can turn to be very boring (useful, but boring), and it can easily bring the class to places that are very far away from what people like about electronic arts...
so, that was obviously not the right direction!
in parallel, by looking at some casey's workshop materials, i felt on this strong hint: "These are not programming exercises - they are visual and programming exercises",
then... on Oct 24th, 2003, 2:11pm, amoeba wrote:| 3x7 hours does not a programmer make. But it might make a visual person think about form in a computational way. |
|
now, i'm aware that this is the "solution", but i have to admit that at the time i first read this sentence, it was still very abstract to me.
to put things into context, casey wrote this paper in which he defines a number of "software expressions":
- Dynamic form
- Behavior
- Gesture, etc.
it took me some time to digest all this... looking at amoeba's udk workshop was very helpful to see these software expressions translated into something tangible.
in parallel, with heidi, my partner and neighbor, we had a long series of brainstorming sessions and we reached the following "principles" as a basis for our forthcoming 2.5 days workshop:
1) it should be fun.
2) heterogenous classes (e.g. including people experienced in programming and people experienced in arts) are not an handicap, but an advantage.
3) people are creative, let's make use of it...
4) all knowing is doing (ah confucius, ah mitchel resnick...)
5) it's not about programming, it's about [YOUR OWN STUFF HERE].
6) it should be "theme" based (the "motivation" factor)...
now, for the (short) synthesis part: how all this relates to casey's software expressions
- there could a be theme, e.g. THE THEME OF THE FESTIVAL THIS TIME = EROTICA that would serve as the inspiration for software created by the workshop participants.
- the "basic atoms" used by the participants will be our software expressions (in other words: the "basic atoms" used by the participants won't be some generic programming principles).
with that erotica software theme in mind, casey's description of his software expressions take a very tangible form:
Quote:| Dynamic form is form that changes in time. If this form reacts to stimuli, it is responsive... |
|
Quote:| Behavior is movement with the appearance of intent. Combining simple behaviors can create personality or disposition... |
|
isn't it
(we have now one month to put theory into practice, and get ready for our first workshop: it will be directed to people that are not part of cursus: artists, designers, and eventually "flashists", project managers, etc... it will be fun  )
|
| « Last Edit: Oct 24th, 2004, 2:55pm by arielm » |
|
Ariel Malka | www.chronotext.org
|
|
|
|
