In January, I’ll be teaching a course at Portland Community College called “Apps as Art: Learn to Code Apps that are Artistic”. At the risk of sounding hyperbolic, as far as I know, this is the first course of its kind being offered in the world. Thus far, enrollment has been good, and it looks like the course is a go.
Part of the course’s novelty is the newness of the medium that we’ll be focusing on, the mobile app. I’ve written previously about the medium’s promise, as well as some of the reasons why the range of work currently being done in it is so sparse. Digital art has been around for almost as long as computers have been. Internet art has existed since the ‘90s. But due to the mobile app’s youth, and the perceived barriers to entry, it’s still the Wild West.
What’s especially enticing (I’m gambling, anyway) about the course is that no previous programming experience is required to participate. I’m hoping to attract experienced hackers and artists, who are not necessarily both. If I’m really lucky, the course will also lure a few who are neither coders nor self-avowed artists.
The course has two simultaneous tracks. In the first track, we’ll build a standard app, Calculator, to get acquainted with the application development tool that we’ll be using, which is called LiveCode. The value of LiveCode is that just about anyone can learn to code with it quickly. It’s that easy to use. But it’s also powerful and flexible.
In the second track, we’ll explore art theory as it relates to our medium of choice. This will include discussing key questions, such as: What’s the social significance of the mobile app? What’s unique about the mobile app as an artistic medium? When building mobile apps as works of art, how do we distinguish between “design thinking” and the kind of creativity that warrants the status of art?
My neighbor recently brought an article on Github by Lisa Charlotte Rost to my attention. In that article, Rost writes:
What are these criteria art and design judged by? ... Design needs to be functional. I studied and taught visual communication, and I tried to make my students ask constantly: “What does it communicate me?” In data vis, that question needs to be answered. The clearer, the better. Data art, on the other hand, doesn’t need to be functional. If a student would ask me for feedback for her data art project, I would judge strength of idea / concept or strength of aesthetics, but not readability. I want a piece of art to stimulate emotions or thoughts in me; I want a piece of data vis to explain to me the world. I want Data art, like lots of other art, to raise questions. I want Data Vis to answer them.
This strikes me as a decent departure point for discussing the differences between art and design—but only that, a start. It echoes the conventional wisdom that opts into the all-too-easy dichotomies: art is open-ended, design closed; art is provocative, design functional; art is ambiguous, design transparent; etc. Under closer scrutiny, these oppositions lose force. In the course, we’ll explore how and why this is the case.
A couple weeks ago, I went to a Show & Tell put on by the organizers of the Meetup group PDX Creative Coders at their home base, Helios Interactive in North Portland. I noticed that much of the digital art on display was of the “generative” kind. This is digital or internet art where code generates the content of the artwork. Generative art often takes the form of a theme, determined by the algorithm at the heart of the code, and variations on that theme. When we think of generative digital art, apps that produce intricate visual or audio patterns come to mind. But Twitter bots are also an example of generative art. I like to called generative art, “algorithm art,” because the artist is letting a kind of artificial intelligence do the heavy lifting.
In the app art course, I want to get away from algorithm art. This is, in part, why we’ll be recreating standard apps like Calculator, Notes, and Messages. You could also call this a “theme and variation” approach to making art, but with an altogether different emphasis.
I love literary scholar Linda Hutcheon’s definition of parody, which she writes is “imitation with critical distance”. That’s essentially what we’ll be doing with Calculator. We’re going to imitate the standard app, then explore ways to adapt, extend, and subvert it. This involves considering the purpose of Calculator, its history as a technological tool, and its social contexts.
Parody is great for finding a way into creative expression because it forces us to work within limits. Take, as an example from literature, the sonnet. Ezra Pound famously taught us that the sonnet evolved in the thirteenth century as a parodic imitation of the troubadour’s chanson. He chafed at the sonnet’s formal rigidity, its divorce from the melodic inventiveness of song. But sonnet, as a literary form, has persisted, even thrived, because it imposes limits on the poet. In the case of a Petrarchan sonnet, 14 lines in iambic pentameter, an octet and a sestet with specific rhyme schemes, and so on. Working within these limits forces the writer to find new avenues of invention. A parody of the humble, taken-for-granted Calculator offers the same promise!
Due to time constraints, toward the end of the course, we’ll consider briefly other standard apps, in particular, Notes and Messages. Messages intrigues because it’s social. One of the most exciting things about the mobile app as an artistic medium is that it can be cloud-based, with client and server sides. It suggests all sorts of possibilities for distributed interactions among “users” of the art app. Miranda July recognized that brilliantly with her app Somebody. Corey Pressman’s mobile app Cornbread cleverly exploits a comparable functionality.
In the coming months, I’ll be reporting here on the progress that we make in class. If all goes well, at the end of the course, I hope to have some interesting mobile app artwork to share with you.
// Channel Surfing
""The Memory Remains", with a few minor exceptions, borrows heavily from a season one classic.READ the article