Anders Ramsay.com » Industrial Design

Scarily Real Robot (Yes, it really is a robot)

Anders — Thu, 27 Mar 2008 16:58:54 +0000

Just came across this at Machine Thinking:

At first, I thought this was two guys in something akin to one of those two-person horse costumes, but then as the video kept playing, I eventually had to accept that this in fact is a machine. Be sure to continue watching until a guy kicks the robot really hard in the side – the way that it regains it’s balance is incredible. Then, when they show it trudging through deep snow, it just appears to be struggling so much, I almost started feeling bad for the thing – won’t be too long now before somebody starts PETR – People for the Ethical Treatment of Robots :)

Toilet Usability – 6 Reasons Why the new NYC Public Toilets are Doomed

Anders — Fri, 11 Jan 2008 19:58:44 +0000

With great fanfare, New York City Deputy Mayor Dan Doctoroff (who will almost certainly never use this toilet himself) today announced the installation of new public toilets throughout the city (toilets he will almost certainly not be using himself.) The idea of public restrooms in the city is of course highly welcomed, though it’s a bit embarrassing that this is being announced in 2008 and not, say, 1908. But no matter, when reading the description of the new toilets, there are just so many IMO terrible design choices that were made that I have to wonder if any kind of prototyping/usability testing was completed. I just can’t imagine these toilets being a success and these are some reasons why:

1 – They look like prison toilets

There is a very strong association between a stainless steel toilet attached to the wall with no seat and what you might find in a prison cell. In fact, when I first saw a picture of the toilet, I thought that it was a picture of exactly that. The idea of a prison toilet, of course, has strongly negative connotations, somehow making the statement that “citizens of New York are so uncivilized and prone to destruction of property that we have to take the same approach to designing a toilet for them as we would for prison inmates.” Sad indeed.

2 – I would never sit on a public steel toilet without a seat (even if it supposedly had been cleaned)

The reason for this is not only about logic, but also that I would just find it weird. And wouldn’t the toilet also get very hot in the summertime and very cold in the wintertime? Why couldn’t they at least have a plastic top on the toilet that can’t be lifted?

3 – The door to the toilet remains open for 20 to 30 seconds after entering

Like the NYT article says, this will

possibly be the longest and most awkward 20 to 30 seconds of a person’s day. The door slips open like an elevator, but then it stays open, to accommodate those who need extra time getting in. Meanwhile, men and women in suits walk past. It is very difficult to look inconspicuous in a bathroom on a sidewalk in New York with the door open. There is just nothing to do but stand there. And the delay will not please those who are in distress.

So here I am, really needing to go. With most every other toilet I’ve ever encountered, I can close the door behind me as soon as I enter. But here I am supposed to just stand there looking stupid with people walking by? The fact that certain disabled individuals may need more time is all good and well, but they should have the option of preventing the door from closing immediately rather than keep the door open for an extended period for everyone. This is a case of broad-sword design, in which all users of a product are made to suffer to accommodate an edge case.

4 – The door to the toilet opens automatically after 15 minutes

Interestingly, this second ‘feature’ is in complete contradiction to the door being kept open on entry. What if I am a disabled person who needs more time? I would be publicly humiliated. And, frankly, even if I technically would be able to finish my business in that amount of time, I just don’t like the idea of this time limit hanging over me. And this isn’t just about disabled people. What about older people who need more time? Or parents with their kids? Very very bad, IMO.

5 – The toilets are only open from 8am to 8pm

If these toilets supposedly are completely automated, why in the world can they not be available 24/7? After all, the time when I think a lot of people would want to use something like this is when everything else is closed, i.e. not between 8am and 8pm.

6 – The toilet will use 14 gallons of water per use

This is according the NYT City Room Blog. Keeping in mind that the EPA’s recommendation of water use for a single flush is around 1.5 gallons, this is absolutely egregious. To be clear, the 14 gallons are used to hose down the toilet between each person who has used it. This kind of water waste is IMO simply environmentally unethical, and reason enough for me to avoid it.

Emergencies and Design

Anders — Thu, 22 Dec 2005 17:35:30 +0000

Sitting here stranded in my apartment during the NYC Transit strike has got me thinking about the relationship between design and emergencies (ok, compared to real emergencies like Katrina and the Atche Tsunami, this strike is more a major headache, though for some, such as those who are losing money or access to healthcare, it is a true hardship.)

Emergencies are, in most cases, sudden and unexpected; design work is traditionally carefully planned and relatively time-consuming. At the same time, it is often exactly in times of emergency when the need for good design is the greatest. But because there are so many unknowns in an emergency situation (since they inherently are rare and unpredictable), the design challenges can be staggering. Of course, people design for emergencies all the time, such as the strike contingency plan currently in place by the city (which, by the way, appears to be working tolerably well.)

But what about all those needs which only are discovered after the emergency has occurred? I remember, during the blackout of 2004, returning to my apartment building, planning on simply taking the ten flights of stairs up to my apartment. But since I had never experienced a blackout while living in that building, I had completely disregarded the fact that there are no windows in the stairwells, and also consequently realizing why modern build have windows in their stairwells. And since there also was no emergency lighting in our stairwells (clearly, no planning for an emergency here), they would be pitch black.

After taking one look into the completely opaque stairwell, I realized trying to scale ten floors could be treacherous (also considering that, while NYC has gotten a lot safer of late, it’s still a city where you need to watch your back.) I don’t remember exactly what gave me the idea, but I somehow realized that my cell phone could double as a flashlight. When it’s pitch black, even such a weak light source turned out to be sufficient to illuminate my way up to my apartment.

And so it goes with emergency, or ad hoc, design–you have very limited resources, usually little or no time (in my case, I happened to have that one luxury, sitting on a bench outside my building, pondering my situations), and are basically iterating on the fly, and you have to effctively take an out-of-the-box perspective on the resources you have. (Reminds me of how Tom Hank’s character in Cast Awayused the blades from a pair of skates as a cutting tool.)

But ironically, I think it is exactly those constraints that have the potential to allow for truly innovative solutions (what’s that saying about how times of need sharpen the senses?), to be forced to solve the problem now with whatever paltry resources you have immediately available to you.

I wonder how taking such an approach, as in simulating an emergency soituation in a design exercise, would affect the overall quality of the design. Maybe it’s not possible to artificially create a sense of emergency in an everyday design context (other than imposing completely unrealistic deadlines or have super-short design/prototype iteration cycles), but assuming it was, would the design team, effectively use the limitation as a tool, produce something they may not have been able to produce had they followed a more traditional model? Too often, the luxury of time (and wide-ranging design choices), are more a hinderance than a help. I guess it’s a bit ironic, then, that the one thing I do have due to this strike is a bunch of extra time to ponder questions like this.

Feature dependency and context of use

Anders — Sat, 06 Aug 2005 17:54:59 +0000

Imagine buying a new (and expensive) car and discovering that the car will only run if the air conditioning is turned on. You take the car back to the dealer and ask them to fix the problem. But to your surprise, the dealer informs you that that this is how the car has been designed. This seemingly surreal analogy is not too far off the mark from my experience purchasing (and later returning) the Bose Quiet Comfort 2 Headphones.

I received the headphones and was immediately impressed by their compact and light design. I plugged them into my notebook and fired up iTunes. Unfortunately, all I got was silence. No music. I called customer support to report the problem and was informed, to my surprise and great dismay, that the only way to be able to hear music is if the noise canceling is turned on.

So why is this a problem? Well, first of all, the noise canceling requires a battery, meaning that if the battery that goes into the headphones is dead, I will not be able to listen to music, even though hearing that music does not require a power source. Second, the noise canceling is so good that a person can be standing next to you talking fairly loudly and you can’t hear a thing. Worse, it is probably highly unsafe to be walking around in NYC with the noise cancelling on, since you would, for example, have no ability to hear an oncoming car or bus. In fact, and somewhat ironically, the insulation of the headphones is so good that you almost don’t even need to turn on the noise canceling for the headphones to reduce noise.

Why is this bad, from a design perspective? Recalling the car analogy, just as driving is the primary function of a car, listening can generally be seen as the primary function of headphones (not to be confused with the earmuffs you might see people wearing at a noisy construction site, which will become relevant in a moment.) Just as air conditioning is a secondary feature in a car (you can have a car without air-conditioning,, but not vice versa), so noise canceling is a secondary function of headphones.

But wait a minute, you say, isn’t the primary function of these headphones to cancel out noise? Possibly, but that still doesn’t justify any kind of dependency between these features. Listening to music should not require having noise canceling turned on. there is no logical dependency between these features. instead, the dependency has very unfortunately been manufactured into the design. And in reality it’s probably a legacy problem (for those who think that computer systems hold a monopoly on being hampered by bad design due to legacy issues, take heed.) The Bose QC2 are the offspring of industrial grade headsets Bose designed for US Military helicopter pilots, to shut out the extremely loud noise of the chopper engines and allow the pilot to hear what was being said in their headphone intercom units.

Similarly to how the Humvee was sold to civilians in the form of the Hummer, Bose discovered a market for these headsets among business travelers sick of the drone of jet engines on passenger planes, and the Bose QC1 (bulkier than the QC2 and with a separate noise canceling box and power pack) was born. I’m guessing that the original military headsets were drawing power for both the noise canceling and the intercom from the same source, and when the civilian version was designed, this was maybe not even have been considered as something needing to be addressed.

Would the noise-canceling/audio dependency issue not have been uncovered with some simple usability testing with civilian users? Or did Bose decide that all the rigorous testing that inevitably had been required for the headphones to pass muster in the military was sufficient, and that the (supposedly) lesser needs of civilians meant that no further testing was necessary? This, perhaps, is at the core of the issue: civilian use is obviously a completely different context from military use, which means all bets are off as to whether the design intended for the original context will be valid in the new one.

Battling affordances with labeling (or trying to)

Anders — Sun, 03 Jul 2005 18:01:11 +0000

Walked by the Dolce & Gabbana store in SoHo the other day and saw some serious labeling on their door handles.

You have to wonder if at some point the doors did not have these oversized instructions on the handles, and customers were constantly trying to push the big and inviting surfaces only to be rudely informed (probably in the form of a big ‘BOINK!’) that the doors actually swing outward. After all, those big white raised surfaces simply beg to be pushed inward. So, instead of correcting the affordance of the design (e.g. replacing the big push handles with a set of thin vertical handles that communicate the need to pull), somebody decided to instead slap on a label to communicate how to open the door. Sort of like labeling a big beveled button with ‘DON’T CLICK.’ I guess the labeling will likely work ok for attentive people who can read English. But as it happens, more than a few people in NYC do not speak or read the language–especially tourists who of course come to SoHo in droves. They’ll probably wonder what the hell that text is on the door, seconds before finding their face imprinted on the glass…

The iPod remote and communicating function with shape

admin — Wed, 01 Jun 2005 13:41:14 +0000

For all the brilliance of the iPod’s design, I think Apple must’ve outsourced the design of it’s somewhat lesser offspring, the iPod remote. It has a very unfortunate design flaw, unfortunate because the fix would be so frustratingly simple. The problem I’m referring to is the use of identical button shapes for different functions, play/pause vs volume up/down.

When I use the remote (which is the primary way in which I control the iPod), I am rarely, if ever, actually looking at the remote when operating it, usually because I keep it in my pocket or inside my jacket or somewhere tucked away and I don’t want to have to pull it all they way up so I can see it every time I need to click on something.

But because the shape of the volume and play/pause buttons are the same and it’s very hard to know which way is up or down when not looking at the iPod, I am constantly pausing when I want to be changing the volume or vice versa. It seems as if whoever designed the remote assumed that the user would always be looking at it when operating it, which in turn leads me to wonder if they actually did any field testing of the thing.

Seems it wouldn’t take much actual use of the remote to discover that it’s likely that the operator would not want to have to be looking at the remote to be able to operate it. Why not apply the functional identification to the shape of the button? In other words, why not give the up/down volume button a distinct shape, such as a triangle shape that maps to the volume level?

And while we’re at it, might as well apply the same concept to the next/previous track, making the shape-based concept complete. (In humble deference to the designers at Apple, I also corrected the icon they are using for the next/previous track; the one they are using is actually the icon for going to the first or last item in a list rather than the next or previous one…) This way, there is no need for any tactile guesswork every time you want to change the volume or track or whatever.

And in addition, after some wear and tear, when the white labels have all but faded away from the endless clicking of greasy fingers, that won’t matter much, since the user will still know which button is which based on it’s shape.