My Critique of the RGT Start Up Sound

In this video I listen to the sound as it’s used in real life, talk about what the sound is intended to accomplish, and then give it a sound score. And then I try to improve on it.

RGT is a great, freemium service that’s fun for cycling indoors. It connects to your bike and let’s you cycle through one of several virtual worlds along with other people. If you’ve heard of Zwift, it’s similar.

Learning JavaScript, Day 4

I recently decided to re-learn programming. Because I already know HTML and CSS the web is a fast prototyping environment for me, so JavaScript is the logical language for me to learn. Besides,

  1. JavaScript has stood the test of time and the community has improved it a lot
  2. It’s now on the backend too
  3. There’s a ton of new/cool learning resources
  4. jQuery

At first I tried learning from a traditional book, from CodeAcademy, and by reading online. But I was only spending 30 minutes a day on it, and nothing stuck. It’s like my guitar teacher told me when I was 14: “When you start, you need to practice at least an hour a day to train your brain to think this way, or it’s not going to work.”

Four days ago I bought the excellent Head First JavaScript Programming book and have been making my way through a chapter a day, obediantly doing all the exercises with a pencil in the book and in code on the computer.

It feels great. My brain is so happy to learn something new and useful. After day 2 I was able to bang out a simple prototype of an algorithm that was too painful to do in Excel. I wish I had done this sooner.

2014 is the Year I Learn JavaScript

I’m at the point in my project where I need to prototype some software ideas. Doing it on the web is cheaper, simpler, and faster than prototyping a mobile app. And everything I need to do can be done on the front-end, for now. So I’m probably looking at JavaScript or Ruby on Rails, though there are other options.

I went looking to hire a programmer or a small firm to help me. I even wrote a simple spec to make the task official. But it turns out my task is not complicated enough to engage someone else.[1] And yet it’s beyond my HTML/CSS skills.

When I was young I taught myself BASIC on my Sinclair 1000, optimizing code to fit in 1K of memory. I kept those skills fresh in high school and college and even did a bit of Pascal work in grad school.

But that was a long time ago. Since then I’ve been busy learning about networks, then design, then business, then being a husband and father. Just about every year I would wonder if I should re-learn programming, if only to prototype my interaction design ideas. This often took the form of, “Should this be the year I learn Flash?” The good news is I didn’t spend a lot of time developing deep Flash expertise.

Why is 2014 any different? A few reasons:

  1. There’s increasing discussion about the pros and cons of unicorns
  2. When trying to fill an interaction design position recently I interviewed two actual unicorns. They really exist!
  3. I love to learn, and I feel a little tapped out of new things to learn in UX. Not that I know it all, I certainly don’t, but there’s nothing so new it stimulates my brain like it used to.
  4. Programming is such an exciting field these days. Stuff like Github, node.js, Rails, and non-SQL databases make it possible to make new things in new ways.

So, it’s time to learn JavaScript. More on that choice in my next post.

[1] And all the developers I talk to want to differentiate based on services. I hear from a lot of people that want to brainstorm, to partner on ideas, to think about strategy and process, and to measure ROI. For once I’d love to hear someone say, “All we want to do is write solid code at a reasonable price.” return to text

Are Amazon’s Drones Crazy or Awesome?

Rosenfeld Media asked me my opinion of Amazon’s idea to use drones to deliver packages. Here’s a short excerpt from the interview:

Say what you will about Jeff Bezos, the man knows how to touch off a media storm. Which is precisely what ensued after Bezos told 60 Minutes that Amazon is testing the use of drones to deliver goods. Immediately, everyone was discussing the prospect of ordering a box of tissues from Amazon and having a drone arrive at your doorstep in half an hour. We’ve asked some Rosenfeld Media experts to join the fray on this audacious idea.

It’s a longshot that this will ever happen.  But let’s imagine for a moment that Amazon pulls this off.  A terrible road to go down, or awesome?

Victor Lombardi: The danger is in trying to answer this question using reason rather than experimentation. And that’s because drone package delivery is so new we have no idea if it’s awesome or not. To find out, we need to test it. The reason we fail to get these things right is because we fail to treat them as experiments. We fall in love with ideas, with visionaries, with progress for the sake of progress. And that leads to failure.

Read the the full interview at Rosenfeld Media.

The 60-Second Startup Pitch

I’ve been watching founders of small tech startups pitch their companies in 60 seconds. One thing I learned is that a pitch this length must be committed to memory; there’s little room for forgetting a key detail or losing your train of thought.

The successful pitches hit on these points:

  • Who I/we are
  • What problem we solve
  • How we solve it
  • How we sell it
  • Status of business & funding
  • Our industry experience

Twitter was a slow hunch

Part of my research into concept design is to look at where successful products and services came from. Today, it’s Twitter.

Lately I’m also perusing Stephen Johnson’s thoughts on Where Do Good Ideas Come From. In this context it’s interesting to read here and here about Twitter co-founder Jack Dorsey’s years of experience creating software to dispatch messages, and how this interest goes back to his childhood, so in Johnson’s terminology, the idea for Twitter looks like a slow hunch not a eureka moment, typical of many good ideas in Johnson’s view.

Here’s his sketch from 2000 showing key parts of the user interface:
early sketch of a Twitter user interface

Fast forward to 2006 via Dom Sagolla:

“Rebooting” or reinventing [Odeo, the struggling podcasting startup] started with a daylong brainstorming session where we broke up into teams to talk about our best ideas. I was lucky enough to be in @Jack’s group, where he first described a service that uses SMS to tell small groups what you are doing. We happened to be on top of the slide on the north end of South Park. It was sunny and brisk. We were eating Mexican food. His idea made us stop eating and start talking.

I remember that @Jack’s first use case was city-related: telling people that the club he’s at is happening. “I want to have a dispatch service that connects us on our phones using text.” His idea was to make it so simple that you don’t even think about what you’re doing, you just type something and send it. Typing something on your phone in those days meant you were probably messing with T9 text input, unless you were sporting a relatively rare smartphone. Even so, everyone in our group got the idea instantly and wanted it.

This telling from an Odeo developer helpfully points out that this session was one of several:

When it became clear that Odeo was not going to become a huge success in the podcasting space, there was a period of soul searching and hack days. One of those hack days, Jack, Noah, and Florian (another rails dev at Odeo), created Twitter. The initial version seemed interesting, Noah, Jack, and Florian kept working on it for several months, while the rest of the team stayed focused on Odeo.

This interview with Dorsey shows he really did have the essence of the idea years before, and had to wait for technology to catch up:

We were limited until 2005-2006 when SMS took off in this country and I could finally send a message from Cingular to Verizon. And that just crystallized — well, now’s the time for this idea. And we started working on it.

and again:

At that time, one of my co-workers introduced me to SMS (short message service), which I had never seen before. She used it all the time. Once I saw that, I’m like, ‘Whoa, this is awesome!’ This communication blew my mind, and the way she was using it blew my mind. I thought, What if we simply set status, archive it on the Web, use SMS to do it, and it all happens in real time? We all kind of went into a corner, wrote out a bunch of user scenarios, and started inviting co-workers in. They fell in love with it. We knew we had something.


A prototype was built in two weeks
and Twitter was publicly launched almost four months later.

There’s a few lessons here for anyone creating product or service concepts. One is that slow hunches are slow and take time to evolve. Two, sometimes technology needs to catch up to ideas. Three, nurturing company environments like Odeo help these concepts take shape.

Four, obviously Twitter is a very emergent concept and less goal-oriented than even many startups would attempt; it feels more like a demo you’d see on a Labs page, except it just wouldn’t work on a Labs page. And it’s different than how we usually create concepts that require making money; the New York Times profile states, They freely acknowledged that they had no idea how people would use it or how it would make money. But they thought it had potential…

Why I Think Posture Makes the iPad Different

Of all the images to come out of the iPad announcement, the one struck me the most was less about the device and more about the experience of it:

iPad in Lounging Position

iPad in Lounging Position

Lying back on the sofa — isn’t that a nice way to be?

And sitting or lying on the sofa with a 9.7 inch screen means we’ll typically hold this about 2 feet (.6 meter) away from our eyes, versus 1 foot with an iPhone, which means you can rest it on your lap. While some may buy the dock, putting the iPad on a surface means having to uncomfortably lean over it. I think lounging will be much more common. We can do this with a laptop, but the separation of output (display) and input (keyboard and trackpad) is disjointed in comparison. And the iPad will be a little awkward and heavy to hold aloft like a phone.

Consequently the mood while interacting with an iPad may be more relaxed. The interaction has the potential to be more passive, though not necessarily. We’ll make bigger gestures and pivot at the elbow and shoulder rather than the wrist. We’ll scroll/size less than on a phone, using more eye movement to scan the screen. And while Apple has had to succumb to menus to make more functions available, we have the potential for powerful new forms of direct manipulation.

As a designer I’m tempted to display more, denser visual content at one time that a person can sit back and absorb, and offer control with fewer, grander gestures.

Given the physical similarity, it’s tempting to look at the iPad and call it a big iPhone. But I think the posture we adopt and interaction with the device will make it an experience unlike a phone or a laptop.

Aside: how long until someone designs a lounge chair specifically for optimal iPad use?!

Presentation Hardware: Tiny USB Speakers

I’m learning the hard way that presenting concepts may mean giving them to someone else to show on an unknown laptop across the world somewhere. I can control for many factors by simply making a video of my design concept, with voice over. But that laptop won’t get the audio loud enough, and no one ever has a cable to plug into a projector’s speaker.

We need speakers.

Here’s what I would like in my show-off-my-design-concept speakers:

  1. Tiny, tiny enough to fit in a laptop bag
  2. Powered by USB so there are no extra cables or batteries to worry about
  3. Great looks
  4. Decent sound, at least good for speech

Here’s a few candidates:

Play Literacy

…yes, that term sounds a little dumb, but it’s an idea I think will be important in the future. A deliberate spin on computer literacy, I think play will not only be important to designers to support creativity and innovation, it will be important simply to get along in an electronic world.

In the past I’ve argued that software tools will continue to be created much faster than we can possibly design quality interfaces for them. So consumers who can and are willing to play with a device to figure it out may be more successful.

I had this thought today while driving and navigating with the Google Maps iPhone app (I know, I know). The iPhone is slick, and the app is slick, but for so few functions it ain’t easy to use. But the slickness, the playfulness, of it all helps me overcome this. The desirability of the device and the experience make me want to overcome the usability. As designers, we can build playfulness in to help people, and, cynically, playfulness might be a sexier product development approach to sell than usability.

Update: Only tangentially related is how receive serious political ideas from comedians

In one “astounding half-hour” of television, Stewart viewers saw “more trenchant talk of the financial crisis and the responsibility of the networks than you’d find on any news channel, all the more surprising in that it aired on Comedy Central.”

Not surprising, really, in that comedians like Lenny Bruce did this long ago. It’s just another place where we like to coat our serious work with a bit a humor and fun to make it palatable.

IDEO’s Open Dev of the BugBase Hardware/Software UI


It’s not often we get to peek inside anyone’s concept design process, so this blog from IDEO has me starting up my reverse-engineering machine….

An open project between BugLabs and IDEO, this deep-dive exploration of the BUGbase UI is focused on re-envisioning the BUGbase interface with an eye toward integrating new display and input technologies.

The outcome of these explorations will feel less like a finished product and more like a concept car. And like any successful concept car, we hope these provocations will not only help us gauge users’ interests, but will spur constructive discourse and inform future design, engineering, and business decisions.

BugLabs’ commitment to openness presents a unique and exciting opportunity for us to be as inclusive about the design process as possible. For this quick two week collaboration, we will be conceptualizing new interface paradigms, designing new tangible user interface directions, and creating the associated industrial design/housing-modification solutions.

Webinar with Bill Scott of Netflix, Yahoo + 20% Off

Bill Scott of Netflix, formerly of Yahoo, will be hosting the Future Practice webinar tomorrow, helping web designers learn how to create designs that are easier to implement by illustrating the UI engineer’s point of view. And you, my dear readers, get 20% if you enter the code VTWBNR when signing up.

I recorded a bit of our rehearsal with Bill. He’s killer smart — an O’Reilly author and frequent presenter — but has a great laid back style that’s such a pleasure to learn from. Here’s a ~7 minute edit:

A Quantified Value of the iPod Design

This study — Who Captures Value in a Global Innovation System? The case of Apple’s iPod — is one of the best I’ve heard of in a long time. The researchers traced the parts and assembly of the iPod and attributed the value generated by each step by part and by country. A few key stats: of a $299 video iPod, Apple gets the largest piece of the pie: $80. The other portions are relatively small; China only gets $4 for assembly.

Hal Varian of the New York Times made this key observation about how Apple’s capabilities generate their benefits:

The real value of the iPod doesn’t lie in its parts or even in putting those parts together. The bulk of the iPod’s value is in the conception and design of the iPod. That is why Apple gets $80 for each of these video iPods it sells, which is by far the largest piece of value added in the entire supply chain.

Those clever folks at Apple figured out how to combine 451 mostly generic parts into a valuable product. They may not make the iPod, but they created it. In the end, that’s what really matters.

I’m encouraged by studies that highlight the value of concept design given my work in this area. Here’s a question for you: how would you most like to learn more about concept design: a book? videos? something else?

When Engineering Defines the Limits of Design

I’ll get the plug part of this post out of the way right here: I worked on a preview of Bill Scott’s upcoming webinar on What Every Designer Should Know about Interface Engineering and I think it’s both very good and very important, and what’s more it’s a topic that I’ve never seen addressed outside project work.

I was reminded of this in a meeting the other day. We’re working through a Flex application that asynchronously queries the server with each criteria specified on a form, a little like what Kayak does, but with more data coming back from the server. Unfortunately the latency in that data transfer is simply too high, with too much customer time spent watching the spinning cursor. It’s unfortunate, because the design of the form itself (not mine) is clever, and I found myself thinking, “This is how Google would do it.” But the infrastructure in question is not as robust as Google’s infrastructure, and so the design needs to be modified to fit the latency of the system.

And this is the kind of situation that Bill refers to. When designers understand the limits and degree of difficulty in the technology needed to implement their designs, the designs are better.