Adaptive Path Blog

Light Sensor Triggers LEDs

Originally uploaded by odannyboy

While working my way through the Making Things Talk book, I hit a wall when it started to get into electronics. I had to stop and read Physical Computing and go through some basic Arduino tutorials just so I could understand what in the heck was going on. I had no idea what a basic circuit was, or how a switch worked, and especially not how to read an electronics schematic. A bunch of reading and some experimenting later, I have a much better handle on that stuff. Enough to be dangerous, probably, but at least enough to continue.

The next thing I wanted to do was hook up a sensor to the Arduino board and just see what it did. I had a light sensor laying around, so I plugged that in and found a simple piece of code that basically just reads and reports the data coming in from the sensor. I put that into the Arduino programming environment and ran it.

What I got back was a simple, rapid string of numbers ranging from 520 (when the sensor was covered by my hand and thus in the dark) to 600 (when the sensor was in the full light). What these numbers mean, I have no idea, nor does it really matter very much, I suppose. At least not for playing around.

I wanted to then have the sensor do something other than tell me the data, so I added a little bit of code (from an earlier program I’d done based on a tutorial), that made two LED lights light up based on the sensor reading. Red for dim light, blue for bright light. Any number below 530 made the red LED turn on, anything about 560 makes the blue light turn on. And, voila, I had a sensor that controlled some lights. Definitely not brain surgery, but fun, and it is, I think, as simple as it is, a great step towards a bigger world for me.

Next up: a more complicated response to sensor data…

Arduino Light Box

Originally uploaded by odannyboy

Considering that at the start of the week, I knew next to nothing about electronics, I’m pretty pleased with how the week ended up.

After getting stuck on the basic electronics at the end of Chapter 1 of Making Things Talk, I worked my way though most of some Arduino tutorials while reading up on electronics in Physical Computing. I feel like I can at least navigate my way around a breadboard now and make some simple stuff. There is obviously still a ton to learn, but I feel like I’m moving forward in a positive way–especially since several days ago I despaired about ever picking this up.

Next up is adding some sensors and switches. Now that I can make art (of a crude sort), I want to make something more interactive. Stay tuned.

Over the last several years, Adaptive Path’s business has expanded from mostly web work to a mix of web, mobile, medical devices, and consumer electronics. As our business has changed, our skills have needed to change along with it. Part of that change is gaining a comfort, understanding, and hands-on knowledge of subjects that didn’t used to be part of our vocabulary: electronics, programming, and industrial design, just to name a few.

Adaptive Path’s Interaction Design Lab
Originally uploaded by odannyboy

So as part of expanding our skills, I went and set up the beginning of an interaction design lab so that our designers had a place to work and tools to play with. I bought some basic tools like a soldering gun, some screwdrivers, wire cutters, etc. I also bought an Arduino Starter Pack and a bunch of sensors, some buttons, resistors. Other contributions made their way to the lab: our One Laptop Per Child XO machine, an old Chumby, and a touchscreen kit from Synaptics. It’s not much, but it is a start.

The most important contributions were from books though. I donated my copy of Brendan Dawes’ Analog In, Digital Out and purchased the two definitive books: Physical Computing and Making Things Talk.

Then I started playing.

I started working my way through Chapter 1 of Making Things Talk: downloading the software necessary to tinker with with the Arduino microprocessor. Since I learned Processing in grad school (under the patient tutelage of Golan Levin), the programming part wasn’t hard to pick up. I was able to pretty quickly make an LED light up and blink. (”If it lights up, it’s art. If it blinks, it’s interaction design.”)

But then I hit a roadblock. Near the end of Chapter 1 of Making Things Talk, which up until then had done a great job of handholding through the initial code and set up, suddenly stopped the handholding when it came to electronics and working with the physical components. So I had to put that book down and pick up Physical Computing to brush up on that, as well as start working my way through some online tutorials like the set of Arduino Tutorials.

I’ll let you know how it goes.

About a year and a half ago, when I first started thinking about the material that would eventually become UX Intensive: Interaction Design, I wondered what it was that helped designers make those leaps of faith, the great guesses, that we have to make on projects. So I came up with this talk, How to Make Good Design Decisions.

| View | Upload your own

UX Intensive Interaction Design no longer contains this material, but it is still interesting nonetheless. I hope you enjoy it.

I was having a conversation yesterday and mentioned that I occasionally designed mobile phones. The woman I was talking to then proceeded to tell me about the big problem with her phone, that sometimes when she talked, her face hit the buttons and caused the phone to start dialing or beeping and generally disrupting the call. I started to say, “Well, that’s really an industrial design problem…” but caught myself. Maybe it was unavoidable from an ID standpoint. Perhaps they didn’t have the manufacturing budget for better buttons, for instance. Maybe there was something that could be done from the interaction design side, like, say, making it difficult for the pressed keys to do much while a call is in progress.

Each discipline can only go so far with the constraints they work under, and we have to watch each other’s backs and cover for the flaws of each other. Users don’t care whose fault it is that a product works poorly, only that it works poorly. All the disciplines need work together to figure out solutions to product flaws, with visual, interaction, and industrial design blending their strengths together. The visual design should make the interaction design look good, which in turn makes the industrial design look good, which makes the visual design look good. (Mix up the order as you will.) Focusing on the connective tissue between disciplines makes products holistic.

This is the essence of experience design.

It’s hard to believe that iTunes Music Store just turned five years old yesterday, that there was a time (for two years!) that the iPod (iTunes’ better-looking older sibling, the Marcia to its Jan) relied on either users slowly converting all their analog CDs to digital, or simply stealing music online.

While iPod gets all the press and adoration, it seems clear that iTunes, for all its faults, is the little app that could. iTunes is the secret sauce of the iPod experience, and the music store is, if not at the center, than at least an incredible piece of that. Imagine trying to put a major ecommerce store in the middle of another application (Word, Photoshop, etc.) and it becomes clear marvel that is iTunes Music Store.

Of course, the store itself is the tip of the iceberg when it comes to that marvel. Were it not for the amazing technical and business infrastructure backstage (which remains (as it should) mostly invisible), we’d be downloading donated MP3s. Slowly. And forget about movies, TV, podcasts, etc. The store has expanded so that the “music” in iTunes Music Store seems almost silly. iTunes Media Store is more like it. But I quibble.

Happy fifth birthday! You don’t look a day over four. Now could you please go get Twin Peaks for me?

It’s easy to forget when hearing someone give a presentation that the talk is a product too. And like products, the designer doesn’t always know what’s going to happen when the talk meets the users (the audience). Sometimes it works, sometimes it doesn’t. And like a product, good designers go back and revise the beta. Put out a better version.

This is a long preamble to saying that Kim Lenox and me have taught the interaction design day at UX Intensive four times now: in Chicago, Amsterdam, Vancouver, and San Francisco and each time was different. We’ve spent the last year tweaking the content until we (and the audience) were happy with it. As it turns out, it’s tricky to teach interaction design in a day. We went from a nearly all-lecture day to one that is mostly a hands-on, activity-centered workshop that tries to create a studio environment. It even requires having a first-aid kit on hand! I’m really happy how the day has evolved.

If you are interested in learning (or brushing up on your existing) IxD skillz, we hope you’ll join us at UX Intensive Minneapolis in June. Use the discount code BLOG and get 10% off admission!

I found myself at a design conference listening to still another demand that clients give us designers that coveted place at that legendary table where all the big decisions are made. Sitting next to me was one of my favorite clients, someone I treasure for her levelheadedness and good humor. “I’ve spent hours at that table,” she whispered to me. “It’s not that great, you know.”
Michael Bierut, You’re So Intelligent

Adaptive Path’s MX Conference is about to kick off. Design managers and executives are descending up San Francisco to learn and talk about how to make their designs more effective, to speak to management better, how to innovate their organizations. Part of these discussions I’m sure will be the perennial talk of How to Get a Place at The Table. I’m here to offer an alternate view: our place as designers isn’t at The Table. It’s to smash The Table.

Perhaps the natural state of design—and thus designers—is to be outside the circle of power, and thus better able to tell the truth to power. At The Table, it is easy to have other concerns instead of just creating the best products possible: political concerns of gaining and retaining power, or financial concerns of running the company, or resource concerns about personnel, or the million other details it takes to run a business–many of which fight against putting out great products. Yes, a seat at the table can guarantee that a product gets made, but it doesn’t guarantee it will be good. Witness: Foleo, which Jeff Hawkins was able to push through but was so roundly criticized, it was pulled before it was even sold.

And of course, yes, we want and deserve respect (we’re changing the world, dontchaknow??), but that respect should flow from the products we create, not the number of meetings we’re in with the CEO.

Designers work better outside, looking in, the wise fools at court. The view outside is clearer, more open to other influences, less susceptible to groupthink and myopic viewpoints. (This outside viewpoint is why so many companies hire consultants.) Being outside allows designers to be advocates: lobbyists for what is the right thing to do for the users, the integrity of product itself, and even in some cases for what is best for the business.

This idea of Designer as Outsider is nothing new. In the 1950s, industrial designer Henry Dreyfuss had brown suits made so that he would stand out from his corporate clients in their blue and grey suits.

As Dreyfuss knew, sometimes it benefits us to be more like artists than scientists. Design is, after all, a combination of science and art, and it is often art’s job to shine a light on what is uncomfortable or hard to do: the strange and unusual. The Truth with a capital T (which also means Trouble). We just need to draw on that legacy more often. Telling a CEO her vision of the product is the wrong one is not easy. It requires two things: courage and allies.

Rather than expend energy to get to The Table, it’s better to have allies there. People who know how to read the room, who can seem impartial but also lobby for you and help you make your case. The best clients, Tibor Kalman rightly said, are smarter than you. We need to cultivate these allies through the strength of our work and our ability to explain our work in terms of the value it brings to the users and to business. Only then will our voices be heard and respect given. We don’t need a seat at The Table for that. We just need allies there.

And here’s the most subversive thing: if we do our jobs right, The Table will change. It will get bigger, move, transform, and, yes, even get smashed. The best products change companies, markets, and, yes, possibly even the world. And when that happens, attention will be paid, respect given. You will be thanked for smashing The Table and giving them a new one.

And then you will go and do it again.

With the “topless” (as in laptopless) meeting idea getting so much coverage, I thought I would put up the “rules” I came up with back in 2006 when I jokingly coined the term. (Note that this banning of laptops can and should spread to other attention-sucking devices. I’m looking at you, Blackberry. You too, iPhone.)

The guidelines:

• Topless meetings must be announced when the meeting is scheduled, not directly before or during so that people can plan to be topless.

• The meeting shouldn’t be more than an hour long, unless there are scheduled breaks for email/IM/etc.
• The meeting should never be more than 4 hours long in any case.
• The “topless” designation should be used mainly for brainstorms/design reviews/essential discussions.
• If you can’t be topless, you shouldn’t be in the meeting. Join when you can be topless.
• One exception made for a single note-taker/documenter of the meeting.
• Could be used for internal and client meetings

I’m as guilty as anyone of getting sucked into an email during meetings, and the divided attention (and the lowered discussion) really lowers the energy and productivity of any meeting.

And if you are one of those people who think all meetings are a waste of time, I say: nonsense. Meetings are not just about communication, though they are often treated as one-to-many information distribution sessions. Meetings are a waste of time when they are used to talk about work that’s already been done or work that is yet to be done. They are valuable so long as everyone is there to contribute and pay attention. People dread meetings because they are often not focused and drag on for longer than necessary–which is what happens when people don’t contribute or pay attention.

Meetings enhance productivity when people use them to do the kind of work that is best done in collaboration with others. Good meetings are about getting somewhere: a decision, a new idea, etc. Working through ideas often means making those ideas tangible through sketches on whiteboards, quickly showing examples, etc. That needs face-to-face time and focused discussion. It needs topless meetings.

Kudos to Jesse, Andy, and Todd for eloquently stating why meetings still matter. I ruthlessly stole and mashed up their thoughts for this post.

If you’ve ever used a bot like SmarterChild, pause and pay a moment of respect to the late Joseph Weizenbaum who died March 5, the news of which is only now making the rounds. Weizenbaum was the creator (in 1966) of ELIZA (play with the web simulation), the first software program whose purpose was to make the computer seem like a human being, with human-like responses. ELIZA was (and remains) ridiculously seminal in HCI circles, and its influence can be seen in everything from IM to text-based adventure games to Clippy.

Weizenbaum had some wrong-headed, disparaging things to say about the internet (”a garbage dump”), but his caution about the possible evils of computers sounds like he was warning us about SkyNet long before anyone else was. He had a great concern with the ethics of technology and strongly advocated that computers never replace human decision-making.

Another one of the old guard is gone, and we are all lessened for it.