deeplocal: Design and Development for Humans and Machines

Twitter succinctly captures thoughts, ideas, emotions, or just daily drivel, but words can be so dry sometimes. Building on the previous LED activation project, we simply translate these tweets to a physical representation of light.

By configuring what Tweeter this project is looking at, this will examine recent tweets, and based on what they say, output color relating to emotion. For example, if there is a tweet of “I’m so sad because my puppy ran away”, the led glows a bright blue. Then, when “HAPPY because Fluffy came back!” happens to pop up, a happy yellow emanates.

Comments

Just a quick update on our post-digital development. Here’s a variation on an LED activation, controlled through Twitter:

So if you’d like to control an LED on my desk, just tweet @dltest, “LED ON” or “LED OFF”. More exciting things to come soon.

-Eamae

Comments

Sometimes understanding and developing technology involves years of research, testing, documenting and publishing. Other times, though, it’s just a couple hours of messing around and posting a video online. When applicable, we really like the latter approach.

Here’s one such project. We do a lot of work in mobile, and we also have a decent amount of experience working with electronics. Yesterday afternoon I put together a quick proof of concept combining the two. Here’s controlling an LED from a text message:

The SMS is handled by our Gumband API. We then have a small PHP script on a server that returns new text message data from Gumband. A small program running locally on a laptop pulls that data and parses it for defined commands—in this case “on” or “off”—and then translates those into events which it sends to an Arduino microcontroller. The Arduino can then activate hardware circuits like turning on a light, or any manner of other physical changes.

Comments

Deeplocal is going to open up our doors a bit to the outside world. Our clients like to work with us because we are constantly trying new things and learning how to creatively combine technologies to create new experiences. In our research blog, we will share with you a little of what we are working on and playing with (that is not under NDA of course). Have fun and watch us play.

Comments

As a designer, people are sometimes surprised to learn that I write code. A good friend of mine is a talented furniture designer, and I doubt anyone is surprised that he understands joinery and actually makes things. It makes sense: to design a good chair, he has to know how chairs work. To me, we’re both doing the same fundamental thing, developing fluency with our materials.

So why is it that so many interaction designers don’t program? (I’m not going to delve into a dissertation about what interaction design is; in this case, I’m referring to designers who work with people and digital machines.) In my experience, interaction designers tend to be among the humbler, or at least nerdier, subsets of creative professionals, so I don’t think it’s that we feel designing software mechanics is beneath us.

I think the challenge is that, until relatively recently, the barrier to entry into writing software was dauntingly high. I remember my sophomore year of college, after finishing a semester and a half of introductory programming classes. I had learned all about variable types, data structures and principles of object-oriented programming, but I still had no idea how to actually program anything I could actually see. Disheartened, I dropped programming and went back to my diagrams and screenshots.

Then something happened. I took a programming class for artists and designers, taught with Processing, an open-source Java library and IDE for visually-oriented programming. Suddenly I wasn’t implementing arraylists and sorting strings, I was editing pixels and animating shapes. Suddenly I wan’t limited to conveying interaction through indirect descriptions, I could specify interaction explicitly, through code. Approaching programming as hacker, rather than as a computer scientist, lowered the barrier to entry because I was focused on the end-experience rather than the computational theory.

Hacking has it’s limitations. As I learned more about software, Processing and I eventually had a falling out. As many developers have criticized, larger programming projects just became too unwieldy to manage inside Processing. It’s like trying to write a novel on post-its. So switched to writing programs in “real” java, and then C-based languages, along with some web development (less hacking) and microcontroller programming (lots of hacking) somewhere in between.

Recently, Dave and I were working on an iPhone project, and hit a couple nasty bugs. The app was compiling and running error-free, but things were just not happing the way they ought to be. So I paid a visit to my old friend. By making quick proof-of-concept sketches in Processing, we could quickly isolate, test, and solve problems, and port the code back into our main project in Xcode. As Nathan would put it, it allowed us to let poor solutions fail quickly, so we could develop better ways to solve the problem.

Processing works best as a prototyping tool. It’s allows programmers to put aside lower-level optimization and strict object-oriented principles and quickly hack together some code that works. Hacking makes it easier to approach code as a beginner, and faster to “sketch” ideas as a more experienced programmer.

For design, understanding basic programming is as important as drawing, diagramming, speaking and Adobe-ing. It’s another means to communicate ideas and, moreover, it’s sometimes the only way to accurately describe digital interactions. For development, I think it’s important to differentiate between prototyping and production. If you’re building a proof of concept that won’t be part of production code anyway, don’t be afraid to hack it.

Comments