Live data from Hacker News

Show HN: Elevators

john.fun

321–330 of 426 posts

Re: Show HN: Elevators

#321

> Destination Dispatch [...] are in general worse I wonder if this is an artifact of how the author used random destinations. I worked in a building that used Destination Dispatch, and the common travel pattern seemed to be: - Everyone who is not on the ground floor generally want to go to the ground floor. - People who are on the ground floor generally travel in large groups to the same destination. This happens bec…

This is case where you need to make sure your test data reflects real-world usage or you end up optimizing for the wrong thing. Ideally a new elevator installation would have a trial period where they record usage and then run it through a simulator like this to determine the optimal strategy for that particular building. And you'd want to re-run it every once in a while as the building tenants/usage changes. I wonde…

> Ideally a new elevator installation would have a trial period where they record usage

There's a tricky problem here: as a user, the first thing you do upon discovering a new elevator, especially if you expect to be using it regularly, is to observe how it behaves and adjust your own expectations/behavior to it.

Re: Show HN: Elevators

#322
post #266

I am currently staying in an AirBnB of a 60 floor tower, and the three elevator shafts definitely cannot handle this (I don't think the building was designed with renting to tourists in mind). The elevators are frequently completely saturated during weekends, meaning that the elevator stops at each floor, but noone can get in because the elevator is already full. This means the backlog of people wanting to use the el…

> 60 floor tower, and the three elevator shafts

I don't think I've ever seen a 20-story building with less than 4 elevators at a minimum.

I've worked in low-rise office buildings with no less than 10 elevators.

Seems like that gross deficiency should have been stopped at the city inspector's office before plans were approved.

Re: Show HN: Elevators

#323
Elevators are, in a way, a heap of social and psychological problems stuffed into a box that moves up and down a lot. The article briefly acknowledges it, but like ~all such articles I read over the years, it's primarily interested in wait time and focuses on which quantile to minimize and how. But I'd love to know if and how the soft, squishy thing is being accounted for.

The core problem: elevators are frustrating for many reasons, and that frustration often manifests as hidden blame and hate towards other fellow passengers. Like, IDK, I'm sitting there with a stroller and a kid on floor -1, trying to get to the train platform at floor 0, but the elevator isn't coming because it's going back and forth between 0 and 2 and 3, as people who came by cars shuttle their luggage to and from the parking lot. As a city dweller and non-car person, I can feel my hatred towards cars and drivers bubbling up right there.

I imagine the same is felt by them if I manage to snatch the lift and go from 0 to -1, when they'd really love to already be on +2.

There's many other cases. Mall problems are different than train station problem, different than tall residential building problems, different than office building problems. Destination Dispatch is its own special thing, with its own special psychological twists. But two things I observed in general are:

- If there is a control element available, you will blame people for using it (even internally). Like, "I'd be there a minute ago if not for this damn XYZ who just had to press the button at exactly this time, and they weren't even going in this direction!"

- If there is an indicator element available, people will optimize around whatever it shows.

Like, someone gets at floor N, sees most of the buttons between there and their destination M lit up, immediately presses N+1 to get off there and call another elevator. But if the buttons are visible enough from outside the lift, they may just not get in in the first place, saving themselves and the others time and trouble, etc.

The more I think about it, the more I see that placement of buttons and indicators in the lift is in itself an UX engineering problem with unusually high impact of every decision on well-being of the users.

EDIT: Also ironically, and in line with my feeling that Star Trek got more things right than people give it credit for, a lot of elevator problems - both scheduling and social/psychological ones - would be solved if elevators just moved faster, like 2-4x faster than now, and also in some cases, also moved sideways. I.e. turbolifts.

(That, and if it didn't immediately led to the building owners putting less of them. So put another way: frustrating lifts is the sign of building owners/designers cheapening out.)

Re: Show HN: Elevators

#325

It's a pity that paternoster lifts are so unsafe [0] — we could avoid all problems to do with scheduling if they were safer. On a related note, could someone please design continuous spiral escalators with horizontal sections at each floor? 0: https://en.wikipedia.org/wiki/Paternoster_lift#Safety

They're not great for accessibility, either.

Re: Show HN: Elevators

#326

Earlier quoted context omitted.

This is case where you need to make sure your test data reflects real-world usage or you end up optimizing for the wrong thing. Ideally a new elevator installation would have a trial period where they record usage and then run it through a simulator like this to determine the optimal strategy for that particular building. And you'd want to re-run it every once in a while as the building tenants/usage changes. I wonde…

> Ideally a new elevator installation would have a trial period where they record usage There's a tricky problem here: as a user, the first thing you do upon discovering a new elevator, especially if you expect to be using it regularly, is to observe how it behaves and adjust your own expectations/behavior to it.

I think you belong to a small percentage of the population doing that. Most people don't bother with such detailed life microoptimizations.

Re: Show HN: Elevators

#327
post #257

Earlier quoted context omitted.

This is case where you need to make sure your test data reflects real-world usage or you end up optimizing for the wrong thing. Ideally a new elevator installation would have a trial period where they record usage and then run it through a simulator like this to determine the optimal strategy for that particular building. And you'd want to re-run it every once in a while as the building tenants/usage changes. I wonde…

The data is already there. This also gets more interesting when you expand the scope from just elevators to general building occupancy and movement. In the simplest sense, I've seen this tied into security gates so as people badge on when entering the building there's already suitable elevator movement to meet demand by time the foot traffic reaches the lift lobby. That can then also feed into destination dispatch if…

> (...) and a lot of very good things from a sustainability and general optimisation perspective. The flip side is it also has the potential to be an absolute dystopian privacy nightmare.

Privacy is an illusion for most people, and in office spaces, it's also a red herring. Wifi trilateration doesn't make things worse when you have a CCTV camera on every corner, badge reader at every other door, and presence sensing in conference rooms. Dystopia does not materialize without a severe regime shift.

Nah, my main worry is precisely sustainability and optimization, i.e. cost-cutting, because the more tools you give a business to optimize, and the more bullshit excuses ("sustainability! saving the planet!") you give a business, the worse the outcome is for users (here: employees). And a lot of that is doubly annoying, because it's counter-productive.

So what you have smart sensors in every room, and combine it with badge readers and wifi trilat and what not, and have smart auto-routing/rebooking algorithm: half the week, all conference rooms are always booked full, and yet somehow when you physically go and check, a good half sits empty, and it's apparently an impossible problem to solve.

So what the bathroom wall says, "with water-saving fixtures, we're using much less water in this building", and "we're now saving 2L water per flush". It's all bullshit, because those eco inventions mean I need to flush 3 times instead of once, and it means that I spend a minute washing my hands instead of 10 seconds - especially because both the soap and the dispenser are also optimized, so it takes 20 seconds to get enough soap on your hands, and then extra 20 seconds to get it off afterwards, because unlike normal people soap, it leaves your hands slippery for some reason.

And then they say "scientists said you can dry your hands with just 2 paper towels". At that point I'm getting red, because yes, I saw that TED talk 15 years ago too, and yes, it's total bullshit. Maybe it was true then, but the industry and the beancounters have value-optimized paper towels 15 times since that.

The generalization and summary of this rant is: slack is good. Happiness lives in slack. There is such thing as optimizing too much. Also the small, isolated systems under optimization, are in reality neither small nor isolated.

Re: Show HN: Elevators

#328

How often do people travel between non-ground floors though? In my own experience, whether it's a residential or an office building, 99% of elevator usage is a) someone going down to the ground floor, and b) someone going up from the ground floor. There are some exceptions like hotels that have amenities on different floors though. The first elevator "algorithm", if you can even call it that, that I've ever encounter…

Not sure how common it is but Bern train station has 3 elevators, usually 2 are set to normal and one to "express" which means all middle floors (mainly parking) are locked and you can only go ground to top (outside so a lot of people going to/from the station on foot) It's super efficient for people who understand the system at the detriment of people who don't, as they get in and mash the middle buttons and get con…

Having visible, pressable buttons that do nothing is terrible UI. Why not just screw a metal plate over these do-nothing buttons, or at least tape a piece of cardboard?

Re: Show HN: Elevators

#329

Back in highschool, simulating different elevator algorithms was one of the projects I implemented during my CS class. It wasn't for the class — AP CS did not require anything like actual programming — but it was a fun project. A cool connection is that a spinning-disk hard drive (HDD) is actually kind of like one really long elevator, just wrapped around a spindle instead of perfectly vertical. The SCAN algorithm is…

The elevator algorithm → disk scheduling connection is such a perfect example of how CS concepts keep showing up in unexpected places. Same idea, completely different domain. It makes me wonder how many other "unrelated" problems we're solving today already have decades-old algorithms waiting to be rediscovered for them. Robot motion planning is basically just elevator scheduling with more degrees of freedom.

FYI: all your comments are [flagged][dead]

I don't know why, because they all look fine to me...

Re: Show HN: Elevators

#330

Earlier quoted context omitted.

This is case where you need to make sure your test data reflects real-world usage or you end up optimizing for the wrong thing. Ideally a new elevator installation would have a trial period where they record usage and then run it through a simulator like this to determine the optimal strategy for that particular building. And you'd want to re-run it every once in a while as the building tenants/usage changes. I wonde…

I wonder if we'll see LLM elevator scheduling

Most likely not. I think all the big players have been using more traditional ML approaches for years. Then again someone new might go there and fail miserably.
Post reply on HN