It is hard to do things that are hard, but it seems to usually be worth it. Historically, I prefer running away towards the easier things, but I’m working on changing my habits. It feels a bit unnatural, but I’m trying to be honest about the struggle.

The hardest part of making something new and exciting is usually coming up with the idea.

Today, after months of dancing around the problem of not having an idea I was happy with for the distance interaction machine, I had a great conversation with two generous designers. In less than an hour things finally really gelled! But before I get into that, let’s take an honest look at:

The pathology of the situation

The first entry in this blog makes it clear that I didn’t only want to use it as a platform to share my neverending train of fabulous successes. Why? Because I don’t have one of those to share; like most creative builders-of-things, I’ve got some successes blossoming right next to a bunch of mushed up failures of smelly potatoes.

pretty flower Bird’s-foot Trefoil by Judy Gallagher via Wikimedia Commons

If I only show you pictures of gorgeous victories, I’m giving you a fictitious and demoralizing view of my creative experiences. Not only demoralizing for me—demoralizing for you too! It elides the actually hard part of doing things, and by mentally substituting in shiny finished projects for hours spent working in the salt mine after the lights went out, I’m leaving out the longest and most meaningful part of the story.

ugly potato potato blight, or “this sort of thing happens all the time” from Wikimedia Commons

Careful readers will have noticed that I’ve been posting exhuberantly about the Bus Stop Machine project, showing my incremental progress from idea to prototype. Next up should be some pictures of my cutting some parts out on a CNC router. It’ll look great—you’ll see some expensive and complicated machine doing my bidding. What won’t you see? The hours of frustration leading up to it. I’m going to explain some of the frustration below. But that’s still not the root of the problem I want to share here.

The root of the problem

I once heard a really interesting bit of trivia about professional and amateur musicians’ practice habits. The amateurs practice the stuff they’re good at—playing that favorite song again and again, nailing it and enjoying the sense of achievement. The pros, on the other hand, practice what they’re bad at. That is, of course, how they stop being bad at it! And by pushing against their limitations, instead of comfortably playing within them, they expand their expressive and technical realm. So we should all just keep working real hard at the stuff we’re bad at. Great!

Well, not so much. It’s quite frustrating to always be attempting things that are challenging. It’s…challenging. Nobody wants to eat broccoli all the time. We want some ice cream, maybe even before dinner.

It’s easier, and more fun in the short term, for me to spend time working on those types of problems that I can wrap my head around and comfortably approach. I’ll work at them, then come to a successful conclusion. I’ll feel smart, like I’m applying complex solutions to complex problems in a way that reinforces a comfortably positive self-image. Ice cream is delicious!

It’s harder, and more valuable in the long term, for me to focus on the things I don’t know how to do (but want to know how to do). What does that look like? More frequently than not, it looks like approximately eight minutes of attempting to figure something in software out over and over, followed by reading three or four Stack Overflow pages, or some stray forum entries from the middle of the aughts, while saying out loud to the unsympathetic computer screen, “why didn’t somebody just post a simple example? Is everybody crazy?!” Steamed broccoli needs at least some salt and lemon juice.

Dealing with the annoying thing head-on for long enough will vanquish most technical problems

About a month ago, I decided I was fed up with not being able to use git and GitHub. I had tried before and failed before. Like I think two or three times. And that was with help from friends or teachers who knew what they were doing! I had a project I wanted to properly do version control of, rather than just resaving all the time with different dates baked into the filenames.

I pulled up three different git guides side by side, all of which were flawed and occasonally seemed to contradict each other. I tried for more than an hour just to get a single git upload (“push” in gitland) to work. This is a process which should take maybe a solid 5 minutes. After going a bit crazy, it finally worked, sort of. Now I finally know how to basically do what I want in git and it’s actually been a boon to my work recently, since I’m more eager to share revisions of things I’ve been working on and have an easy way to do so.1

The story is fairly boring: thing was hard, tried for a while, got really frustrated, eventually figured thing out. But this fairly boring story is, in my experience, exactly the story of everything meaningful I do.

How this relates to my relative silence on the long-distance interaction machine

I haven’t done much posting at all about the substance of the long-distance interaction machine that forms part of my thesis. (The last time you heard from me about it was this field trip two months ago.) It’s not because I haven’t been working on it; it’s because the work has been extremely slow, very frustrating, and consistently really tempting to set aside and not deal with. When there are other more captivating tangible problems on my plate, like making little bits of plastic rotate on an axis through magnetic pushes, who wants to deal with server-side Python difficulties? Not me.

With the kind and patient help of David Newbury, I have made some real technical progress and have a skeleton of the system to get my two remote computers to reliably communicate with each other (through a third server, hence the complexity).

But the bigger problem was I kept not focusing on the actual substance of the interaction I want the two remote users to have with each other! This problem was confusing and complex, creative rather than technical, and all too easy to put off because (as I told myself) I was dealing with solving the underlying computer problem first.

That’s a mistake. Instead of failing early and often, as is so deservedly the mantra of this sort of design work, I allowed myself to become obsessed with solving the problems that felt easier and more obvious, like the mechanical bus stop matters. In so doing, I have pushed my failures later and later (and consequently they will be weightier and weightier once I actually get around to failing at them).

Failure in point

Just because it’s the most recent progress-blocking failure that comes to mind, here’s an illustration of a problem I’ve recently had: I’m no Rhino (3D design software) pro, and consequently I can spend something like an hour and a half figuring out how to make drawings but apparently not extruding them into volumes properly. I’m working on a digital rendering of the Bus Stop Machine knob control housings so that I can CNC route them.

Rhino mistakes galore

Why might Rhino not want the big flat surface of this to be extruded, and instead only the walls? Who knows. I’ll figure it out. For the time being, I haven’t, despite looking at the developer’s help pages and poking around online a bit. This is a very typical sort of problem for me: industrial-grade software with loads of quirks and complexity, and since my dilettantish contact with it likely won’t go much deeper than “get it to do what I want then move on,” it’s always a matter of finding out only those parts of the whole that are necessary for my goals.

There is good news down here

As I mentioned at the top of this post, I had a wonderfully useful conversation earlier today with two great designers, Hannah du Plessis and Marc Rettig, who are coteaching a fascinating class in the Design department this semester, Principles, Approaches, and Methods for Social Innovation. As might be obvious from the name of the course, their practice is quite close to my central research interests. When I asked if I could get their advice on the design problem I’d been having, I was hoping maybe some useful pointers would come out of a conversation, but I fared much better than that.

I explained to Hannah and Marc the challenge of figuring out the nature of the hardware store machine interaction:

  • I want the engagement to be mechanical/tangible in nature, ideally with the user manipulating actual hardware;
  • I want to connect remote participants without a screen-based interaction being primary to the experience;
  • I need to deal with the likelihood of people at either end of the experience not having a participation partner at the far end when they walk up to the machine (I call this the asynchronous problem);
  • I want there to be a sense of meaningful completion/solution to a puzzle, challenge, or game;
  • and of course the entire impetus of the thing is to give the user at each end a sense of camaraderie, or at least decreased social distance from the person at the other end of the line.

It’s a tall order. In addition to suggesting I try to focus on only a few of these goals instead of all at once (this is excellent advice I’m at least for the moment going to politely ignore), they had some great recommendations for me:

  • Focus on shared play, not merely problem-solving. Most people like to play and they will have this in common with the remote partner.
  • Build a system that’s two ends of the same world, meaning: a physical thing with a ramp leading into a wall, and if I drop a ball on the ramp at my end, it will kick a ball out at the other end from that door. A sort of wormhole!
  • Have a big visible countdown timer running—so the passer by will see that their chance to do/learn/play something is just about to expire and will be more motivated to get over and check it out right then.
  • Employ a sequence of very fast challenges, like:
    • build this shape using any parts you have, in 30 seconds, or
    • build the highest possible structure, in 10 seconds, or
    • make something to shoot a ball as far as you can, in one minute, etc.
  • The experience needs to be fundamentally attractive to people so they’ll be drawn in.
  • Instead of worrying about a technically complete system at first, I should be prototyping these different designs by just sitting two people at opposite ends of a table, for instance, giving them mockups of many possible interface designs or Wizard of Ozzing it as is helpful.

The idea!

Now that you’ve heard everything I have to say about everything, I’m happy to share my new idea with you. It came about during the meeting this afternoon and while I haven’t even drawn a single concept sketch yet, I have been thinking about different possible modes of implementation.

It’s some sort of Rube Goldberg or Mouse Trap kind of setup, with a variety of hardware pieces being all the various bits that make up the funny kinematic chain. The users at either end both make a sequence of things that trigger the next, and at some point, their local goal is trigger a remote change at the other site. To extend that idea further, the control flow may be that at one site the user builds a chain that ends up hitting a specific sensor—that then fires a remote solenoid so the other person’s chain begins, and that one ends up hitting a sensor that shoots a ball back onto a ramp at the starting person’s space.

I think this idea, if executed well, could give both users the chance to build something interesting, creative, fun, purpose-driven, and ultimately cooperative. Designing the particulars, as well as scaffolding the interaction, will be no easy task, and the clock is ticking. But I’m feeling relieved that after a shameful amount of treading water and waiting for inspiration to strike, this feels like a reasonably promising idea. I’ll hope to have a tabletop prototype in about a week!





  1. For instance, I recently updated my OpenSCAD script for generating ball chain gears, and for good measure wrote a new one to generate NEMA motor mounting plates.