Future of Coding

48 • Jennifer Jacobs • Para & Dynamic Brushes

2020-06-14

Listen in your podcast player by searching for Future of Coding, or via Apple Podcasts | Overcast | RSS

There’s a small handful of people that I’ve been requested again and again to interview on the Future of Coding podcast. Jennifer Jacobs is one of those people. Her work on Dynamic Brushes in particular, and parametric drawing in general, occupies a major intersection between disciplines and provides insights that we can all apply to our own work. This interview touches on childhood education, programming tools for both non-programmers and expert programmers, tangible interfaces, wearable and embodied computation, aesthetics, the relationship between academia and industry, means of evaluating the efficacy of projects, geometric encodings of first-order logic, symbolic representations, whether Scratch could exist outside MIT, and more. Jennifer does a wonderful job articulating the nature her own work, but also the works of her collaborators, peers, and influences, so that we come away with a great understanding for the broader spaces in which her research fits. Jennifer is already am important figure in our Future of Coding field, and I am very excited to follow her career and see all the places the impacts of her work will be felt.

You’ll notice right away that Steve is sitting in the interviewer chair this time. This is the first of a handful of episodes that Steve recorded in 2019 but didn’t release. I’m planning to edit and release them throughout 2020, so you’ll hear a bit more of Steve yet.

Quote of the show: “Metaphors are important here.”

Before we get to the links and transcript, as the host of this podcast and the steward of our community, I want to say something in my official capacity: Black lives matter. The consequences of racism in the US, here where I am in Canada, and around the world permeate every facet of life and society. It will take a constant effort over many lifetimes to achieve justice, and all of us can play a role in making that happen. There are many ways we technologists can be deliberate in our work, to be sure we are empowering the people who need it most. Right now, I’m just going to look at one small piece — our community. Over the past six months, we’ve had a number of deep, probing discussions about the need for greater diversity in our membership, in the guests that appear on this podcast, and in computing broadly. One outcome of those discussions has been the creation and iterative refinement of our code of conduct, which I’d like to excerpt a few sentences from.

One of many principles held by the community is that computing currently reflects the interests of a narrow minority of people. A directed effort is needed to broaden the accessibility of computing and amplify the influence of historically underrepresented people in shaping its future. The tools for thought we want to build aren’t just to help us do more thinking about our tools. We’re trying to make tools to help people solve real problems in the world. That means we need to be able to talk about these problems. We also need to be able to recognize and discuss problems within our own cultures, like the lack of diversity.

Those are just words. They are necessary but not sufficient. I’ve received a number of suggestions for concrete actions we can take as a community, and that I can take as the community’s steward, to make this a more welcoming and inclusive place. I’m doing my best to put them into effect and am excited to share more of that work with you when it is ready. Like accessibility, a focus on justice benefits not just the people who are underrepresented, but everyone. So if you haven’t yet reflected on how to make your own work embody the values of justice and inclusion, or moving power from those who have too much to those who don’t, I implore you to do that. Finally, if there are things you would like to see me do, or changes you’d like to see in our community, to make it a more empowering space for Black people in particular, I would by grateful to hear from you.

Here’s a quick demo of Para at the Adobe MAX 2014 conference.

Jennifer Jacobs is our illustrious guest. The two main projects discussed in the interview are Para and Dynamic Brushes. You can also find Jennifer on Twitter. She currently leads the Expressive Computation lab at UCSB.

We are actively looking for people who are interested in potentially pursuing these ideas under a PhD or a Master’s degree, but also visiting researchers, visiting artists. If you’re excited about this and you’re interested in talking more, definitely reach out to me over email: jmjacobs@ucsb.edu.

Steve Krouse ghost-hosts.

Jennifer has participated in two groups at the MIT Media Lab, each featuring a number people working on fascinating projects.

High-Low Tech

Lifelong Kindergarten

Steve invoked Seymour Papert, of whom Mitch Resnick was a student, as an example of someone standing deeply within mathematics, extending a hand to the people outside it.

Grasshopper is node-based dataflow language for the 3D modelling tool Rhino, and an example of the sort of tools artists will happily use without being aware that they are in fact programming.

Steve doesn’t like the term procedural in reference to art. Jennifer references Sol LeWitt’s instructional art as one of many examples of the term having meaning outside programming, and A Pattern Language as an example of abstraction in a domain outside computing. Shantell Martin is an artist who makes drawings in a very procedural fashion.

Jennifer has led workshops on Processing.

Para was created with contributions from Joel Brandt, Radomír Měch, and Sumit Gogia, under supervision of Mitch Resnick. Kimberly Smith is a painter at the Media Lab who helped test Para. It builds on many prior works, including SketchPad, Morphic, Toby Schachman’s Apparatus, Rubaiat Kazi’s Kitty, Bret Victor, and Sketch-n-Sketch.

Bret’s essay Learnable Programming explains why good defaults are important. MicroWorlds provides a good starting point / introduction of concepts.

Jennifer’s former advisor was Michael Salter.

Dynamic Brushes was put through its paces by artists Erik Natzke, Emily Gobeille, and Theo Watson (creator of openFrameworks).

Steve reminds himself of Alan Kay’s STEPS project.

Dynamic Brushes gets compared Max/MSP, though it probably owes more inspiration to Scratch. What you’re actually creating are states and constraints, which Steve compares to Statecharts?. Jennifer had looked at Steve Oney’s InterState, too. The iPad component of Dynamic Brushes looks a bit like Procreate.

Jennifer’s discussions with Madeline Gannon led her to the conception of Dynamic Brushes in the space of interaction design rather than tool development.

Steve wonders if the intuitive way that artists train to work, and some programmers naturally work, is related to Kahneman’s System 1 / System 2.

Jennifer’s work is inspired by The Textility of Making and The Reflective Practitioner.

Steve references Piaget and his experience with Logo when discussing how people come to learn the workings of a tool. He then references a criticism of Scratch by Alan Kay, which reminds Jennifer of Kay’s User Interface: A Personal View, and Jerome Bruner’s theories of the forms of knowledge.

On the subject of evaluating tools, Steve mentions the 7GUIs project.

Benjamin Mako Hill is a professor at U-Dub who analyzed how people adopted and used the LilyPad.

p5.js is a JS-based adaptation of Processing that, like Processing and openFrameworks, has a rich community that inspires Jennifer.

Jennifer wants to continue working on connecting the creative coding community with more academic communities like CHI.

Transcript

Transcript sponsored by Repl.it

Corrections to this transcript are much appreciated!

Steve

Welcome Jennifer.

Jennifer

Thank you. Happy to be here.

Steve

I’m very excited for this conversation. In particular, I think a few of my longtime listeners are excited too because you have the honor of being requested. Not all of my guests were requested but you were.

Jennifer

Oh, that’s always nice. [laughs].

Steve

You’ve worked in two different groups at the MIT Media Lab, is that right?

Jennifer

Yes. High-Low Tech and Lifelong Kindergarten.

Steve

I think most of us are pretty familiar with the Lifelong Kindergarten because it’s Mitch Resnick’s group. It’s the group that made Scratch. But I haven’t heard of the High-Low Tech group. What’s that?

Jennifer

High-Low Tech is a group that was founded by Leah Buechley. Leah is probably best known for being the creator of the LilyPad Arduino, which is a version of the original Arduino but fundamentally redesigned to support e-textile-based electronics, as opposed to more traditional electronics. Rather than breadboarding, you connect to the LilyPad with conductive thread. There’s a whole set of components that go with it that also are connected by sewing and conductive thread. The LilyPad is something I knew about before I was interested in the Media Lab. It’s really a seminal example of how redesigning an existing piece of technology enables not just a different type of application for that technology, but also really broadens participation to a totally different group of people. In this case it was people who enjoy sewing or working with textiles.

Jennifer

High-Low Tech was founded around this notion of integrating emerging or highly technical platforms like electronics, computational design, and coding with established, or traditional — or sometimes what are considered “low” forms of making — in terms of fine art, traditional craftsmanship, but also “arts and crafts” (in the sense that people think of that as more of an approachable, or hobbyist, or accessible form of making). The group was structured around different ways of supporting both communities and different types of practices, in combining these different modes of making and different materials.

Jennifer

There was a lot of work in the group being done around combining electronics and paper craft. This is being done by Jie Qi. She now has a company called Chibitronics that produces these electronic stickers, or paper craft and electronics kits. Also, Dave Mellis, who was one of the original Arduino team, did a lot of work in the group to help people make their own consumer electronics — radios, computer mice, speakers. His most complex electronic product that you could build yourself is a DIY cell phone. There was also a lot of work that extended the LilyPad platform. Emily Lovell in the group did a lot of work around supporting community engagement, creating a community sharing platform for the LilyPad called LilyPond. She also did some work in building different versions of the LilyPad that were simpler and easier to get started with.

Jennifer

Hannah Perner-Wilson was also in the group. She’s a rock star. All these people are rock stars, [laughs] but she really took the integration of craft and electronics really far. Her thesis was this work called A Kit-of-No-Parts, which was basically looking at all the ways you could repurpose materials that were not traditionally thought of as electronic materials into platforms for building electronics, and building sensors. She did a lot of knitted resistant sensors that could be then integrated into clothing. She did work with conductive paints to create painted speakers on found materials. She’s also one of the people I respect the most in terms of dissemination and documentation, where everything she did is very carefully documented and presented online. If you’re all interested in craft-based electronics, Hannah is really the master in that area, in addition to the work that Leah did.

Jennifer

Leah really brought this amazing group of people together, and then I was lucky enough to be able to join it for my masters. That was really where I first got excited about this idea of combining code as a design tool, and then as a design tool for making physical objects by integrating it with digital fabrication. Leah was really the person who inspired me to start looking at the ways in which we can use computer programming to build really complex forms and objects, and then turn those things into real things by using 3D printing, or laser cutting, or computer controlled milling. So that’s a quick overview of what High-Low Tech does, but it’s no longer a research group at the Media Lab, but we still maintain an active community independently. We have meetups biannually. We’re actually having one this summer [2019 - Ed.] in Kentucky. Really excited about that.

Steve

Oh, wow. It’s just for people who are part of the group or is it open to the public?

Jennifer

No, it’s still kind of an internal element. The original members of the group meet up, share our research, share our work. We’ve all spread out across the world at this point. I don’t know what this says about the type of work that I’m interested in doing, but often it’s something that is at odds with a lot of institutions. I think there’s a lot of really amazing things about the Media Lab. There were aspects of High-Low Tech that weren’t always understood or supported there. The fact that High-Low Tech is not a research group there anymore is something that’s acknowledged as a loss. But it’s also difficult to have non-traditional engineering communities in what are often pretty traditional, or rigid, engineering communities. I think High-Low Tech was an example of that. It still exists in terms of the work that we are doing as individuals, but it is no longer a research group at MIT, unfortunately.

Steve

There’s this saying, or this idea, that “high tech” is just the things that didn’t exist when you were born. I think today’s definition of high tech is things that didn’t exist when you were born that were like likely made in California. I think that’s an approximate definition for what high tech is. I think what’s interesting about the High-Low Tech group is that it’s trying to take things that were made after you were born, but make them as usable as things that you grew up with.

Jennifer

Yeah. A bunch of it is thinking about ways in which we can make different approaches to making — in different media and material — more approachable, or more inviting, or more relevant to different groups of people. Often that’s groups of people that traditionally have been excluded, or viewed as not relevant to them. In some ways that’s lowering barriers to entry and making things easier. Although, as I know you’re very aware of and your audience is very aware of, what it means to make something easier is not a simple notion. There’s a lot to unpack there.

Jennifer

But it’s also often this notion of: what are the expressive opportunities that come with reframing a form of making along the traditions of another form of making? In traditional circuit design, the trace (on a circuit board — not to be confused with a “trace” in programming) is primarily viewed purely from a functional and efficiency perspective. Is it thick enough to support the necessary electrical properties? Does it connect the necessary components? But if you translate that, so the trace is also something that you’re embroidering with conductive thread or you’re drawing with conductive ink, then it’s both a means to transmit electricity (and have a functioning circuit), but it also becomes a decorative or an aesthetic element. That’s something that comes out of traditions of drawing, and embroidery, and sewing, where functional aspects are also things that contribute to the visual properties — the beauty of a piece. That’s something that I think everyone in High-Low Tech felt was very powerful and very meaningful. It’s an opportunity to engage people who maybe have an interest in drawing, or have an interest in sewing, or in craft, in seeing themselves as producers of technology, which is very important.

Jennifer

But it’s also an opportunity to re-envision what technology might look like — or what these materials might mean, and how they might be used — to people who have a closed notion of what a circuit is or what applications computer programming is used for. One of the really interesting experiences I had in the group is when I was first doing computational design workshops with Processing, and I was having people write code to make designs for lamps, for example. I would work with people who had never programmed before, and this was their first introduction to programming, and they would be interested in that. But I’d also worked with experienced programmers and software developers who would say, “Oh, I had no idea that code could be used to make beautiful forms.” I feel like both of those are powerful outcomes.

Steve

I find myself wondering how you identify. I have these two myths in my head that I think could apply. One is the myth of, the guy who brought fire from the gods…

Jennifer

Oh, Prometheus! [laughs].

Steve

Prometheus. Yes. So, you could see yourself as Prometheus, being a technologist who’s bringing technology to artists. Or you could see yourself as more like Jack in Jack and the Beanstalk, someone who goes up to the gods and steals their stuff and then comes back down. So do you identify more as a technologist who’s democratizing technology or as an artist who’s trying to claim technology for themselves?

Jennifer

I would say there are elements of both of those that are things that I think are important and am interested in supporting. But I wouldn’t say I view myself precisely through either of those lenses. One thing that I continually struggle with is the language that I use to describe what I’m doing and who I’m doing it for. A lot of this comes up in talking about artists versus programmers. The reality is that while not all artists program, it’s also not an accurate distinction to say that there are programmers and then there are artists. Much of the work I’ve done has been inspired by artists who are also some of the best programmers that I have ever met, some of the best software & application developers that I’ve ever met.

Jennifer

I would see it more as trying to explain to artists why programming is so great, or help make it easier for artists to program. Artists do very difficult things all the time, and learn very difficult things all the time. But thinking from this perspective: what are domains of art that could really benefit from some of the powerful affordances of programming? I believe that frankly at this point, everything can benefit from programming if it’s presented in the right context.

Jennifer

We might rethink how we develop programming environments or programming languages to support these specific domains. That’s less about just making it easier for some artists to use programming, and more about thinking a little bit about changing the idea of what programming might be, or changing the notion of how it might connect to different forms of expression. At the end of the day, this comes down to my own experience, and the things that motivated me personally. I often talk informally about my work as being a series of productive failures, and trying to mash symbolic programming and drawing together. They are these two forms of creation that I feel are incredibly powerful, personally, but have fundamentally different properties in many respects. I can talk more about what those are at length.

Jennifer

A lot of the work that I’ve done has been trying to approach different ways that we get these two things to be integrated more closely together. How can we make the experience of programming more like drawing? How can we make the process of programming reflect some of the key forms of expression of drawing? That’s translated out into a bunch of different domains beyond drawing. I think it’s more of a notion of taking these two forms of expression that are really powerful, and thinking about different representations, different interfaces, even different forms of teaching, and facilitation that allow us to combine them as opposed to introducing this audience, like artists who were previously unaware of this medium programming to it, and helping them to get started.

Jennifer

That’s definitely a part of it, but not the whole story. From the other perspective, I think you use the metaphor of Jack and the Beanstalk like… I think like there’s another angle of this work, or question that I ask myself, which is, “What value does my work provide for more established programming communities like software development?” That’s only been a question that I’ve been focusing on relatively recently, and I think it’s not the primary focus of my work, but there are a lot of things that I’ve been looking at in terms of how artists program, or how artists work. This is generalizing to some extent, but often true — they often engage in an exploratory working practice where they don’t start with a clearly defined problem and say, “Okay, now, I just need to break this up into smaller problems and solve it.” They have a process where they’re open to mistakes, they’re open to variation, and they explore as they make. Bret Victor has talked about this in a lot of his writing as well. That’s something that’s true for artists, and often goes against very traditional notions of what good programming practice should be, or what good software development should be. But I also think that software developers work in an exploratory manner. Other people have written about this in many cases, and I think that it’s impossible to predict and plan every aspect of a programming project before you execute on it.

Jennifer

There are always surprises, and unexpected things, and experimentation. I think there are things we can learn from how more messy forms of creation, or more messy creative practitioners use programming that might help us make better programming tools for people like software developers or their communities. But I haven’t explored that direction in my work as much.

Steve

Just to clarify, when I was talking about the Jack and the Beanstalk metaphor, the metaphor was: artists are more normal people, and the giants are the programmers. You’re stealing some of the programmer magic and bringing it down to the artists.

Jennifer

Yeah. I’m sorry, I [laughs]-

Steve

You flipped the metaphor so artists were the people… ‘Cause you could do it either way.

Jennifer

Yeah. I mean, there is so much magic in programming, but I don’t…

Steve

I guess, just to give you examples of people that come to mind: Seymour Papert, to me, seems like someone who was like really a mathematician who was trying to bring mathematics to people who didn’t like mathematics. As opposed an artist who wanted to use mathematics in their work. You know? He was very much like a democratizer, when there are other people who are scrappy artists who just take whatever they can and embed it in their work.

Jennifer

There’s this problematic notion — I’ve heard this addressed on your podcast before — of certain types of people being equipped to be good programmers, and other types of people being less equipped, or a notion of exceptionalism in certain forms of programming. That’s unfortunate, and not surprising.

Jennifer

But I do like to try to break down that idea a little bit. That — while programming is an incredibly powerful form of expression, while abstraction has value in so many different forms of design and so many different forms of expression, while symbolic mathematics has value in so many different forms of expression — programming is too vast to say that there is one personality type, or one intelligence type that really aligns with it, and if you don’t have that you’re never going to truly be effective in it.

Jennifer

That’s definitely a belief I had about myself getting started in programming. It was totally by accident that I got started programming. But I see it now with some of the people that I work with. For example, a lot of artists who use visual programming languages like Grasshopper, which is the node-based dataflow language for Rhino, it is a very powerful programming language. I’ll have people tell me, “Oh, I don’t know how to program, I just use Grasshopper.” It’s like, “Why is that not programming? Where did you get that idea?” Because [laughs] it is a visual programming language, you know? There are people (but I think fewer and fewer) who don’t consider visual programming to be programming…

Steve

Definitely not, from where I’m sitting, fewer and fewer.

Jennifer

[laughs]. Right, right. Well, I’ve had the good fortune of being in a very supportive environment, in Lifelong Kindergarten. I’m still learning a bit about how the rest of the world…

Steve

Yeah, you’re in Mecca like, “Oh, everyone believes in the same God as me.”

Jennifer

Yeah. [laughs]. Everything’s wonderful.

Jennifer

I do think it’s important to dispel those ideas, and dispel the notions of where programming is relevant. I don’t know how much oxygen I even want to give to that space. But needless to say, I focus not so much on, “Is this programming, or is this not programming?” More, “What are different people trying to make? How can the ideas or the approaches embedded in programming support them? What are the barriers? How can we help more people make things by building different interfaces, or environments, or tools that get around some of those barriers?” There’s so many questions and challenges in there that, at the end of the day…

Jennifer

There’s somebody who looks at what I do and says, “Yeah, but you don’t have conditionals in this language. It’s not really a programing language.” I’m like, “Well, there will be other issues where we need conditionals. But I want that to be driven by the people I’m trying to support, or the work that I’m trying to support, not by the fact that there’s the notion that to be real programming, you need conditionals,” you know?

Steve

I want to keep talking about this sort of stuff, but I think it might help our audience to talk more concretely about some work you’ve done.

Jennifer

Yeah, absolutely. [laughs].

Steve

But actually before we do that, I want to just ask you a question which I might end up cutting, but I’m curious to know the answer.

Jennifer

Sure.

Steve

I really enjoyed the who’s who of High-Low Tech, and all the interesting work happening there. I was wondering if you would do the same for that Lifelong Kindergarten group.

Jennifer

I can tell you who was present when I was in Lifelong Kindergarten, because it’s since grown. The group is led by Mitch Resnick, who I’m sure many people are familiar with. He was a student of Seymour Papert, and one of the main designers (and, really, the continued architect) of the Scratch programming language — although, Scratch is really a community effort, it’s come together from the contributions of a lot of different people.

Jennifer

While I was there, there were a few other grad students that really influenced me. Ricarose Roque, who’s now faculty at CU Boulder, in the information science department, I think. She was doing a lot of work around facilitation in computational learning, specifically related to families. How do you help not just kids learn to program, but how do you engage people in computational learning in the context of a family? The cool thing about that work is that she is an immigrant, comes from an immigrant family, was focusing on working with other immigrant families by and large as a means to think about: what are some of the constraints that different communities people have when engaging in different types of learning? How can we have this be a process not just to help people develop new skills, but also something that engages parents and their children together, and working with a new technology?

Jennifer

Ricarose’s work really stands out to me because facilitation is such an important aspect of how we think about people learning programming. Often, the work in my domain that gets a lot of focus and research is: what can an environment do? What can a technology do to make learning easier? But there’s also so many important questions about what it looks like to facilitate a learning environment, what the interactions look like between the people who are “experts” and the people who are non-experts. Ricarose is one of the people who’s really doing deep work in that space.

Jennifer

Sayamindu Dasgupta was another grad student who was in the group when I was there. He is doing really interesting work of combining data science and programming for young people just like Seymour Papert. Mitch said that kids are programmers, and we should build programming languages for them. Sayamindu has kind of extended that, so that kids can be data scientists. He’s looked at ways to use Scratch as a way to help kids do programming with data around their own data. The Scratch community has a lot of opportunities in that space where kids can get data about how many the way people have viewed their projects, the people they’ve worked with in the community. We’ve done a lot of really interesting research in that area. I think that there are some Scratch extensions that have come out of it that are specifically geared towards programming with external data.

Jennifer

Oh man, [laughs] there were a lot of other people in the group when I was there. Eric Rosenbaum was there. We overlapped. He and Jay Silver did the Makey Makey, and Eric has done a lot of really great work around computational music creation that’s continuing to be embedded in Scratch. One of the great things is that a lot of students in the group are also members of the Scratch team, and we’ll come back in various ways and continue to contribute to Scratch. I think Eric is actually now working as a member of the Scratch team.

Jennifer

Natalie Rusk was there as a research scientist. I believe she’s still there. Natalie’s another big component of Scratch, and also has done really thoughtful work in the space of motivation, and understanding what drives people to engage in difficult learning tasks, or learning challenges.

Jennifer

Then there’s the whole Scratch team. One of the things I feel really fortunate about, being in Lifelong Kindergarten, was not just interacting with the grad students, but the fact that there’s basically this small company of people who are maintaining, designing, and doing engineering for the Scratch community and Scratch programming environment. They’re such a wonderful group of people, but also have such a wealth of knowledge around design, around working with people, around teaching.

Jennifer

A lot of the work that I’ve done was directly influenced by talking with those people about how they thought about designing visual programming languages, or how they thought about developing documentation. I think it’s something that is often not present in academia, where you’re maybe working in a simplified or less ecologically valid context, and less aware of what people in the “real” world are doing. There’s too many people in Lifelong Kindergarten to talk about, but those are a few people that really influenced me.

Steve

For people who aren’t in academia, academia sometimes seems overwhelmingly large. But when you meet a few people who are in academia, and you just ask, “Who were your friends? Who are the people that you’ve worked with, and are interesting?” They just list ten people, and you’re like, “Oh, I can learn about these ten people.”

Jennifer

Yeah. There’s too many people to talk about. But the other nice thing about both High-Low Tech and Lifelong Kindergarten is everyone I’ve encountered in those groups has been a very kind person as well. If people are interested in and they look into Sayamindu or Ricarose’s work, I encourage them to reach out because they’re all very kind, and interested in sharing and connecting with people.

Steve

Cool. Okay. Now let’s get into some of that more concrete stuff of the work you’ve done. There was one talk of yours I saw. You had two different projects. One project needed some testing and evaluation, and then you did a second project.

Jennifer

I think you’re probably thinking of Para and Dynamic Brushes.

Steve

Got it. I forgot the name Para. I knew the second one, Dynamic Brushes I’m familiar with.

Jennifer

Yeah. It’s not a great name, but we needed a name, [laughs] so…

Steve

No, I like Dynamic Brushes a lot actually. I have trouble with the word procedural, the phrase procedural art, because procedures are just one way of describing things.

Jennifer

Yeah. I have trouble with it too, but I haven’t found a better word.

Steve

I guess I like dynamic art, or computational art, something more abstract than procedural because, you know…

Jennifer

Yeah. I am continuing to refine the language I use. I chose procedural because it’s one that is used both in the art community and also historically with regards to art made with computers, and also to some extent art that is not made with a digital computer but arguably is computational like instructional art, for example, Sol LeWitt is the canonical example in that space.

Steve

That’s interesting that there’s this connection to instructional art even before computers, or like giving like a recipe of instructions even before computers were around.

Jennifer

Yeah. Well, we can go way back into the history of all kinds of forms of algorithmic production that existed before computers. Yeah.

Steve

Yeah, I can imagine an architect could explain to the brick layers where they want the bricks to go.

Jennifer

Yeah. I’m sure you’ve are familiar with Christopher Alexander’s book A Pattern Language, and all the work he’s done that’s all about (arguably) abstraction in form, in architecture and structure. But, you know, knitting and weaving are the canonical examples of algorithmic forms of making. It’s interesting because — not to go on too much of a tangent, but [laughs] it’s hard not to — a lot of artists think about what they do algorithmically, even if they don’t program, because artists are highly reflective in their process. They’re very interested in what they make, but they’re also very interested in how they make it.

Jennifer

For example, Shantell Martin, who’s an artist that I’m very inspired by. I’ve had a lot of conversations with her about her process and drawing. She creates these giant large scale drawings, all improvisationally, and all seemingly without a plan. But she talks about the fact that, “Oh yeah, I understand this general structure of when I make a decision to vary the line, how long that I draw, the general distance between different elements of my drawing, when I choose to create these different singularities, like exceptions.” She doesn’t program, or she hadn’t really when we were first talking, but she was thinking about her work very procedurally. She was then very drawn to the notion of programming, and since gone in to do work in this space, the idea not just that it would let her create different things, but that, “Oh, this might help me see the process that I use through a different lens, through a different representation.”

Steve

Is she one of the artists that you commissioned to use your tools to try it out?

Jennifer

Not yet. Hopefully soon. [laughs]. She’s, unsurprisingly, really blown up. This is the problem of talking with really talented people, [laughs] they’re very successful. Then they have a lot of projects to do. We’ve talked about doing projects together, and hopefully eventually that will happen. But she’s also doing a lot of work on her own. She’s very successful this point in time, which is great.

Steve

I liked in your presentation about these two projects, how you framed it that you were doing interdisciplinary systems engineering? There was this cool graphic, that you started from certain motivations. So maybe you could walk us through the process.

Jennifer

It builds very much on the notion of user-centered design, or other human-centered forms of design practice, where it is to start with an understanding of an existing domain and examine what people are doing in that domain. What are the opportunities? What are the challenges? Then starting to try and build tools and technologies that try to address some of those challenges. But the idea being that you’re really starting first by trying to understand the practices of the people you’re trying to support. In the case of artists, I do a lot of work initially with observing artists at work in their studios, interviewing them, analyzing their work, and making hypotheses about how they might be doing certain things. Then asking them about this, and talking with them about it. Then trying to prototype tools that might align with some of the things they’re trying to do. To start with Para, one of the things that I noticed really early on when doing workshops to people with Processing is that often people were coming from a background of using direct manipulation tools like Illustrator. Processing generates vector graphics, so it’s in many ways really powerful to combine it with a tool like Illustrator.

Jennifer

But there was this big disconnect, both moving between these different interfaces — symbolic / textual programming, and direct manipulation of vector graphics — but also these very different representations, where you’re using this imperative representation in Processing where explicitly every transformation you’re describing, whereas in a direct manipulation tool it doesn’t matter how many times you move something, all that matters is what the final position of that object is, for example. Seeing these tensions come out, thinking about them and informing them through conversations with people about why they choose to use an imperative programming tool like Processing or why an artist might choose instead to use a tool like Illustrator.

Jennifer

That really led into some of the early prototypes for Para, which is this direct manipulation procedural art tool. I don’t call it a programming tool because there’s no symbolic code, there’s no code that’s displayed to the person using the system, but there are types of things that you can do with it. Describe constraints, have iterative variation, between multiple objects that normally you would use a programming language to achieve these same relationships. The development of Para, going back to this interdisciplinary systems engineering idea, the challenge in building a system is as you’re building it, you’re making all of these — you know, everyone who’s worked in software development knows this — you’re making all these individual decisions at any point that could be really impactful, or are just necessary to get the thing up and running. The task is to understand at some point how to inform those decisions.

Jennifer

The approach that we’ve taken is to actually do iterative testing of the system with professional artists using it. As soon as the system is in any shape for anybody to use it, which is often way too early for my comfort but [laughs] probably too late in some ways — I should probably continue to try to do it earlier — we’ll have professional artists use it and try to make work with it, and observe them using it, and actively modify it in response to some of the challenges that they observe.

Jennifer

With Para, we had a professional painter use the system for two weeks while we looked at what she was doing — this is the painter, Kim Smith, who’s also at the Media Lab — then revised elements of both the interface and also some aspects of the underlying representation in response to things that just didn’t make any sense. In some ways, the ways we were representing lists were really powerful from an abstract notion, in that, like, you create a list, it was very simple, it was just an ordered collection of vector graphics, but not very useful from an artistic standpoint. You create this collection, and you have no immediate functionality that comes out of it. We added the ability when you create a list — this is maybe getting too deep in the weeds, but — that it automatically had some constraints on those objects imposed, so that when you would start to manipulate them through direct manipulation, you would get useful changes across the collection of the entire objects. This is something that came directly out of working with this one artist, and in the process of watching what she did with it.

Jennifer

That process is something that improves the tool itself, and also helps us to understand more general notions of like, “How does it actually apply to longer term use? Does it support the creation of different types of art as well as supporting these interesting small interactions? At what point does it stop becoming interesting for the artist? How do we need to think about different forms of expression that we should enable? What are the limitations of the tool?”

Jennifer

Really towards the end of the second week, Kim started using Para to make more illustrative work in the system as opposed to abstract forms. She was using the ability to automatically manipulate large collections of objects, to create patterning, an illustration of an animal and some plants. That was really interesting to see, and it was really exciting. But we also noticed right away that compared to some of the illustrations she had done, you know with watercolor by hand, the fact that she was using vector graphics was a kind of a big constraint in terms of those forms of expression. That’s where this cycle of feedback, building into the next project where you look at what people have done, helps you improve the existing system. But it also points to these directions to new work and new systems.

Jennifer

Without doing the studies with Para with artists, we wouldn’t have thought more about, “Well, should we examine these assumptions we’ve made around vector graphics, and direct manipulation of vector graphics as a way of supporting more expressive forms of procedural art for artists who work by hand, and focus more on this idea of drawing, and actually drawing with a pencil or drawing with a stylus?” That’s where Dynamic Brushes came from. That’s not to say that I think that Para was a dead end. In fact, it’s something that we’re still working on, and that project was a collaboration with Joel Brandt, Radomír Měch, and Sumit Gogia [couldn’t find a good link - Ed.]. But Joel and Radomír are both research scientists at Adobe, and you know, there are ideas from Para that are continuing to percolate through Adobe in different forms. But it also opened up new ideas, or different directions that we might go. That’s kind of where Dynamic Brushes came from.

Steve

Yeah. Before we continue on in the story, I want to just talk a bit about Para, to give people a mental picture if something didn’t come to mind. I think the tool looks a bit like Photoshop, like a normal graphics editor.

Jennifer

It actually is more like Illustrator. It has a toolbar. It has what appears to be a layers panel, and then a canvas, and a few other things.

Steve

I just want to give people a bit of a mental image. The way I thought of it is like you said, it’s not a programming language. It’s first and foremost a tool like that. But then it seems augmented with these cool computational constraints, and linkages, which I’ve seen actually a few tools start to incorporate. For example, Figma has these new components, like master and instance ones — you can change the master and all the instances will change too. It seems like this tool was exploring that space.

Jennifer

There’s been work in the past that has some of these same elements. A major frustration I have in research in general is that I feel like we’re often discouraged from building on prior strong work, as opposed to distinguishing our work as completely novel. Para has new things in it, and I would say it represents a different direction than some previous work. But you know, everything going back, from SketchPad, to Morphic, to the work that Toby Schachman has done in Apparatus, to the work that Rubaiat Kazi has done with Kitty. Then also obviously all of Bret’s work in dynamic data visualizations. It’s definitely built on a strong foundation of prior works.

Jennifer

I would say that the things that maybe don’t get focused on in Para as much that are important to me are how we tried to position those things with respect to the specific domain of visual art and illustration. Then also really how we evaluated it with artists in terms of looking at the types of work that it could enable, and the ability to support those more abstract forms of procedural art but also these more illustrative forms with animals, and plants, and so on. But yeah, it’s built on this foundation, and inspired by, and hopefully contributes to this larger body work that I think is really important.

Jennifer

Also, Sketch-n-Sketch is an important example in that space too. But yeah, this body of work that’s looking at what are the ways in which we can express procedural relationships, programmatic relationships through direct manipulation? There’s so much exciting work that’s been in that space, and so many difficult challenges to continue tackling.

Steve

The list improvement you made, that you went over — that sounded interesting. It sounds like, before, when someone would make the list, it would just be a collection of items, but they wouldn’t be linked at all. Then you changed it, so when you put things in list, they are automatically constrained to each other in some way.

Jennifer

Yeah. I mean, one of the first ideas we had was really, just, what are powerful ideas from more conventional forms of programming that we can apply to the direct manipulation context, and have them presented? The notion of a list generally is just something that can serve many applications, but in itself is specifying an order, and a collection of data, but not specifying operations on that data necessarily. Although that is useful, to have bare bones lists off the bat, as we quickly observed when you’re coming from this space of direct manipulation, and also maybe not thinking about collections of artwork in that way. What’s really powerful about Para is that you can define a relationship, and then start to play with it by manipulating the shapes themselves, by manipulating the actual artwork.

Jennifer

The powerful aspect of direct manipulation in general is that immediate feedback, where you change something and immediately get a sense of how it changes everything else. To have built-in constraints when you’re applying lists, so that when I apply a list of 10 objects, and then drag the last object and it redistributes the objects, it gives people immediately a sense of some of the potentials of using those types of relationships. As opposed to — they describe a list, and really the structure is there but nothing happens immediately.

Jennifer

There was a whole bunch of additional work in general we did in Para thinking about, “Oh, what are these really complex types of procedure relationships you might create?” We had something that looked a little bit like prototype inheritance in the system. When you duplicated an object, it would maintain the same properties as its parent until you explicitly manipulated one of those properties, then it would have its own value for that. That was very powerful, but you really had to have a deep understanding of where you might want to use that. It also really upped the burden of how much complexity you had to manage in the system, and how we might even represent those relationships, or represent that complexity.

Jennifer

In the end we settled on this simple set of procedural concepts: constraints, lists, and declared duplication. It kind of hit this sweet spot of letting you do things you couldn’t do in existing direct manipulation tools, but not increasing the complexity so much. It’s very rare that you would encounter a situation where you’re creating a cyclic constraint in Para, for example. You can, and the system will alert you if you’re doing that. But because you can do so much just with simple object-to-object constraints, or do a single constraint, and map it from one list to another list. A lot of that complexity was unnecessary.

Jennifer

I would say going forward, one of the biggest challenges we have in thinking about direct manipulation as a format for expressing programmatic-like or procedural relationships is: how do we help people debug these things? Because even if you can create the relationships, and manipulate them through direct manipulation, if you can’t understand them, if you can’t unpack them, if you can’t evaluate them when they’re functioning incorrectly, then it’s not going to be any easier than other forms of programming. To be fair, this is already an issue we have with regular direct manipulation systems, where they don’t necessarily always perform super well when you have really complicated compositions or large collections of artwork. The layers panel is not the greatest panel for manipulating an artwork with assets on the order of the thousands, or even the hundreds. There’s people doing work to address this. But I would say, if and when I continue to do work in the space of direct manipulation-based, procedural, or computational art tools, debugging and understanding structure is really an area of interest for me.

Steve

One of the questions that I still have about this list improvement you made: did you simplify lists from this generic structure to have default / standard behavior, or was it just that you gave lists a certain default that could be undone if they wanted it to be?

Jennifer

No, we just gave them a default. In Para, you can remove any constraint that’s defined. We didn’t actually take away any functionality. More, we chose what — for the context of this particular study — was an effective default.

Steve

Learnable Programming does a great job of explaining why good defaults are just so important. They’re such a simple way to improve the learnability of a tool.

Jennifer

I’m glad it was highlighted in that essay. I don’t think it gets enough appreciation in general. Something that’s often lost on people who don’t understand the power of Scratch is not understanding some ideas of really powerful but simple starting points they provided people, how they introduce different concepts. MicroWorlds is a really important idea in this space.

Steve

I think there are a few examples of places where Scratch goes too far, and they don’t let you unpack… Like, the Glide command, I have a lot of trouble with. I told my students to never use it, you know? It’s harder initially because they have to learn to point their object in the way they want it to go, and move in a loop. It’s like three blocks instead of one. But it’s so much more powerful to understand the primitives in that way. Glide is so limited.

Jennifer

That’s interesting to hear. I think this is the general tension you get when you have a pretty diverse audience of people using a given tool. I know one of the challenges that the Scratch team is always dealing with is: how can we support people who are doing really complex work in the system, without making it so that when completely new people encounter it they might be encountering types of blocks that make it really difficult for them to do simple things? There’s always a push and pull in terms of how you resolve those challenges.

Jennifer

My interest as a researcher, working in the space of designing creative systems, is finding good resolutions to some of those challenges, but even more trying to do a better job of documenting and explaining how those decisions were made, and why they were made. I feel like this is a struggle in writing about any software-based project. There’s a lot of design knowledge and information that gets glossed over, because the process of building a software tool is made up of so many important, small design decisions that really converged to make the tool what it is. It’s very difficult to communicate those decisions in a short and understandable manner to an outside audience.

Jennifer

There are other things that happen in Para that I haven’t been able to unpack and talk about. We’re definitely returning to the system to continue to work on it in other areas. But yeah, this is an ongoing challenge in the work that I do.

Steve

Let’s talk about Dynamic Brushes now. Maybe you can pick up the story where you left off — how the evaluation and feedback you got from Para led to the conception of Dynamic Brushes.

Jennifer

Yeah, so it was a convergence of factors. One was really getting to the limitations of vector graphics, where they’re very useful for some forms of expression, but if you’re someone who draws, or paints — many of the people that I was working with fit that description — there is so much expressive power you get just from the movement of different people’s hands. Everybody draws differently than anybody else, no matter their level of experience. If you look at people who have a lot of experience in a form of manual draftsmanship, let’s say like painting or drawing, they have spent years refining how they move their hand to draw.

Jennifer

I spoke at length with my former undergrad advisor, Michael Salter, who’s an illustrator and studio artist. He talked about how the opportunity of drawing is that the fastest way for him to express an idea in his head was the length of his arm. The fastest transmission of an idea from his head to reality was basically this mapping between his head to the extension of his arm. I’m misquoting him slightly there. Apologies, Michael. He really refined this ability to draw and express ideas that came into his head very quickly.

Steve

Like, someone who’s good at talking, it might be that the shortest path is from their head to their tongue or something.

Jennifer

It’s this common notion that has come up — the speed of drawing being something that’s both powerful in terms of getting ideas out there, but also the thing that affects what it looks like. Shantell, talks about how she tries to draw without thinking very quickly, because if she thinks about it too much, it’ll change her style. It’s almost like it has elements of like meditation in it, I think, to some extent.

Steve

I think Seymour Papert really liked this kind of conversation because it’s all somatic knowledge, embodied knowledge

Jennifer

There’s definitely this notion of embodied or tacit knowledge. I think that idea was really what led to Dynamic Brushes, thinking, “Let’s take the same approach we took with Para, but reframe it around this notion of drawing by hand.” You’re not using vector graphics, but what you’re doing is drawing with a pencil, or in this case like a digital stylus. How can we use that as a starting point? There’s any number of directions that might’ve taken. But then I was also having a lot of conversations with artists who regularly use programming in their work.

Jennifer

I focused on talking with artists who also did these works that had what seemed to me like their hand-drawn qualities to them — Erik Natzke, Emily Gobeille, and Theo Watson. There is a common pattern where they were building basically their own software that let them draw, but then procedurally manipulating aspects of their drawings. They were drawing with a stylus, and then Erik wrote software that would take the stylus input and manipulate the line by sampling from some other external data, like a JPEG image. If you look at some of his work from this time, it has these really sweeping forms, but then this really complex variation on the weight and the color of the stroke. That’s coming from this functionality, the software he wrote.

Jennifer

The same thing with Emily and Theo, they had a really interesting process. Emily comes from both a background in programming, but also in illustration and puppet design. Theo comes from a background that’s more rooted in software development and computer science. They have this wonderful collaborative process where Theo would write these ad hoc scripts in openFrameworks — which is a tool he was one of the cofounders of — where it would do something really simple, but really playful, like take the line that Emily was drawing and then also take microphone input and modulate some aspects of the line geometry based on the amplitude of the mic input. Or take some form she had drawn and then automatically do a circle packing algorithm within it, and fill it with circles. Emily would use these, and then generate ideas of, “Oh, what if we did this instead?” Theo would script up another tool that was a variation, and they work back and forth, and build these ad hoc drawing tools.

Jennifer

It’s like, “Oh, that’s amazing! That’s such a powerful process. Can we think about the idea of a programming language for drawing as something that is actually a programming language for building your own drawing tools, that take your drawing input, and transform it in some way that the artist dictates or describes?” That’s really where Dynamic Brushes that was kind of the start of that project, is that idea.

Steve

I just have to say: you’re a true computer scientist. You’re starting with drawings, like, “Oh, this is nice. But how do I make these drawings a little bit more dynamic? Okay, I’m gonna make a tool for artists to make dynamic drawings. Okay. That’s a good idea. Oh, you know what? I need to make a tool that artists can use to make your own tools.” You know? Yeah. The next project, you’re gonna make a generic programming language… that allows people to make tools… that will allow other people… It’s just, you’re never going to stop.

Jennifer

It’s turtles all the way down. [laughs]. I think it’s a natural process when your goal is to think about, “How can I help people be expressive with programming?” That’s basically what programming enables you to do is build your own — “tools” is not always the right term, but — your own sub-routines, forms of automation. Often artists I’ve talked to who use programming extensively describe it as, “Programming lets you build a medium.” It’s useful to take other aspects of programming like, “Oh, can we just help people automate this one thing that everyone needs to do?” That’s powerful and that’s valuable. But the more I think about helping different people be expressive, you really want to [laughs] give them the full access to the true power of programming, which is constructing your own software, basically.

Steve

I like the way you’re doing it in almost this DSL kind of way. It reminds me of Alan Kay’s STEPS project, where you have a main interface that’s easier to use, and you have an interface to just specialize the first interface, and then maybe the interface to specialize the specializer…

Jennifer

Yeah. There’s all kinds of problems that come out of that. I’m happy to talk about those at length. But I think in general, I’m a big proponent of this notion of domain-specific languages. Dynamic Brushes brought a lot of challenges along the lines of: let’s build a language around this notion of managing drawing data with a visual programming language, and then let people work with those tools in a more traditional direct-manipulation drawing environment. The data from your stylus is now going to be represented as absolute position over time, or its relative position over time, or the change in force over time.

Jennifer

Again, this was a collaboration with Joel, and Radomír, and then also Mitch was hugely influential in this work. We borrowed a lot from work in the space of computational music manipulation, where they’re using very simple waveforms to modulate sound, or generate sound. We simply applied them to modulating the line that was being drawn — the position of it, the geometry of it, also the stylistic properties of it. You can have a brush in Dynamic Brushes that follows the stylus X and Y position, but modulates the geometric scale relative to the origin along a square wave. You get this geometric variation, but then the position is totally determined by how the person is drawing.

Jennifer

It’s this incredibly simple program from one viewpoint. (The program itself is very short [laughs] — that’s not always the measure of simplicity in programming.) But then you give it to different artists, and each person makes something different with it. Whereas in Para, although I liked Para a lot, and I still love it a lot, a simple program — because it was using the same geometric primitives — was a much higher threshold for different people generating different things, off the bat. That’s probably the most powerful thing about Dynamic Brushes, is that it just brings in this form of data that’s highly expressive, and you can do a lot with simple programs.

Jennifer

You can also do very complex things. One of the key goals of the system was: let’s not just see what happens when we treat drawing as an input, and let people manipulate it, but let’s enable people to create tools that aren’t available in other drawing software (like Illustrator, or Photoshop), where they can have things drawn that correspond with what they’re drawing by hand, but they can also have things being drawn automatically, or independent of what they’re drawing by hand. I don’t know how in detail you want me to go into the programming representation. [laughs].

Steve

I do want you to go into it because I think it’s fascinating. I just want to draw a mental picture, and I’ll do a quick sketch, and you can fill in some of the details. Dynamic Brushes, the picture I saw was: you’d have iPad, and a computer screen. On the computer screen, it looked a bit like Scratch. You had like blocks that you could connect. Then on the iPad you were drawing, and the thing you were coding on the desktop screen was the brush. As you changed the brush on the desktop, and then you used your iPad pencil on the iPad, different things (like squares) would come out of your pencil instead of just the line.

Jennifer

Yeah, exactly. The basic idea was that the desktop environment had a visual programming environment which gets compared both to Scratch — and it probably owes more to Scratch than anything else — and to node-based dataflow programming like Max/MSP or Grasshopper. I would say what you’re actually creating are state diagrams. It’s a state and constraints model, which…

Steve

Statecharts?

Jennifer

Yeah. We looked a lot at Steve Oney’s InterState as a way of informing the design of this tool. It’s technically not the same thing as the way the dataflow languages and Grasshopper work, but it looks similar in that transitions are event-driven. It’s similar in some ways to Max in that regard. Then the iPad environment looks kind of like a really simple version of a tool like Procreate or some other tablet-based bitmap drawing environment. But instead of having a tool palette that is defined up front, the tool palette is whatever programs that you create in the programming environment, and they’re linked.

Steve

You said bitmap. You’re not doing vector graphics anymore?

Jennifer

No. The reason we did bitmap was because we started earlier testing Dynamic Brushes with artists. We were working with people who had worked primarily in a digital painting scenario, and they were used to bitmap tools. They wanted opacity. They wanted the ability to feather the edges. You can do that with vector graphics — there’s a version of Dynamic Brushes that is completely vector, but we haven’t returned to that. It was more just the audience that we were looking at. There’s no reason it couldn’t be a vector tool necessarily, but we chose to align it with bitmap drawing because that corresponded with the types of people that started using the system early on.

Steve

Cool. Yeah, I think I interrupted you. You were going to talk about some of the programming model of stuff, interesting bits.

Jennifer

Yeah. It’s so funny. I usually give this with some images behind me, so it’s a useful practice to describe it without images. I find I often design my languages around three primary programming concepts or components. In Para it was constraints, lists, and declared duplication.

Steve

Why three?

Jennifer

It’s, like, the magic number. Arguably in Dynamic Brushes you could say it’s four.

Jennifer

(1) Primarily, it’s data bindings. Declarative mappings between some input data, most commonly the stylus. But then you also have the synthesized data like function generators, like a sine wave. Then you also can import in external data; we also added the ability to use mic input, the accelerometer of the tablet. Any data can be mapped to a brush property. The properties are obvious things like position, and color, and opacity, but then also less obvious but very powerful things like geometric transformation, rotations, scaling.

Jennifer

(2) Then you describe data bindings inside of states. So that’s a second thing. Then this is basically: whenever a state is active, the data bindings within it are active. You can only have one state active at a time, just the traditional notion of state machines.

Jennifer

(3) Transitions between states are driven by these event-driven transitions that we predefined in the first version. You have a limited set of events, similar to Scratch, like stylus events — when the stylus is down, when the stylus is up — or when a certain interval of time has elapsed, or when a certain interval of distance has been traversed. Then we’re working on a new version which has a more expressive event definition structure, so you can describe more arbitrary events or evaluate arbitrary conditions.

Jennifer

(4) Yeah, so states, bindings, transitions, and I guess the fourth thing would be: there is also a small set of actions, which are just very simple methods that are called once. They can be called once on any transition that occurs. For example, you can initialize a new stroke when a transition occurs. Or you can start a timer, which is really useful for doing time-driven transitions.

Jennifer

Or you can also call this action called spawn, which is the most powerful, but maybe most complex aspect of the system, which basically lets one brush generate another brush, or multiple instances of another brush. So the reason we added spawning to the system was because of what I was talking about several minutes ago, where we wanted the ability for the artist to create brushes where multiple things were happening simultaneously with one input and multiple outputs. Or you were drawing on the canvas, but had some automated things that would be drawn in response to what you are drawing. So spawning basically lets one brush generate copies of itself, or brushes generate automatically that draw on a timer interval as opposed to being driven by changes to the stylus input. The example we were really trying to build up to was this drip brush, where as you draw a line, drips automatically come off of the line and fall down across the canvas.

Jennifer

But yeah, there’s been other work we’ve done in that space. You can generate really complex radial forms, where you’re just doing one input and then you automatically have multiple radial branching forms coming out from that one input. It’s a lot easier to show with videos [laughs]. In a prototype version, we added the ability to actually do recursion, where a brush could spawn instances of itself, and then we had a termination condition based on the number of brushes that have been spawned. We didn’t actually use that in the final version of the software, because recursion can generate some tricky debugging scenarios. We’re still working on refining that part of the system. But that’s the overall idea.

Steve

Yeah. I don’t know why it just occurred to me — I came up with a way to extend the level of abstraction here. It’s probably already occurred to you. You just take this, but bring it into a VR / 3D world, where instead of making brushes you’re making, like, clay basically. It’s like a clay making kit, and so you can make clay over here, you mix the clay programmatically with blocks, and then you like walk over… or maybe one person’s mixing clay, and the other person’s like shaping the clay. So, it’s like the same thing, but for sculpting.

Jennifer

Yeah, that’s interesting. I’ve talked with people about doing stuff in VR, in a 3D application. We chose 2D originally, because I love 2D art. It’s also a lot of work to build these systems, and any corners you can cut in terms of simplifying the things you can build is a good starting point. But yeah, we’ve talked about doing a 3D version of it.

Jennifer

Actually really interested in applying it — and we have done a little bit of experimenting in the space already to…

Jennifer

One way of thinking about this is, I kind of framed it in the lens of tool development. You’re building your own tools. But another way of thinking about it is reframing drawing within the space of interaction design. So instead of actually making the artifact, what you’re doing is defining the interactions you want to have with the system that’s going to then generate an artifact.

Jennifer

That idea is something I was thinking about, or kind of came to me from these conversations I’ve been having with the artist and engineer Madeline Gannon, who is probably best known for the gestural robotics control she’s done with these industrial-scale robot arms. But she’s actually doing all this work from a standpoint of: what are different ways in which we can think about digital fabrication interaction and control, and what are the ways in which we might think about CAD (computer-aided design) not as being this process of sitting in front of a computer and creating a design, and then sending it to the machine to be fabricated, but more of this process that looks more like what happens when we make an object in a more traditional method. She’s really interested in on-body fabrication and clothing manufacturing, where you actually might design an object while you’re working on a mannequin or actually working with the person themselves.

Jennifer

She has this really powerful idea: can we think about interacting with some autonomous agent, not as “upfront we describe what it’s going to do with the artifact, and then that’s translated to toolpaths, and then the system executes it,” but instead, “what are the class of interactions we might want to have, or what are the ways we want this autonomous agent to respond to us as we work, and let’s put the designer in the position of describing those, and then being in the context of actually working with this machine / autonomous system / agent to collaboratively finish the artifact.”

Jennifer

I don’t know if “collaboration” is the right word. Metaphors are important here. I’m not sure I’m choosing the right ones.

Jennifer

So I’ve been thinking more about Dynamic Brushes from the standpoint of: what would it mean if we’re describing not how a digital brush is performing, but how the head of a CNC machine or a 3D printer is moving in response to decisions we make in the moment of digital fabrication, as opposed to ahead of time. It maybe seems like a big jump, but we’ve already done a version of Dynamic Brushes where we connected it to a CNC machine, and used it to create brushes that actually draw in large format on the CNC machine.

Steve

I was thinking about how you said that you have, like, electronic circuits, but now they have a dual purpose. Part of what’s great about gestures is the embodied knowledge that we have, but also just the joy of moving our hands in ways that aren’t just twitching our fingertips. Like, it’s just more joyful to like move our whole arm, but that’s just our arm. So I was imagining one day it’s going to be like, you’re just going to dance. The way you move your whole body is going to be somehow mapped to some other creative form of expression that might be a physical object. I like the idea of allowing people to design their own interactions based on how they have embodied the thing they want to express.

Jennifer

I’m really excited by that too. I think this also gets to the heart of like the challenges I’m most interested in addressing right now. One of the powerful things about programming is you can create these arbitrary mappings between any input to any output, within reason. That was actually one of the really nice things that came out of doing these studies with artists with the Dynamic Brushes system.

Jennifer

I actually had this moment of observing this painter have that realization. He was working with the system early on. He would say (paraphrasing), “Every drawing tool I’ve worked with, the stylus position dictates the brush position. Why would you ever not want to map stylus position to brush position?” Then at one point he said, “Oh! I can transform the stylus position in some ways, where I can use it to dynamically control the speed of the brush in addition to where it’s actually located. Or I can have it so that the position changes the color of the brush. That’s interesting. Oh! That’s totally arbitrary how I mapped these things. Oh! Every tool that I’ve used, those relationships are arbitrary in the space of software.”

Steve

It’s like, “Oh, I can be a wizard. I don’t have to like take physical pigment, and like spread it around with matter. I’m a wizard. I can have it do what I want.”

Jennifer

So that was really cool to see. That’s one thing I’m super excited about in helping people to create their own software and tools of programming. You can think differently about these relationships and these mappings. The hard thing is then — there are all these wonderful things about when you’re getting to the space of mapping data from interactions that are tacit, or embodied, or gestural, there are all these understandings that people have about that, the way they move through space, the way they draw — to do really powerful, or specific, or precise things with them in a symbolic context, it can be very useful to understand them from a different perspective, from more a discrete perspective, from a more formal perspective.

Jennifer

Artists think about (for example) the way they draw as a time-based act, many artists I talked with, but that doesn’t mean that they think about it in the way that Dynamic Brushes represents time with regards to drawing. That doesn’t mean that they didn’t think about, you know, “it takes me approximately 10 seconds to move this distance, and I want to have this behavior in my drawing execute on a certain time interval.” There’s a non-trivial process that goes between this embodied or tacit understanding of drawing as a time-based process to, “how can I symbolically manipulate that to do the thing that I want?” Same goes for physics. I’m always sensitive to the fact that there’s a tension there, and there’s a chance for trade-offs. I don’t think you can preserve everything you get from one way of knowing, like a tacit way of knowing, when you move into a symbolic or formal representation. But I do think there’s power and utility there.

Steve

What don’t you think is possible — preserving which one can’t you go into the other? Yeah, sorry, I just missed it.

Jennifer

I think it’s both ways, right?

Steve

You can’t transmit from one to the other without losing something in the middle?

Jennifer

This is maybe getting too abstract, but any translation is an exercise in losing something, right? [Laughs] There’s value in it, but…

Steve

Not technically. You could translate things losslessly.

Jennifer

I’ve been trying to write about this lately, and it’s been very challenging, so I want to choose my words carefully here. Earlier I talked about how drawing is this process of… often speed, and not thinking, is an important element of drawing. Artists train themselves to build up this physical intuition, so that they’re not explicitly analyzing everything that they’re doing, and instead reacting.

Steve

Like people who play sports.

Jennifer

Maybe. I’ve also observed programmers — and people have talked about this — where they’ve reached such a familiarity and level of skill with programming that what they do is almost reactionary or intuitive in some sense when they’re developing something. But I would say, my experience of programming is in general a process of analysis, of taking an idea and breaking it into smaller, achievable problems, and that is very different from this notion of reacting in the moment.

Steve

Almost a System 1 / System 2 kind of Kahneman’s distinction?

Jennifer

I want to be careful [laughs]. There’s been a lot of work in the psychology of programming, and also psychological and theoretical work around tacit and embodied forms of working. My work could benefit by drawing more heavily on that space, although I am really inspired by things like The Textility of Making, or The Reflective Practitioner. Those works really drive how I think about some forms of expression that I’m interested in supporting.

Jennifer

I recognize the tension in my own work between trying to combine something that is often a fundamentally tacit and embodied form of creation with something that is often most powerful as an analytical form of creation, which I think programming is in many respects, and that they are different pathways you can take in that process. The pathway I’ve taken is to try and select programming representations that preserve some really important expressive aspects of the passive form of creation like drawing. But I also recognize that they’re going to shift some of the things that people are doing in that space.

Jennifer

So Dynamic Brushes, I never have claimed that it’s something where people can just automatically learn the programming language and start creating tools and drawing like they were before. No. Like, they spend time learning the language, they spend a lot of time authoring tools, which they wouldn’t be doing necessarily with other systems, and there’s more labor placed in that space of learning symbolic programming, and writing and debugging the tools they’re building, and also understanding what are the trade-offs in that space.

Jennifer

Another approach might be to build a really expressive set of procedural drawing tools, give people the ability to tune some parameters of those tools, but don’t have them invest in the actual process of writing the code itself. There would be a lot of benefit to that approach, and there have been things that people have done in that space. But I think now I’m much more focused on this idea of recognizing these trade-offs, recognizing that you have to think about drawing numerically, you have to think about it analytically, you have to think about it systematically. What’s the way in which we can help people make that transition more easily?

Jennifer

Most of the work we’re doing with Dynamic Brushes right now is really around this idea of: how can we show people representations of the drawing input they’re using in ways that help them to understand why a tool is functioning the way that it is, why a state change occurs when it does, and help them make informed decisions about the process of programming. Yeah, it’s a trade-off [laughs].

Steve

I definitely see the trade-off. I do a lot of thinking in this area too, but I’m gonna be a little bit less careful with my words. I’m just going to talk around it to evoke what I’m getting at. I see on the one hand, there’s things that humans already know, like we have a very embodied sense of gravity. We’re not born with it, but I think over the first five years, like a Piaget kind of way, we get it, you know? Like, “Oh, okay, I drop things, I expect them to fall.” You feel it in your body, and you expect it in objects you manipulate. But then it takes a long time and a lot of formal training to get someone to transfer that to a knowledge of physics, like an abstract knowledge of physics. There’s quite a lot of education that has to go to teach that formally.

Steve

A better example, one that’s kind of close to my heart, is: I was a Logo kid. I was a math-phobe who was exposed to Logo. I learned how to draw a circle. I eventually intuited on my own, “Oh wait, if I just walk up a little bit and turn a little bit, and do that 360 times, I got a circle.” Then when I eventually went to calculus, it was just so easy to understand what a derivative was, because I’ve walked along curves before. Anyways, what I’m getting at is… One way to put it is, Alan Kay has this critique of Scratch that you may have heard of. I guess you have worked on Scratch. But I feel like you’re maybe one of the better people I’ve had on the podcast who could defend it from Alan’s criticism. Basically, there are certain human universals, or things that humans are good at, like drawing, and singing, and dancing, and playing. But then there are certain non-human universals that are also very desirable, but they don’t come naturally. They require a certain kind of investment. But then there are these interesting ways to get humans from the universals, the things they already know and love, and transfer / leverage that love and knowledge into a new, a more powerful, but also harder domain. So anyways, I’ll let you take it from there.

Jennifer

Yeah. That makes me think of — and maybe this is what you’re drawing from — Alan Kay’s essay User Interface: A Personal View where he talks about this notion of how you can move between more concrete forms of understanding to more symbolic forms of understanding, and symbolic knowledge versus visual knowledge. This is coming from Jerome Bruner’s theories about different forms of knowledge, and I’m not representing it in its entirety. But this idea of symbolic knowledge being this really powerful form of representation, but maybe less natural for people to understand, and visual and kinesthetic knowledge being more familiar and more natural, but that by working in the visual and kinesthetic domain, you can help scaffold the process of understanding and manipulating symbolic knowledge.

Jennifer

I’m really excited by that idea, and it’s something that I need to do a better job, with some of the systems that I do, in thinking about. So much focus initially has been on how we select an appropriate representation for a given domain, with a knowledge that there’s going to be learning challenges or conceptual challenges here, and the ways in which we support people in making connections or moving to really understanding the symbolic domain, when they’re starting with a visual or kinesthetic form of manipulation.

Jennifer

I think there’s a lot that I can do that is, like, not hiding information, showing information visually. There’s also a lot of huge challenges. One of the very concrete challenges in Dynamic Brushes is: we have people working in a geometric domain, 2D drawing. Then we have this type of data that is geometric. It has natural geometric properties — the stylus input. We have these other data types that you can map to geometric properties, and that’s very powerful, but they’re more abstract. They don’t inherently have a geometric quality that aligns with the geometric properties of the 2D canvas. Like a sine waveform. I can draw a sine waveform on a canvas, but that’s also misleading in some respects, because the dimensions of it are going to be arbitrary relative to my drawing. It’s also very powerful to understand that data more abstractly, or numerically.

Jennifer

So there’s this idea of: I want to help people draw those connections. I also don’t want to mislead them. I don’t want them to have an incorrect intuition about how to think about this type of input and this data. It would be a problem if the painter got the idea that, “Oh, there are certain types of relationships I’m supposed to create with data in Dynamic Brushes, and other types that I’m not supposed to create.” I don’t think I have answers to that, but it’s a topic I’m really interested in.

Steve

One of the big challenges that I see in that is: the more programmatic of an interface you expose, the less constancy or repetitiveness they can expect, so the harder it is for them to build up those somatic intuitions that are so important. Part of what allows artists to get really good with a paintbrush is that paintbrushes are pretty similar. But you’re allowing them to create all these new paintbrushes. So one solution to that problem would be: they spend a lot of time iterating on what dynamic brushes they want to make, and then they will leave it kind of like it is, and then make a bunch of art. Then the next series they’d modify the brushes again. If you modify the brushes too much, I could imagine that it’s hard to build up a certain intuition of what different gestures actually accomplish.

Jennifer

Yeah, and that’s the behavior we’ve observed so far with people using the system. They will spend a lot of time in the programming environment, experiment-drawing, and then a lot of time in the drawing environment really only making minor tweaks if anything to the brushes. But I’m not saying that’s wrong. I also think that we’re working hard to find ways to enable people to move more easily back and forth between the two spaces, because there are ideas that emerge during the process of drawing that you want to be able to implement in programming, and to be able to translate to the programming environment. It’s not always easy.

Jennifer

So we’ve done really simple obvious things. Like you can record some drawing input, and loop it back through the system while you modify the code, so you don’t have to experiment every time. You can immediately see how your changes update the drawing. There are bigger questions that I know have been explored by other people in other domains, this idea of, “Oh, do I ever want to be able to do something in the drawing environment that actually describes or manipulates a relationship in the program?”

Jennifer

Bret has done some really cool stuff in this space. But once again, you get into that area of, “How do I distinguish between what I could do that’s possible, versus what makes sense, and what has a meaningful semantics?” Like, I love the idea of having people be able to draw a waveform in the drawing environment. That’s a great idea, you know? Less clear [laughs] — I’ve talked about this a lot with people on the Scratch team — how would you geometrically describe a conditional? Or not, you know? You could come up with an idea, and there might be some cases where it makes sense, but there might be a lot of other cases where it might not make sense. So yeah, a lot of challenges in this space.

Steve

One of the things that makes this very concrete for me, this idea of a standard interface versus a programmable interface, is: 10 years ago, my dad got this whole new TV system, and it came with this touchscreen interface. He could never turn on, let alone use this TV. The newer interface, like the state-of-the-art of today, is made by the same company, but it’s not touch screen anymore. It’s back to an old-fashioned interface, where you actually specify to the company what you want printed on the buttons, and they print it onto the buttons. So it’s like the same amount of programmability, but once you’ve set it up, they print it in a way that makes it much more… like my dad, not only can he turn on his TV now, but he doesn’t [laughs] have to look at the the remote to know where the buttons are.

Jennifer

That’s interesting. I think there’s need for more work in the domain of creativity support and systems research looking at some more longitudinal impacts of use patterns and learnability for some of the tools we build over time. There’s this idea that people should be able to learn a system really quickly, or use it really quickly, and if they can, then it’s a good system, and if they can’t, then it’s not an effective system. But that’s not necessarily the right metric for how we think about how we might support people using software, or using a programming language, or a creative tool.

Jennifer

Some of my favorite things come out of looking at what artists who have been using Photoshop and Illustrator for a really long time do with it. They use the filters in ways that I had no idea that you could use them in those ways, and they’ll call them “hacks”. So they go, “Oh, I use this hack. It’s not really how it’s supposed to be used, but I get this effect by combining the blur filter with the…” I’m not gonna remember the filters. I never use them. [laughs]

Jennifer

It’s interesting, because you could see that as an unintended use, or you could see that this is what happens when people use software for an extended period of time. They adapt it to their own applications, and that’s a really powerful and valuable thing. But it’s so rarely reflected in how we present and evaluate systems from a research perspective, in that it’s a system we build over a year to six-month period, and we test it for (hopefully) for a while, then we kind of understand what people can do with it in that timeframe, but not what people might do with it using it over a year, two years. There’s certainly exceptions to this, but…

Steve

I have a very funny illustration of this kind of dialectic. I’ve been having this silly conversation with a stranger on Twitter. His position is that programming should be as intuitive as possible, and my position is that it’s not necessarily a bad thing if it requires a certain investment but that investment pays off in power down the road. So he sent me, yesterday, a video of a monkey using a touchscreen. He’s like, “See, programming should be this intuitive, that even a monkey can use it.” So I sent back a video of a time-lapse video of someone who didn’t know how to play piano. At the end of the year, he could play really intense piano. It was like, “No, no, this is what programming should be like.” I think it’s funny, the dichotomy of the two different views of immediately usable versus rewards investment.

Jennifer

Yeah. I guess if you think of programming from the interface or environment perspective, yes, we should make things easy. Important asterisk there, which is: easy without restricting the important forms of power, or expression, that we want to deliver. But if you think of programming as a way of thinking, it is almost not relevant to think about how to make this way of thinking easy. We want to provide pathways into engaging this way of thinking, but you can’t trivialize the difficulty of learning abstraction.

Jennifer

I remember when I first really understood the concept of object-oriented programming. It’s a powerful idea, and I don’t think you want to say, “Well there are things that are hard about object-oriented programing. Let’s choose a simpler idea that’s more intuitive, that’s more obvious to people.” I mean, you’re diminishing the power of that idea, you know? Arguably, object-oriented programming is more aligned with how people might think about things than other programming models. But there’s value in understanding and learning different ways of seeing the world, and programming offers that, I don’t want to diminish that.

Jennifer

Also, the idea of what is intuitive. I use it a lot, so guilty of this, but — we don’t really have a good grasp of, I think in many ways, things that are intuitive. Because what’s intuitive for one person could be totally different from what’s intuitive to another person. You know, the notion of Dynamic Brushes — we chose this representation for drawing, not because we thought, “This will be the most intuitive representation for drawing, because this is how people think about drawing,” because every artist I talked to thought about drawing in a different way. There were some similarities that we tried to recognize. But overall, the idea was, if I build a programming representation for how I think about drawing, it’s not going to correspond with how this other person thinks about it. It’s an impossible design challenge.

Jennifer

So I think there are other principles we can involve in terms of, “What does this let people express? What does it limit them from expressing? What are the reasonable scaffolds we can provide to helping them learn it?” We want to think about things in terms of correspondence, and how close the mental model of a given audience is to a given representation, but that’s not always feasible. I would argue in programming it’s often not feasible.

Steve

I like that answer a lot. I didn’t know if that’s what you were gonna say. I thought maybe you’d come out on the other side like, “No, no, no, it has to be as easy and natural as possible.”

Jennifer

Yeah, easy as possible, but no easier right? I’m ripping off multiple people with that statement. [laughs]

Steve

So back to some of your work, I liked your discussion of the evaluation of it. You talk about how tricky it was. Whenever you make a tool, it’s hard to evaluate, because you have to evaluate how people use the tool and what artifacts they produce. So it’s like we are one step removed in a way. But I think for a creative tool, it’s even harder. I’m someone who designs tools for people to build user interfaces. There’s this project called 7GUIs where there’s seven user interfaces. I just can watch people build those seven interfaces in my tool, and call it a day. But when you’re building a tool for artistic creative expression, you’re building a tool for people to purposefully break boundaries, and do things that have never been done before, so it seems really hard to evaluate that tool.

Jennifer

Yeah. It is hard. One of the best metrics, that I think Mitch and Leah both held up, and I’ve similarly tried to pursue this metric in my work, is: you know a system is successful when you see multiple people making things that you didn’t know were possible in that system. It’s great if people are able to make complex things, or able to easily do the things that you thought the system would be good for. But if someone uses it to then do something you had no idea was possible, then you’ve succeeded in some way, from a creative standpoint. How you design for that is not obvious. [laughs]

Steve

I think you just design with a blindfold on. “No, I couldn’t have imagined they did that. You know, I wasn’t looking.”

Jennifer

Jay Silver has this notion of developing a tool around a project space. So if you develop a tool that’s able to create one type of project, then you’ve get a point. If you know that the tool can create these two types of projects, then you’ve got a line, and you’ve got a spectrum of projects across that line. If you know a tool is able to create three types of projects, then you’ve got a space, and you’ve got a larger area of possible projects that might emerge within these outer parameters. He describes this in his dissertation.

Jennifer

I think that’s one way of approaching both the design, and then evaluation. A lot of the work that I’ve done gravitates towards this. You try to choose these targets of the types of expression you think your tool should be good for, but pick them in a way that they are different enough that you’re hopeful that there will be some interesting variation in between them. You design for those, you inform that through different processes, looking at what people do while you’re building it, and so on.

Jennifer

Then when you evaluate it, you also think about, “Who am I selecting that corresponds with or diverges from these forms of expression that I tried to design for,” and then looking at what they do and how it aligns with these points you’ve created versus unknown areas, or points between them. Really, trying to look at both what you’ve set up as the types of things you think the system enables making, and also what people make with it, and how close or how far it is from those things. So that’s one reason that I’ve also tried to have people use the tools that I’ve built over a long period of time, because you get more interesting artifacts out of that. You have more data with regards to the forms of expression that are possible by analyzing those artifacts. It’s definitely a qualitative method of evaluation, and there’s a lot of noise in the data, so there are limitations to it, and I recognize that.

Jennifer

One thing that I’m trying to move towards is actually scaling up some of these studies. So we’re working right now on releasing Dynamic Brushes as a stable app for people to use — although that’s a long process — so that we can look at, more generally, what do people do with this system independent of a formal study, or in the wild? That’s really inspired by some work that Leah and Benjamin Mako Hill, who’s a professor at U-Dub, did with a LilyPad. They looked at what people were doing with it over the long term in actual practice, by looking at sales data and work posted to different online communities, and doing more of a longitudinal and data-driven approach to analyzing the creative affordances of this specific platform.

Jennifer

I’m always interested in other forms of evaluation, but I think that fundamentally, if you’re designing for creative expression, you need to accept that there are trade-offs, in that traditional metrics for evaluation, efficiency, speed — those are great, but they won’t work. They won’t tell you the whole story here.

Steve

Yeah, that was one of my questions, “Can people use these tools?” Exciting to hear that they’ll be coming soon.

Jennifer

Yeah. Para might be coming in a different version than our original prototype. Dynamic Brushes, we’ve been building it. We’re working on another version that has these debugging support features in it. My goal is to get it in the app store with the release of that work. It’s another challenge of academic research — it’s often not incentivized to release your software, as important as that is. So I’m trying to find my own strategies for doing that. Often, the paper is the artifact.

Steve

I guess this is kind of dovetails with another question I have. The interdisciplinary / systems engineering method that you did — where you do this need-finding research, and then you build a tool, and you watch people use it, you evaluate it, then you repeat and build a new tool — it feels a little bit rare to me. Like, I didn’t think that academia would incentivize this kind of work. It seems like academia doesn’t seem to support need-finding as much. I was excited to see that that was a part of your process.

Jennifer

It does and it doesn’t. I’ve been fortunate to work primarily in the field of Human-Computer Interaction. It’s a big enough community with a diversity of thought, so there are definitely people who are more interested in really quantitative evaluation, forms of measurement that are less noisy. But there are also huge groups of people who really value tackling messy problems, and also approaching it from a human-centered design perspective, of which need finding is a big component. These things take time, building software takes time, testing it with people over a longer period of time takes time and resources. Yes, that’s not always supported in an academic context, but I’m also encouraged by the fact that there is — increasingly in computer science research — emphasis on things like open source, or verified artifacts, or functioning tools as a contribution and as something that we officially recognize.

Jennifer

So, my hope is that there will be more official incentives for doing this work in addition to the knowledge gained that we can get from it. I’m also excited to see as I continue in my academic career, running a lab as opposed to working as a student, what opportunities I’ll have for more collaborative forms of production, and trying to scale up projects over a longer period of time and with more people involved in them.

Steve

Kind of like Scratch, I guess. It’s like the big example?

Jennifer

Scratch, I think, could only happen at the Media Lab. Scratch is a very unique example, in that it’s basically a small company being run inside a research group. I think it’s unlikely that I would…

Steve

Could pull that off?

Jennifer

Yeah, you know? Mitch has made really good choices in that respect, but he has made a decision to… He wants to get programming to as many children as possible, which I think is a really laudable goal, and Scratch is an approach to doing that. I think I’m maybe more leaning towards one of the benefits of academia in that you can explore many different directions. I want to release software, and I want to think about building systems that have a lifespan beyond the paper, but there are many ways to do that.

Jennifer

For example, I’ve had great partnerships with Adobe, and industry, and I’m really interested in pursuing those going forward. There’s trade-offs to that, but so far that’s been a good option for me. There’s also opportunities to contribute to other creative coding communities that are more focused on specifically putting systems out in the world. The work that the p5.js and the Processing community, and also the openFrameworks community, is incredibly inspiring and valuable. I also think about ways in which, in computer science academia, I might be able to make more connections between the work that’s being done in the creative coding community and the work that’s being done at conferences like CHI, human-computer interaction research, and programming languages research, and how there can be an exchange of ideas but also an exchange of resources in some respects.

Steve

Cool. Well I think we have taken enough of your time.

Jennifer

This is great. I really enjoy hashing through these ideas. Clearly, I have a lot to continue to hash through, but it’s been really fun to talk with you about this. Love being connected with new people thinking about similar ideas. It’s always encouraging to talk with people who are interested and value the notion that programming can be better, and that by building different programming languages, or different types of programming, we can open it up to new groups and new people. That’s not always an idea that everyone believes in, so it’s good to be reminded of it.

Steve

Well before we sign off, I wanted to give you an opportunity to list some of those places on the internet where you can be reached, and different ways that you want to be reached (if you’re looking for collaborators, or anything like that).

Jennifer

If any of these ideas are exciting to people, I’m starting up a research group at the University of California Santa Barbara in July, as an assistant professor. We are actively looking for people who are interested in potentially pursuing these ideas under a PhD or a Master’s degree, but also visiting researchers, visiting artists. If you’re excited about this, and you’re interested in talking more, definitely reach out to me over email: jmjacobs@ucsb.edu. But you can also find me on my website, which is just jenniferjacobs.co. I think that’s probably the best way to talk with me. I’m also on Twitter.