Untuitive Interfaces: A look at MPL's Automatic Doors

Minneapolis Central Library

Every now and again, there’s a tried and tested way of doing something and it gets enhanced somehow. Sometimes these enhancements are pure genius and sometimes they are half-baked. Today, we’ll look at the half-baked automated doors at the new Minneapols Public Library.

Automated doors are all fairly standard. There’s either a platform that opens when weight is applied (a la grocery stores), or there are large buttons with an engraved handycapped** symbol placed at wheelchair height. Usually automated doors only work well when they are moved by the motor, and give quite a bit of resistance to manual operation.

These aren’t the most perfect designs in the world, in fact, there’s plenty of room for change, for better or worse. MPL’s design involves making the entire door the button. You push the door slightly, and then it opens (and somehow knows which direction to open, as to not smack you in the face). Pure Genius… almost. While logically this makes sense, the flaw is in the execution. When I approached the door, I pushed it, like it beckoned, and then pushed it again… and again, and then eventually it started opening. Since it’s motorized, you can’t easily push it manually. This 5-second frustration was more than just me, it was everyone wanting to get in.

Fortunately it’s not a bad design, it’s just unresponsive. If I pushed it, and the actuator took over immediately in a single smooth motion, this would be perfect. Wheel chairs would gently run into the door and the door would open up. People would attempt to push open the doors and “voila!” it’d give you a helping hand.

This really isn’t so much a rant about automated doors, so much as its a look at what I’d call as “untuitiveness.” You have something which people do intuitively (e.g. push a door open) and then you break it. In our example pushing a door to open it is now broken, because although pushing the door slightly triggers the actuator, this is a lot different than what people expect. Plus the added wait time results in more confusion.

This can apply to web sites. For example, let’s take scroll bars. A web site that doesn’t fit in a browser window will often have horizontal and/or vertical scroll bars so that you can view the entire page. We can easily change the interface for a scroll bar. Maybe it’s a thumbnail in the corner that shows a view finder (a la Photoshop ) and we use that to navigate and disable the scroll bars. It’s arguably a better interface, but it’s going to cause problems for the end user ultimately since they 1. aren’t used to it, and 2. there might be some lag-time (assuming it’s implemented with Flash or DHTML).

This isn’t to say we shouldn’t come up with creative new ways of doing things – we should – but, some care needs to be taken toward usability. After all, your site is just one site on the Internet, even if you have a high ranking web site, you’re risking huge user-frustration if you try to do things too different – to “untuitive.”