jtnimoy About All Work Tweets Contact Cv Login
Year: 2005

Icon==Function permalink

This series of seven interactive musical compositions is intended for serious play and wonderment about tools. Each piece is an abstract visual sound scoring language capable of playing itself back as the user gives input. The series is several attempted embodiments of my conceptual response to a recent HCI conclusion, as written in CWC 2004:

"Icon interpretation is inherently ambiguous because the relationship between icon and function is not determined by a set of well-defined syntactic and phonological rules."

Icon==Function is a science fiction, showing a hypothetical dystopia / utopia. What would an interface be like if its iconography were determined by a well-defined ruleset?

The software art was conceptualised by JT in a series of long-winded email discussions with David England and curator Michael Connor. The sketches were then interpreted by Josh, Matthew Phillips, and David Lu in a number of programming languages. The code is hosted by Sourceforge.

screenshot
hexball coded by jt using lingo
Big Screenshot
Go to Interactive Piece

screenshot
gears coded by jt using p5
Big Screenshot
Go to Interactive Piece

screenshot
nesting circles, coded by jt using p5
Big Screenshot
Go to Interactive Piece

screenshot
triangle music coded by jt using p5
Big Screenshot
Go to Interactive Piece

screenshot
bouncing boxes coded by jt using p5
Big Screenshot
Go to Interactive Piece

screenshot
bouncing boxes coded by Matthew Phillips using as2
Big Screenshot
Go to Interactive Piece

screenshot
colored squares coded by David Lu (aka Forkinsocket) using as2
Big Screenshot
Go to Interactive Piece


Each piece in the series is a simplified programming language used to instruct the computer's functional output. A whimsical code editor is exposed to the user as a visual toy that interacts with a mouse and keyboard. No other labeling or indirect tagging is used to mark the mini-programs written with each mini-language. The languages are made of simple geometries - capable of representing themselves as their own icon. The function's code can be seen as its own graphical icon. The well-defined syntax of iconography in each representation is precisely the instruction language controlling the sound output. When a user browses a small set of thumbnails looking for a state to load and play, the user is not seeing a textual name given to the work, nor a proxy graphic that attempts to explain the function by some cultural mapping. Instead, the user sees the code, itself. In the name "Icon==Function," a double equality operator is taken from modern text-based programming to communication that the icon and the function are the same as one another. If a single equality sign were used, it would signify undesirably that the function in these pieces are somehow being assigned to the icon, and that the icon is a transparent address for the function. The art series aims to collapse the two ideas into one just for the sake of both conceptual argument and exploratory scientific research.

Just Language Enough

In computer programming, the word "function" is used to describe a collection of instructions that perform a coherent task. A function hides the code inside of it from attention, and allows its code to be invoked only by calling the function's name. In creating the seven visual languages in this series, my biggest aim was to produce the beginnings of language-ness from my interactive geometries. The aim of adding the modern features of 'real' programming code (such as memory and logical flow of control) was somewhat irrelevant. In most cases, a simple linear list of instructions sufficed in order to make the artistic point, and to provide the software user with an experience that was close enough to programming that they would gain some sense of authorship with their constructions. A stronger focus was also placed on making the experience playful in a game-like way, rather than providing the user with an industrially competent solution.

Usability of the Pie are unfamiliar components that interface designers hope to channel their users to embrace through play or necessity. This is the part of the experience that I am calling the exploration.

In the pieces of Icon==Function, the interfaces I am recycling come from CAD and desktop graphics software applications like a paint program or paste-up application. The colored square game is a slight variation of a pixel editor. The triangle music interface is a modified vector-line drawing tool. "Gear Sound" and "Nested Circles" both rely on circle-drawing tools. Although HexBall heavily resembles a video game, the most basic interface is a pixel editor -- and so on. That is the intuition aspect. The exploration aspect is what happens to those graphics creation interfaces that result in something more than simply the circle that was drawn, or the pixel that was toggled. No one originally expects music to come from their rectangle dragging tool, nor would they expect the element they drew to bounce around on the screen and obey gravity after they drew it. However, this expectation should also become intuitiho are already familiar with painting and graphics applications. Even if draggable rectangles exist as part of widespread commercial GUI OSes as a 2D spatial "multi-select" for file icons, it is questionable what percentage of the user population considers that an integral part of their computing lifestyles and would recognize it in a new program, or know to check for it. My mother (age 59, health care manager) has had considerable difficulty getting into each piece as she must be told to actually drag the mouse instead of just clicking it. After being reminded to drag, she spends most of her time struggling with the touch pad on my laptop, and eventually concludes that the piece is visually beautiful, without delving deeply into trying new combinations. It is interesting for me to see her interact with the pieces because she doesn't seem to understand the language, nor is she searching for one. On the other hand, my brother (musician in his early 20s) is better familiar not only with graphics programs, but video games and software development as well. He has witnessed my software interface experiments since the mid-1990s and already knows that I expect him to explore, given little or no instruction. My brother will start by doing "the sensor dance." The sensor dance is what happens when a human is trying all the different entry points into the interaction that he or she can think of, in hopes to get any sort of response out of the unrecognized interface. While an ambiguous physical installation will cause a person to wave their arms in the air, move close and far, shout, clap, and touch, a desktop computer based work (restricted to a mouse and keyboard) evokes a different kind of sensor dance. The person will click around on everything, dragging the mouse in different places and pressing different keys. In my own observations, people have also been known to re-launch the application to see if it does something new or to check to see if it's broken. My brother is quick to engage in a neactive language, creating new instances and enjoying the outcomes as his own achievements. Since he is a musician, he's familiar with the idea of embracing a system and recombining its parts to produce a new expression. One could say that my interfaces are more intuitive for him. He is familiar on more levels than just see-and-remember. I think these outer, more anthropological scopes of understanding usability could make the problem clearer than simply analyzing the language that translates between icon and function, or icon-system and function-system.

* Credits [ Artist and coder: Josh Nimoy, coder: David Lu, coder: Matthew Phillips, Commission from FACT (www.fact.co.uk) and JMU HCI (www.hci-fun.org.uk) curated by Michael Connor & Marta Ruperez. HCI research headed by David England. ]


tags: actionscript addiction cplusplus director england flash lingo music opengl opensource sound synaesthesia