Sketching in Hardware: Discussion notes from last day

Jeff: moving Arduino onto Eclipse to support more complex and advanced development on a real x-platform IDE, esp. support for writing libraries. Not fun in Arduino IDE - wants header files, check in/out.

Jan: building a shared history, reminded of Ubicomp the ACM conference in its first years. Was incredibly repetitive. We are doing some of the same. Ex: Arduino-like boards and toolkits. Today, we saw two different directions in graphic programming for microcontrollers. Knowing that these are out, can we help head off more repetition of these two directions? Science does it through conference proceedings and journals. How does design do it?

Mike: ie, Tom's top 10 projects at ITP.

Tom: Goal for physical computing is empowering people who are afraid or skittish about technology in hands-on way. So projects will be repeated, because that's how you learn. You need to distinguish btw what is learning and what is research. As educators, we need to tell students that. But we do have to let them reinvent the wheel occasionally. There is no "the community." There are several different communities in this room. Just because something is "solved," doesn't mean it's SOLVED. Diversity is necessary for continued growth. I (Arduino) don't want to become the Microsoft of physical computing -- but what are some useful x-platform standards? (like control-z)

Liam: Eclipse shows a design-by-committee effect. So many modules. Maybe what we need is a more advanced version of the Arduino IDE, w/o moving into Eclipse itself. Maintain the successful parts of the IDE.

Tom: everybody should assemble a list of favorite parts of IDE.

Mike: the Firefox of IDEs?

Bill: We cannot plan ahead to make communities -- we can only look back. Happier in following instincts. Worries about drive to produce a huge single community.

Phil: [responding to Jan] working with Shigeru to merge server and just have one that everyone can use. [responding to Dave and the shunning of tethering] Depends on application -- sometimes tethering makes sense. Even if wireless. For his students media is central.

Nick: Not doing his tool for research, but just to make a valuable tool. There's value in constantly re-evaluating without making a fuss as new architectures and capacities come out.

Andre: would love to see a more powerful board. perhaps something that would assist the kind of robust prototyping in corporate practice where you need to show something to your boss.

North: Trying to implement curriculums that teach problem-solving. Need a successful 5-min hello world. But they also have to learn to muddle through. Plug-n-play is counterproductive in helping people learn to improvise solutions and work through problems. People need to feel triumphs.

Bill: Teaching in art vs teaching in engineering -- they shouldn't mix.

North: Not interested in turning out Arduino interests -- interested in turning out people who have strategies and tactics for critically engaging with tech.

Kipp: But you do need to constrain how people get themselves into trouble. So that the solutions address what you're trying to teach. Uses Arduino because his engineering students are also afraid of hands-on work -- just as afraid as industrial design students. Artists inspired by engineers, create compelling science fictions, which then inspire engineers.

Tom: Agrees with North. Glass-box enclosure. Some things in Arduino are usefully broken. Students in an art school reach the limits of the tool pretty quickly. And so we let students extend the tool. Disagreeing with Kipp a little -- in the sense that artists and engineers don't need to receive an encapsulated version of the other side -- they need get a clearly explained/accessible version. You can do both as long as you respect both.

Mike: Incentives: tensions in how easy or far it is to reach the reward. How do you get people to take one step forward?

Phil: As Ben asked, what direction is that?

Nathan: First year of engineering school is just really painful. So teachers are trying to make the first year easier by reaching people young. The problem is that people are using "Arduino" as a generic term for a microcontroller.

Dave V.: Last year, we talked about the differences between open source sw and hw. Interoperability is kind of fixing that problem. Ie, Kenny -- which moves Max programming to Arduino. Different ways of doing the same thing is one way of creating this ecology of difference while not starting from scratch.

Dan: In education, you need both the easy solutions and the amazingly inspiring (but very difficult) examples of genius. Otherwise, why else will people play with the technology?

Alexandra: Worried about sense of history -- the same conversations happening again and again as more people join the group. Ie, work at the Slade School in the 1970s was groundbreaking and forgotten. Tension: btw art world and design world (specifically product design). Not yet any good examples of people in product design world who have done things with this stuff.

Mike: well, there are -- it's just that the designers/products are anonymized. That's the lesson of Tenori-on. You rarely see the process. You lose the history of its making. Opportunity to change that by having small-scale, "hand-made" objects that are "signed," that makers take personal responsibility for.

North: Design field a throwback to idea of heroic inventors rather than a real-time back and forth, in which the occasional heroic effort depends on continuous contributions of a crowd of people. Open source. Making the killer strategy for making the killer means by which you interoperate btw systems. Why can't the goal of a designer be to export these skills to the culture in general? Which is what the Arduino does. It's an access point to the black box. First you play, THEN you right the history. Which is more interesting than figuring it out for everyone in advance.

Mike: summing up themes: IDEs, history. IDEs as potential maintainers of history? Modernist philosophy of eternal, authorless designs proven false - we need hands-on engagement with things so that we can make new things.

Ed: Responding to Nate's point. Is it our responsibility to call out that kind of mistake everytime we see it? What about attaching the suffix "duino" to everything? Doesn't that just perpetuate it?

Ben: Look at how democratization of tools has happened in many fields. Filmmaking. Music. The same lifecycle: tools come out that promise to unseat a professional elite. There's a lot of excitement. Then people realize that the {film, music, writing} is really hard to do. And you see a reemergence of the professional. So what happens when this field becomes a bit more professionalized? Could we just skip over the popularization.

Liz: celebrities come from popularization. As does history, common sense, and other things we take for granted. Without attracting many people to a certain version of the world, it never becomes a fact.

Anders: communities = beginners, professionals, artists/educators. A layered Arduino application. Some people will never get beyond an intermediate level. When you're a designer, you might never want to.

Daniel: But you do need to go to engineering at some point. Prototyping and sketching come before communication with an expert engineer for manufacturing.

Mike: If you take a basic class, is it really true that you can just immediately have the conversation with the engineer? In Mike's experience, you have to have a longer conversation in order to understand how the engineer is thinking about the problem and sees the world.

Daniel: It's the difference between describing something in words and having a working rough prototype to demonstrate your idea.

Tom: Graceful negotiation of disciplines! Learning just enough of the other field. Agenda point for next year: acting was one of the most valuable classes he took while doing computer science. Just as we've been talking about simplifying tech for designers, let's how to figure out how to teach aesthetics as it's taught in design schools.

Liz: learning a question of skill and empathy.

Ylva: uncomfortable with essentializing identity. there are artists who are engineers, and engineers who are also artists. seems a little over-simplified to put people just in one place.

Shigeru: Example of workshop. Technical negotiations - explaining to engineers with the right language and definitions.

Trained in computer science and moving into interdisciplinary work. It sucks. Most of the time it doesn't work. Top-down interdisciplinary collaboration never works. Bottom-up -- ie, knocking on someone's door casually -- that works. As a difference point of view, it's rewarding and important to be really, really good at something. If you only work on interdisciplinary skills, you miss getting to the point when you're really good at something. Scott Kim on interdisciplinary collaboration in Art of Human Interface Design (1990, ed Brenda Laurel). The old argument about looking good vs efficiency. You might not be able to learn about think or speak like another discipline, but you can achieve respect for their values. The design patterns approach is worthwhile because they make you explicitly communicate your values. Finding a way to make the values we are instantiating in hardware more explicit by documenting them. Shared repository?

Phil: The disagreements often come from that. We are in the same community but expressing different values.

Ben C.: A functional division that is really important is the division between informal and formal information. We celebrate informal engineering. But we are running into the ceiling between formal and informal. For example, architects spend a lot of time on lateral exploration. But architects then deliver a package to the structural engineering company. We have the lateral explosion of idea, but what about the "print to world" moment in a mass produced object. The "why" in the context of Scratch, or the hyperlinked documentation. All those contextualizations are important. Whether it's documentation or transmitting information on to the next person -- we don't really have a pipeline. And if you want to pass something on to someone else, you need a way.