The Procrastination sketch was originally the first thing I made for this blog series. It’s not great, though the idea is simple: The relationship between work obligation and attention is represented through the spatial relationship between a box and the cursor. The statement is, in essence, ‘avoiding work makes it larger and more demanding of attention’ (plus some nuance). Some of the details of the spatial relationship are more or less invisible though (if not the entire relationship). It’s also a 2D sketch for a 1D relationship. The reasons why these issues are issues though is interesting.
The term ‘game’ is slippery. It has many ‘senses‘ or meanings that depend on the context of word’s use, e.g. “Hand me that game,” “Did you watch the game last night,” “I’m programming a game,” “We’re playing a game.” Two important senses are game-as-activity and game-as-artifact (or, more specifically, game-as-system). However, the notion of goal—frequently noted as a characteristic feature of a game in whatever sense—becomes problematic in the case of game-as-artifact/system.
‘Should designers code?’ is a question with many competing takes. I will not provide another answer here. Instead I’ll offer an alternative route for consideration—questions that favor descriptions of what is over prescriptions and value judgements. Hopefully they’ll bare someone more nuanced fruit…
- If we take “code” as a transitive verb, the question becomes “Should designers code [thing]?” What then is the thing? Are there different categories of coded things in question here? (The reader may be familiar with the concept of high and low level prototypes, but a low level prototype of a multi-player game does not present the same problems as a low level prototype of a resteraunt landing page.)
- How much coding (and of what sort) does a designer have to do (whether yearly, monthly or daily) in order to be a ‘designer that codes’?
- Are there criteria for excellence with respect to the things coded? Can these be used to establish minimum and expert level coding aptitude?
- What are the distinctions betweens novice, intermediate and advanced levels of capability with respect to the above? What does it take to develop these skills at these levels?
- Do designerly programming skills break down into different domains?
- What has been produced by people with some or all of these skills?
- What kinds of (design) problems have been solved (or investigated) through programming?
- What are problems that designers have tackled through programing that they wish they didn’t?
- What problems did designers not tackle through programming that they wish they did?
- Are there specific programming skills that can be abstracted to more traditional design areas? What about reverse?
- What are some best in category ‘interaction/interactive designs’?
- Who made them?
- What were the skills of the people on that team?
- What were their responsibilities?
- Are there any ‘good’ ‘interaction/interactive designers’ who can program? How ‘well’ do they program exactly?
- How do they use their skills (if at all)?
- What are their overall methods like?
- What kinds of projects do they work on?
- What kinds of problems do they solve?
- What kinds of teams do they work with?
- What are their day to day responsibilities?
- Are there good ‘interaction/interactive’ designers who do not program?
- How do their methods, responsibilities, activities, problems and projects compare to those that do?
- What other (sub) skills “should” a designer have (or not have)?
- What investment is necessary to develop what aspect of these skills to what degree? What resources are available? How does this compare to other skills designers develop?
- For the designer asking if they should [learn to] code: do you like to code?
Finally, If you absolutely need an answer, you could do worse than weighing Alan Cooper’s negative argument from “Should Designers Code?” (2017) against the affirmative point of view from John Maeda’s “Design in Tech” reports (2017, 2018).
I sent an email; I made a lunch date; I pressed a button; I moved a finger. Each statement describes an action, or perhaps, each statement describe the same action but in a different way. Why bother splitting hairs though? What does it matter if there are a multitude of actions here or one action with different descriptions, or one action with many consequences, or many actions?
Insofar as interaction designers design opportunities for action they have some stake in the composition of actions, their anatomy, or useful descriptions therein. In other words, if interaction designers compose action in some vague sense, it might be nice to know how actions are composed, or to have a few terms for discussion. I can’t unravel everything here, but I can get started with some basics.
So, what is an action?
The point of view that follows comes from Donald Davidson (1963, 1971) and amounts to a ‘causal theory of action’ or the ‘standard view’. It goes something like this…
An action is an event that is intentional under some description. It is caused by beliefs and desires (or pro-attitudes)—ideas, in some sense, in the head about how the world is and how we might prefer it to be, respectively.
First, we’re not talking about actions of the kind ‘the wind blew the trees’ or ‘the phone alarm work me up’ or ‘the ball hit his head’. Cause and consequence alone don’t constitute an action for our purposes here. There must be some description of the event in question such that the event stems from an agent; the event must be, generally speaking, purposive. By this account, it’s worth nothing that computers don’t perform actions. (This also happens to problematize Chris Crawford’s working definition of interaction: two actors who various speak, listen and think.)
Beliefs and desires correspond to the world in distinct ways. Beliefs being ideas about the situation at hand or in the world, including notions about the history of that situation, the underlying mechanics of its existence an the potential for its transformation: I believe the I am at home, that there is a president, that germs cause disease, and that pressing keyboard buttons causes letters to appear on screen. Beliefs may be more or less true, specific or coherent. Some people believe the world is flat, or that there are ‘a lot of people’ in New York City. Beliefs also include ideas about the possible chain of consequence(s) that could result in a desired situation (more on that later).
Desires are ideas about preferred conditions. I desire these words to be arranged in such and such a way; I desire a drink; I desire to avoid being hit by a car. “Pro-attitude” might be more accurate though; you can a pro-attitude as a kind of disposition, or a disposition to prefer, or just a preference. I prefer chocolate to vanilla, and given the opportunity to chose one or the other, I will chose the former. Desires can not be true or false.
An important outcome of this formulation is that an action is the action that it is, in some sense, by virtue of its attendant reasons or intentions (beliefs and desires); bodily movement or other observable consequences are not sufficient to pin down an action; my arm moving is not the same as the action of me moving my arm. (Also consider the distinction between manslaughter and murder.) The relationship between reasons and action is particularly relevant to any attempt to discuss opportunities for action. Without any additional caveats, it follows that an ‘opportunity for an action’ (such as deleting an email) must include the opportunity (or potential) for an actor to form or hold the corresponding beliefs and desires that would motivate such an action, including by not limited to, the very idea of email, deletion, knowledge about a specific GUI, along with any lower level motivating reason for deleting the message (such as the desire to free up space on a hard drive).
At this point I should mention that the casual description is hardly bullet proof. Its issues are multiple and even people that accept the general form may disagree about, for example, whether beliefs and desires are sufficient to cause action without an additional volition or intention. For more on how this topic breaks down, see the entry for “Action” at plato.stanford, Dancy and Sandis’s Philosophy of Action: An Anthology (2015), Mele’s The Philosophy of Action (1997), and Aguilar and Buckareff’s Causing Human Actions (2010). (I’ve barely touched the last one but it looks promising!)
Here are two tentative claims regarding interaction—in the context of interaction/interactive design—that lie at the heart of posts to come:
Weak claim: Interaction typically involves action, so there’s something to learn in looking at action itself — what is “an action”; what is the line between action and consequence, if any; do actions come in different kinds; how are they composed; etc. (For an introduction see the entry at plato.stanford.)
Strong claim: It’s possible (and preferable) to describe interaction exclusively in terms of action.
Some goals of investigating these claims are to clarify opportunities for (interaction) design decision making and crafting; find more precise language for criticism and evaluation; make finer distinctions between the aesthetics of different interactions; and make finer distinctions between the aesthetics of interactions and the aesthetics other kinds of artifact encounters.
The context of thoughts and questions to come is largely the undergraduate design classroom. I’ve spent some time trying to help young designers better define and manage design problems surrounding interactivity and hope to continue to for some time in some capacity. I’m also increasingly anxious about the complexities of the world my students will need to design for and hope that stronger foundations can help them better cope.
With respect to these needs, I’m interested in descriptions of action (or interaction) that work at an ‘appropriate level of explanation’. For example, a painter need not understand chemistry to paint (which is not to say that this knowledge would be detrimental). With regards to ‘explanatory levels’ I must also admit a great deal of ignorance though. I am only familiar with it tangentially through arguments surrounding J.J. Gibson’s direct perception, (see Ullman 1980 and Carleton 1986). While the nature of explanation is not a concern here, for designers who need to shift between disparate domains and levels of detail, e.g. from business needs to the constraints of digital technologies, ‘levels of explanation’ may be a topic worth looking at more.