fugpaint: it's not a bug, or a feature
an antagonisitic painting tool
The following are from my notes for this project, which aren't particularly well organized, but provides further explanation of the ideas being explored here.
In short, the program intends to continually tease the user in an attempt to humor them and keep him/her engaged for an extended period of time.
When working at the computer, one who is reasonably 'proficient' with its tools has a set of expectations about the software's behavior. For instance, the user of a paint program clicks the mouse to make a mark, dragging the mouse to make a long wide mark. One can practice the act of making marks and become proficient at making the marks 'well'. There is a latent sense of 'power' that the user feels and exerts over the machine, as it is forced to eke out the user's bidding.
But what happens when the underlying behavior is changed? The cynic would point out that bugs and poorly written, poorly designed software work outside our expectations all the time, but that's not the point. Instead, for instance, what happens if, as soon as the user has 'learned' the pattern, the pattern is modified slightly?
As a simple example, the user of the paint program might be drawing lines horizontal lines by moving the mouse from left to right, but then what happens when a left-to-right mouse movement creates a vertical line instead? Or, instead of drawing whenever the mouse is pressed, marks appear whenever the mouse is not pressed.
The motivation is to keep the user engaged in a state somewhere between trying to 'learn' the behavior of the program and a feeling of complete frustration. Ideally, the user might be shifting between both.
The idea here comes from something that's appeared in several of the lectures this semester, a fact of human nature—the user has some concept of what they want, so as soon as they get it, they are instantly bored and ready to move on to the next thing, whatever that might be. Instead, by dangling the proverbial carrot before the user, and moving it away each time the user gets close enough to reach it, it should be possible to keep them engaged for a longer period of time.
Will it be necessary to have a 'task' that the user is attempting to complete (draw a picture of someone or something in the room), or perhaps the user can think of their own task, given some framework (think of a picture that you would like to draw, now draw it). this establishes a built-in metric for how the user is 'doing' — i.e. if they are trying to draw a house, the user continually asks him/herself 'is this a house' 'is it almost a house' 'how close is this to a house'.
everything the user does has a 1-1 correspondence with something that's happening on the screen. the modes are not necessarily destructive to the author's creation. each manipulation should somehow 'conserve' what has been done, and allow for further 'work' being done, but the model with which it is happening has been altered.
this is not a one-liner or a gimmick. at worst, it is at least several gimmicks rolled into one. if better, it makes a better point about the set.
how it can fail, what to avoid:
because the general quality of software available today is so low (alpha quality software released as beta, beta quality software released as final) the user's expectation of continual change in the underlying pattern might be too low. at worse, as the pattern shifts, the user has the feeling that the program simply has a bug.
to address this potential issue, the piece of software is ferociously minimal, heavily tested to as bug free, and contains nothing that does not serve its direct purpose so as to confuse the overall message: this is a 'paint program' it has 8 colors, a brush, and an eraser. it has an area for painting. it doesn't need anything more to get across the idea of 'painting program'.
the changes must be deliberate enough that the user understands them as real shifts, though subtle enough that their pattern doesn't have to be immediately obvious. perhaps the transitions between different pattern states needs to happen slowly.
<< ben fry | fall 1998