Back in June, I wrote a rant about the unorthodox and not entirely successful innovation baked into the elevators at the new Times building. As I learned afterwards, they were designed according to a principle of elevator service called destination-based dispatching. The basic idea is that, rather than putting passengers on the first elevator car that arrives, the system routes passengers to the cars that will deliver them to their destinations most quickly.
This approach somewhat upends the traditional way passengers interact with elevators. Instead of hopping on the first car that arrives and punching a button for a floor, a passenger punches the button for her floor first, on a keypad available at the elevator bank. The system then directs her to, say, car number three, along with other passengers heading to the same floor. Once on the elevator, there are no buttons, nothing to push. It’s a little strange. At least the way it’s been implemented at our building, sometimes it works and sometimes it doesn’t.
In Elevator Design, There Are Ups and There Are Downs
I only know that it’s called destination-based dispatching thanks to a comment added by one of my readers: Sara Rahimian, a software engineer who worked for six years at Motion Control Engineering, a company that, you guessed it, specializes in elevator engineering. While there, Sara developed elevator dispatching products and led a twelve-person research and development team for the company, a depth of experience that far outclasses my own when it comes to talking knowledgeably about elevators. (She’s since left Motion Control Engineering and started a fledgling Web development practice of her own called Slick Logic.)
Via email, I asked Sara for more insight into the mysterious world of elevator design. In much the same way that an average user of the Web routinely underestimates what goes into creating a successful online experience, I had little idea of how complex elevator logic can be. It’s fascinating stuff. To me, elevators were always just things that go up and down; for Sara, they’re a science.
Playing in Traffic
For instance, there are four basic modes of traffic: balanced mode, in which up and down calls are evenly distributed throughout the building; up-peak mode, in which most traffic wants to go up (mornings, usually); down-peak mode, in which most traffic heads downwards (close of business, usually); and lobby-peak mode, in which the majority of the traffic goes from the lobby upwards.
An elevator system’s behavior has to be tuned to match the particular pattern of these modes that each building follows. It’s the job of a systems designer, like Sara, to implement learning algorithms and heuristics in software to identify the patterns and adjust the distribution of dispatches accordingly. Everything is measured, even the wait time between calls — both those made from hallways and those entered from inside the elevator.
However, that overview assumes the standard set-up for calling an elevator from a hallway and punching a floor button inside the car. Things get trickier with destination-based dispatching, which explains the long wait times I experienced at the Times’s elevators. Sara explained some of her experience with designing these systems:.
In most cases, I found that an algorithm that minimizes people’s wait times in the hallway can only perform so well because the elevators are not omniscient and need to travel some number of floors to respond to a call. But with proper learning and heuristics they can do very well.
In modes like lobby-peak we had averaged wait times as low as five seconds. And overall in a busy building we averaged wait times under twelve seconds. In most cases, 98% or sometimes even more of the traffic was served in the average amount of time and every once in a while one call would wait forever 60 to 90 seconds (therefore inflating the average wait time).
In those cases, it was almost always because of some buggy scenario that wasn’t implemented correctly. These cases were hard to track but overall that was my job, finding out what scenarios lead to extremely long wait times and making sure the system was programmed to respond correctly.
Destination-based dispatching, then, is an inherently trickier problem than traditional dispatching, but it can be effective. What makes the problem unexpectedly fascinating, though, is that the challenge is no longer completely one of physical engineering efficiency:
Destination-based dispatching changes the name of the game — because the technical problem to solve is [no longer] minimizing people’s hall call wait time, but rather their total elevator involvement time.
The algorithms try to minimize a person’s time to their final destination. But I don’t know how well this concept will work with human psychology. For one thing, people might find it annoying that they stand there while other people show up and quickly get on their designated elevator. People are used to ‘first in/first out’ when waiting for an elevator. They also might find it irritating to hear elevators swishing past them and not responding to their call, although that can happen in conventional dispatching as well.
In effect, we’re talking about experience design. Presupposing a perfectly running, fully de-bugged destination-based dispatching system, it’s the intangible quality of what users are experiencing that becomes the toughest nut to crack. Though the system may in fact be delivering passengers to their floors with greater efficiency, a designer is still left to struggle with the subjective expectations of its users.
Car Four Where Are You?
This explains the frustration that I and many of my colleagues experienced when we first encountered the elevators in our new building. For all we knew, we were getting from floor to floor with great efficiency than if we had been using a conventionally dispatched system. But the problem was that it didn’t; feel that way. And, to be fair, it also probably explains (at least in part) why the elevators have become moderately more acceptable over time.
In the intervening months, there have been some actual engineering improvements to the timing and behavior of the system — at least that’s what I understand, as it’s unclear to me as to what exactly was done. Whatever the case, the system has improved somewhat, or at least our perceptions of its performance have. It seems likely to me that passengers, like myself, have become accustomed to the elevators’ somewhat idiosyncratic behavior; the prolonged exposure and increased familiarity has changed the experience.
Actually, “accustomed” may be too strong of a word, as it’s still not uncommon for the chatter you hear while riding the elevators to focus on misunderstanding the system or being delayed by the system — it’s chatter that’s spoken with bemusement at some times and frustration at others. As it turns out, it’s not necessarily a positive sign of the overall success of your system when your users can’t stop talking about it. It all comes down to experience.
This kind of system was installed in our main building in December 2005. I never used it (I worked in another building), but apparently it had a lot of bugs and people were complaining all the time. Last time I used it, a couple months ago, the system worked fine, but people in the elevator were talking about how weird this is and how it seems to take forever. Perhaps it will just take a few more years for people to accept the new system?
By the way, I remember a Japanese skyscraper simulation game that was heavily depending on elevator optimisation. Can’t remember the name though.
I find that people are becoming less picky about what floor they want to go to these days. If I want to go to seven, but the first elevator that comes is destined to six- I take that car then walk up the stairs one floor.
Also, due to how different the experience is with these new devices, I prefer to refer to them as “vertical transporters”.
This is interesting stuff.
Going back to computers, it made me think about file systems where you encounter a somewhat similar problem. Applications A and B both need to read data from a hard disk, but A’s data is in a different part of the disk from B’s. How do you minimize the latency?
There is actually an algorithm called “elevator seeking” which prioritizes the read requests in order to reduce the movement required by the read head (the “elevator”).
Thanks for this post, Khoi – I’ll never think about elevators the same again. It got me thinking about the programming involved in controlling other aspects of daily life I take for granted. I wonder what kind of development effort is put into, say, road traffic signals, air traffic control, or national energy distribution?
Imagine if a crack squad of Google engineers were tasked with optimizing the street traffic in a busy city, for example… would they be able to significantly reduce traffic, or are there no major innovations left in areas like this?
On a macro level, I’d imagine that optimizing these kinds of systems becomes crucial to being able to handle the swelling global population.
Thanks again for the insight.
Got me thinking of the insanely old Maxis game SimTower, which is basically an elevator simulator. Has most of the features mentioned above as tweakable settings, including optimized directions, wait times per floor, etc. Good fun back in the days.
For more elevator fun, check out The Intuitionist by Colson Whitehead. An intriguing and thought provoking read…
I am intrigued by Sara’s observation that even *hearing* elevators swishing past your floor is a frustrating and highly negative user experience. There’s a lot of psychology involved in all kinds of user experience design, but the notion that competitiveness (also exemplified in the situation where you watch other people get on their destination-specific elevator car even if they’ve not waited as long as you) could be a major user experience factor is a fascinating new idea for me.
It reminds me of a psychological study that showed that people would rather make empirically less money overall than know that they make less money than their neighbors (for example, you’d rather make $50k when your neighbors make $40k than make $75k when your neighbors make $100k). We don’t want to feel like we are getting less than other people.
Thanks for delving deeper into this topic, Khoi!
@Dan: +1 on The Intuitionist.
During my recent trip to Manila in the Philippines they had a system of elevators just as you described. I was confused at first, but then quickly caught on.
Another software parallel: back in the days when most applications ran off removable media and load times were an issue, it was common to have something distracting happening on the screen (animation, flashing colors) during I/O operations. An ex-boss of mine told me that users generally perceived the load time as faster, even if showing a blank screen would be quicker (due to the decreased overhead).
You see vestiges of this technique in modern console games.
Regarding your closing comment, that people in the elevator complaining about the elevator suggests a lack of acceptance:
Note that people sharing an elevator are desperate to talk about something rather than just stand there, and the socially easiest topic is a novel, shared experience such as a newfangled elevator. And the socially easiest flavor of such a topic is to complain about it – bitching is the conversational path of least resistance, as it generates comisery.
This unfortunate psychology confounds negative chatter in the elevator as a barometer of acceptance.
I haven’t used elevators as pointed out by you. But I have used some which downright defy logic. Coming from a programming back ground, I always tried analyze the way the elevators at my office worked. Never could I figure out.
For sample: at 11:00pm at night, you find all the four elevators on the same floor. (This is a time when the load is almost zero, why not position automatically, so that any person trying to use the elevator from any floor gets to it in the minimum possible time?)
Tough this post gives me a consolation that at least some companies care, I don’t happen to have a great respect for most of these elevator manufacturers
What’s really most jarring about the Times elevators is not knowing where you are at any given moment. The display system shows only the floors the car will stop on, but never tells you where you are right then. Instead you need to watch the display till your desired floor number vanishes, at which point you must quickly jump out. God forbid you get lost in conversation or space out. Imagine taking a cab with the windows blacked out. Disconcerting for the human.
Whilst I’m strictly a stair man myself – my home/office is only on the first floor – I’d just congratulate Khoi on another great post (and everyone else for the comments it has elicted).
The breadth and depth of thinking at subtraction.com keeps me coming back long after many enjoyable, but essentially disposable, ‘narrow’ design blogs have been sampled and then forgotten.
Thank you! Your remarks have been sent to Khoi.