While creating my studies I slowly built an Actionscript library that allows for simple relationships to be established between visual elements. I later also began work on a corresponding interface for directly manipulating these relationships.
Reading
I’ve been notably absent. However I have been doing some reading. Hopefully I’ll get a chance to elaborate on these selections later.
Recommendations from former and current professors led me to FORM+Code in Design, Art, and Architecture by Casey Reas, Chandler McWilliams, and LUST. This non-programing introduction to computational aesthetics is a brief introduction and overview of the intersection between computation and art/design. Good examples, references, and direction for experimentation. I went on to use it as required reading for a class on visual systems & computation and am assigning parts of it now for my pre-junior interactive students.
Another recommendation, The Philosophy of Computer Art by Dominic Lopes, is another look at computer arts from a philosophy/aesthetics perspective. After describing the computational aspects Lopes goes on to argue for interactivity as the defining characteristic of the art form — an idea I’ve found self evident but not one shared by those I’ve talked to who work in static or motion media necessarily.
I also contacted Jonas Löwgren who very kindly directed me to two very interesting dissertations.
Teaching Interaction Aesthetics by Sus Lundgren. In it he outlines current thinking on different aesthetic ideals for interaction and how to teach them in a classroom setting. One of the noteworthy assignments he gave students involved the appearance of interactions to outside observers. For example, the activity of playing a video game, while engendering a playful, stressful, or focused experience in players might hardly appear as such to outside observers.
Another work, Understanding Interactivity by Dag Svanaes, I wish I had been introduced to years ago if only for his succinct description of interactivity as a quality that can be discussed separately from form but can-not exist without it. A portion of the research includes a useful review of alternate models of interactivity from a number of fields including HCI (removed from my studies) and media studies. Svanaes lastly squares in on phenomenology, a philosophical foundation also used by Paul Dourish in Where the Action is. Svanaes continues on to outline — with empirical studies — the phenomena whereby users’ locus of control extends further into a computer simulation as their experience with it increases. This perceptual shift between “I control” and “it acts” is central to the type of interactive aesthetic I’ve been fascinated by for years. Again, I wish I had been introduced to this in undergrad when I was researching things like the non-narrative aesthetics of player/player-character relationships.
A Few Studies on the Dragging of a Box
While variations in mapping and latency between pieces are sure to create perceptual and aesthetic differences; It should be possible to utilize a change in these relationships within the same piece to create more complex (yet hopefully unified) interactivity.
The studies can be viewed here.
The source can be downloaded here.
Latency and Mapping Studies
As part of my exploration for my thesis research I’ve been attempting to build small interactive pieces through the design of a restricted set of proposed interactive variables including ‘latency’ and ‘mapping’. The goal being to produce some minimum level of compelling, complex, or emergent interactivity out of basic overlapping ‘manipulations’
While latency is strictly defined as the delay between input and some response, for my purposes I refer to it as the the time between the expression of a final desired value and the alignment of some external property to that value. I begin these studies by varying this time between input and final alignment over a collection of individual elements. I prefer working with cursors as elements as the relationship between a user’s intent and the end visual result of a cursor is exceptionally conditioned and transparent. This relatively automatic act of placing a cursor in space is as close as I can get to using an ‘intended value’.
While I’m attempting to focus on non-visual qualities, I have no misgivings about the important role of an interactive artifact’s visual appearance in our understanding of it. For this reason, toward the end of the series I reinterpret earlier studies as mathematical structures to be visualized in completely new ways.
The studies can be viewed here.
The source for these can be found here. This includes both my own code and the excellent tweening library Tweenlite. Please feel free to remix anything and send me samples!
Second Wind
My pitch was recently approved and I’m currently starting another push to move this project forward; beginning with a committee search.
The past six months have been relatively quiet on the thesis front, but not uneventful. I’ve since moved to Cincinnati Ohio and have been teaching several classes as an adjunct professor at the University of Cincinnati college of DAAP. The experience so far has been entertaining, enlightening, challenging, and most of all meaningful. There many people here I greatly respect and am also personally fond. I’m pleased to walk the halls of the Eisenman building here again.
Interactive Product Design Finals
Better late than never. Student projects from the Spring ’10 Interactive Product Design Studio.
Tackling Programming Problems
One of the most important but difficult programming skills to acquire is the ability to break apart problems. But how does a student go from a fuzzy idea of some multi-media editing interface to the boolean logic of an if else statement when they have the barest grasp of program flow in the first place. Computer Science students have it easy in a fashion; they can focus on learning existing patterns without the necessity of turning experimental ideas into their new language of logic. Designers of interactivity lack the luxury of years of guided programming experience and are saddled with making systems that interface with the most trickiest components, humans. (The difficulty last part has its own entire field after all).
Last quarter I tried to pass on some more atomistic problems that often sit in between code and concept. the first and one of the lowest level problems I’ve found is the mapping problem, the conversion of one value to another. The second is on the upper end and the first step for breaking apart a concept: splitting application logic into data and representation. (The model / view terms are of course yanked from the MVC pattern and are usually used to refer to something a little more complex that what I’m dealing with here. I use them in order to paint what is often a continuous set of code as smaller pieces with specific responsibilities).
Mapping
In any kind of interactive physical whatever one of the most common tasks, and place for designing the system is in ʻmappingʼ the range of input values to a range of output values. Ie. your sensor gives you 0–1023 but your rotating doll head goes from 0–2*PI radians (yuck). This is a mapping problem, and luckily, with a little math itʼs not that hard to solve.
(inputValue / maximumInputValue) * maximumOutputValue;
or, to use the example above:
(sensorValue/1023) * TWO_PI
What this code does is convert the sensor input into a percentage and then turn that percentage into an actual value in the target space. (sensorValue/1023) will turn our input into a number between 0 and 1 (0 if sensorValue is 0 and 1 if sensor value is 1023). Then we take the value of the target space and multiply by the variable. If our doll head turns to TWO_PI radians and we multiple that maximum value by a percentage, we get the actual number we want the head turned to.
Model / View
Interactive systems are kinda muddy. If weʼre going to design them we need to be able to describe them.
The first step (and easiest and most useful way to do this) is to describe what variables are in the system. A stripped down version of Pong with nothing but the ball needs variables for the x & y position of the ball and also the ballʼs x and y velocity.
Next we need the rules by which the system operates. Always start with the most basic version of a rule that you can actually program. We know in Pong that the ball bounces around, but even simpler than that is the fact the ball moves at all. Movement is a very common rule and is described in computer terms as such:
value = value + valueVelocity;
Or
xPosition = xPosition + xVelocity;
This code needs to be run continuously (every time the program updates). This is done by putting it in the the draw() function.
With a few variables and some math we now have a working model of our simple, non interactive, non winnable version of Pong. Problem is, we canʼt see it work.
The second step in describing an interactive piece is to describe how it represents, or visualizes, its model. This section of a program can be labeled the programʼs view. The view for our Pong game consists of drawing a rectangle to the screen based on the x & y values of the ball. ie:
rect(ballX,ballY, 10, 10);
This code also needs to be called every time the program loops. Just be careful not to mix it up with the model code. Theoretically you could put all your model processes in a function updateModel() and all your visualization code in a function updateView() and then your draw function would look like this:
void draw()
{
updateModel();
updateView();
}
(It would be more helpful if the draw function were just called mainLoop, or main, or loop, but oh well).
Now that we have this basic two part structure we can modify the artifacts gestalt by building more complex models or by building more sophisticated visualizations of the model as is.
What if you had two balls? What if the ballʼs x and y position is greater than the screen size? These are questions about the gameʼs model.
Looking at the speed and position of the ball, can we calculate and draw where it will be in a few moments? This is a view question.
As a designer you can work with either component, evaluate the gestalt, and then try something else. It also makes your program easier to understand if the responsibilities of each line of code are grouped together.
Lastly, thereʼs no rules that govern what the relative size (in terms of lines of code) and complexity (in terms of processing and math) of the model or the view is or should be. Your model could be one variable (meanness) and your view could do a lot of number crunching to draw a flower based on that one variable (like last project). Alternately your model could describe all the pieces of a flower, and the view just has to draw rectangles where the petals are.
Game Studies and IxD
Since undergrad I’ve found that most games are exceptionally sophisticated examples of designed interactivity whether poetic or instrumental. Back then there was a shrinking but present stigma, a common acceptance that games are not-serious. Not to say there weren’t a number of people taking these artifacts very seriously (beyond people looking for something to blame school violence on). Today, with Infinity Ward’s Modern Warfare 2 the highest grossing entertainment product in history, and the center of a exceptionally important lawsuit over the rights creatives have over their work, even a die hard pragmatist would find it difficult to dismiss the field, let alone the industry. More to my point here, the nascent IxD discipline, in their exercise of eminent domain over all things behavioral, have found that games are great examples of designed behavior. It occasionally seems though that — perhaps like many fields IxD has appropriated into their study — the existing conversation surrounding game studies has become invisible. Everyone knows what a game is after all. Surely there’s nothing to say about them that’s not prima facie. I wouldn’t doubt though that this has as much to do with practice vs. academia as it has to do with IxD and game studies. Either way, I was sent an entry into a series of articles not long ago that served as a great example for some of this.
Teaching Processing
This quarter I’m an acting TA for the class “Interactive Product Design” over in the industrial design department. The primary goal for the quarter is to give students there a chance to tinker with Arduino and start thinking about how they can invest their forms with some embedded computing. Secondly, the class will also serve to acquaint them with programming, which is almost completely foreign to most of the students. That said, I spent the last class giving a ground level introduction to programming in general and Processing in particular. Competency, even if by the end of the quater, with a few of the most important structures (expressions, variables, control statements, functions) I hope will provide enough conceptual tools for digesting things they find and allowing them to create rather sophisticated interactivity.

