The biggest problem I always have with elevators is not the algorithm, it's the people seemingly being unable to grasp the concept of pressing either the up or the down request button, depending on where they want to go. Almost always I find someone will press both, because "then the elevator comes faster". Completely ignoring the fact that they end up going the wrong way first half the time, and adding an unnecessary halt for everyone already in there. How hard can it be to understand?..
My wife always randomly hits the up or down button, then gets upset if I explain why she should only pick the one she really wants. She forgets the next time. I think some people never really understand how elevators work.
See also: the keep open / close doors button. I had one building administrator explain to me we should add a delay of 10 seconds to the "quickly shut door" button because otherwise she kept getting her arm hit by the door. When I asked why we would add a delay to the button that's meant to reduce delays (why not simply wait for the door to close on its own, then?), and whether we should fix the sensor that prevents doors from closing if there's an obstacle instead, she just kept staring blankly at me. I don't think she understood me at all.
Again, some people simply don't grasp how elevators work.
Primarily this fixes the bug in the interface which is allowing the user to input data that does not match their declared destination. However, a second benefit is that you can then obtain per-user destination information, which is useful in capacity planning and currently lost in shared direction-only button pressing. Finally, you could usefully use non-floor specifications, ie. 'Ladies underwear', 'ACME Co.', etc.
This reminds me of my partner, who always sets car air conditioning to 50F (the min) or heat to 90F (the max) because she thinks it makes it get cold or hot faster.
And of course a few minutes later we’re freezing or roasting. She sees the temps setting as controlling intensity of cold/hot rather than just, you know, the temperature you want.
"2.3 Non-directional collective
Non-directive collective control provides a single pushbutton at each landing. This pushbutton is pressed by passengers to register a landing call irrespective of the desired direction of travel. Thus, a lift travelling upwards, for example, and detecting a landing call in its path stops to answer the call, although it may happen that the person waiting at the landing wishes to go down. This type of control is only acceptable for short travel lifts."
It doesn't; it just needs to know it was called. You make your selection once it arrives.
Look up the early history of elevators and you'll see a progression from fully manual in-car up/down controls (often with a dedicated human operator); various semi-automatic systems with minor improvements like automatic leveling and door control; and then operatorless systems that started with nondirectional calls:
It is reasonable if you either have low load say a residential building where lift is often idle. Or low number of floors where travel times in either case are short.
Yes, same here, in croatia people believe that you need to press the opposite direction to "summon" the elevator, if the elevator is on lower floor they will press the "up" arrow to bring it up to their floor. And then of course when the doors open they will ask "going up or down?", which is ridiculous. When I point out that the ground floor only has the "up" button they just ignore it (hard to unlearn ingrained beliefs).
> in croatia people believe that you need to press the opposite direction to "summon" the elevator, if the elevator is on lower floor they will press the "up" arrow to bring it up to their floor
Yeah and you can flail your head around looking for the arrow or you can just ask. Especially on a busy elevator lobby there might be multiple cars opening at the same time so you cant even tell from the ding/ding-ding
or just point your eyes a few degrees away to look at the dedicated arrows next to each elevator, built for this exact use case, which indicate whether that specific elevator is going up or down?
I have to assume this is a cultural difference and you just don't have those indicators where you live, rather than "slightly moving my eyes is too hard, better make my problem into somebody else's problem"
Sometimes I think "stupid" questions like these are just a way to break the ice, something that gets used to kindly acknowledge the momentary existence of others in our lives before we continue down our separate paths.
When you're at a lower floor and you're trying to go down, but its a time period where traffic is trying to leave you can end up in a situation where nearly every elevator going down is already full. So you call for down, cab arrives but is already full, it goes, you call again, another comes, its already full, rinse/repeat. Sometimes there's not much up traffic during that time, so it can be a legit strategy to just go ahead and call on the up and ride it all the way instead of waiting and hoping for space coming down.
Although I guess that's not quite what you're talking about.
In situations like this the answer usually comes by flipping it and assuming they do understand, and asking why it makes sense now.
It's probably just the old 'fake loader' psychology, to be honest. Waiting without knowing when the elevator will arrive is boring/frustrating, where getting into an elevator that moves, even if the wrong direction, feels like progress.
Things are happening, and even if it takes longer ultimately that's a less frustrating state to be in.
In some places, I see people do that. It’s not stupidity. I learned the logical reason after observations. During busy hours in some busy buildings, there isn’t enough elevator capacity. Therefore, if you want to go down to the ground floor, taking a trip up and then down might be better (a less-bad worst case outcome, or even a better average outcome) than waiting for a non-full downward elevator. In such case, it’s logical to press both up and down.
Like let's say elevator is at 5, I am at 1 wanting to go to 3, and before I arrive there is already someone else at 1 wanting to go to -1.
I'll get in with them going DOWN so that it doesn't have to stop a 2nd time on the way up.
There are also other situations where I'll press it in the wrong direction if I think it's already likely to stop on the way down (due to me being on a popular floor) to save an extra stop on the way back up.
I live in Ireland. 10+ years ago I used to the travel to the US quite a bit (5-10 trips a year). The majority of the time I would fly via a major EU hub like AMS or CDG even if there was a direct flight from Ireland.
The reason? Other factors that were important to me!
Examples:
- cost optimisation. I could fly business within company budget rules.
- flight time. I highly valued longer flight times between Europe and the US west coast so I got a proper night's sleep when flying east-bound. Doing connections on the east coast often meant quite short transatlantic flights that arrived very early in the morning. Much harder to manage the jetlag.
- Product offering. Some of the routes from AMS and CDG had much newer planes and cabins.
- Airline alliance loyalty. Given the travel pattern it meant sense to pick an alliance that delivered some value. Irish airlines didn't have much to offer and were much more expensive for a worse end to end product.
Elevator algorithm I'm used to always goes up from lobby and always goes down from any other floor. Meaning that it goes all the way to the highest order and picks orders top-down until reaching lobby. Only exception is going to underground parking floors which is relatively rare in my housing complex.
Some companies only get to a "hello world" level with a new kind of tech via a 50k per head training. The organizations are setup in a way that people can't experiment or learn by themselves, it's really the only way.
The Fastmail client is good when it's up and running, but not as good as well-implemented native apps. The initial startup is much slower, and the iOS / iPadOS app (which is the same webapp iirc) is pretty bug-ridden, with the webview freezing or app not progressing past the loading animation without a close swipe / reopen.
You can definitely make a webview app that starts as quickly as most native thing (sub-1s start). We used Tauri and you wouldn't be able to tell the difference.
That's a pretty simple view of native app vs web. Web will always have a lot of baggage that native apps simply won't have, layers and layers of abstractions that still needs to load.
It's true that a blank canvas loaded as a web view will start fast, though. But in practice, when web applications grow - performance tends to take a hit, and the developers also tend to be careless with resources.
Web developers are not magically worse at this than native devs. See: much of the windows OS lately. The performance of a web view app is more to do with the quality of the devs than the platform it's built on.
Generally though, web developers are of lower quality than native app devs. Often little or no consideration to the layers below, and their focus is more on security rather than speed.
Funnily, I'd say the reason web apps tend to be worse than native apps is because the web is so much more powerful and flexible.
For a native app, I'm often limited to just a small set of components and maybe images I can put on those components. Animations are out of the picture. Configuring colors is sometimes not available but always painful (every component needs it tweaked, there's no universal way to change it). I can't really change things like border margins, rounding, or adding crazy stuff like wobbles or splash effects on click. And really, the more I try to add those things, the worse experience it ultimately ends up being as the OS style and theming moves on. My best bet is keeping everything as close to native styling as possible because that has the best shot of still being usable in windows 20.
Because web apps allow configuration of everything, everything is configured. There are libraries and frameworks that do mass configuration. You can always add 1, 2, or 20 new layers and webdev has abstracted that away into a simple <MyButton /> component. And because of all these capabilities, you need a pretty beefy runtime to be assured you can do them all. Coupled with the fact that this is all also powered by a javascript engine.
Although technically speaking, native is much more flexible as you can literally do anything. But yes, most devs will just use standard UI components and that's it. So your point holds.
Well, to do literally anything outside of standard components, you effectively end up in a realm of programmatically drawing your own "anythings". Certainly possible because obviously browsers are examples of this. But a lot harder.
The downside of the native app is the open abuse of surveillance. Why does Teams _need_ local network access to function on my ipad? Why does outlook want access to bluetooth from my phone?
Users don’t want to have to configure every app to fuck off, and native web apps (the world we _all_ live in) work way better than some hodgepodge of shit baked together by copilot that’s using unsafe calls and/or libraries.
The teams conferencing solution probably needs it. It’s pretty spiffy when it works - it detects whether you’re in the same room as the conferencing device and potentially suggests muting
> That's a pretty simple view of native app vs web. Web will always have a lot of baggage that native apps simply won't have, layers and layers of abstractions that still needs to load.
Well, as I say, you can definitely have webview apps that start fast and aren't taking ten seconds to do things. Not just blank canvasses.
My main gripe with the Fastmail client is that it doesn't work offline. This is of course absolutely possible to do with a webapp, and IMO ought to be a priority for an email client.
I literally switched on "Enable offline support", caching "All mail" offline on my iPhone a few months ago. Tons of free space, only using 4GB for offline.
But when my phone is actually offline (on a plane or elevator) it beachballs when trying to find something.
I didn't, but I'll do so now. I usually don't bother with support, because I forget that good companies like Fastmail actually have a competent support team.
Not OP, but I had to change the mail cache from all mail to recent, I think because it couldn't handle how much mail I had? It would often get stuck not syncing, and offline would be unreliable and showing a blank screen. Recent works fine, but it would be worthwhile folks testing more with all mail enabled, especially if they have larger inboxes.
Got an example of a well-implemented natice app for email? I'm bugged by some bugs with the Fastmail app, but have generally had a better experience with it than any other client I've tried. Search in particular is far better on the Fastmail app.
I've heard good things about it, for sure, but I'd argue that it isn't really an Email client. It is a Gmail client as it doesn't work with anything else. Fastmail is in the same bucket, but it is part of my contention about there not being good Email apps generally.
It’s really tempting - uses their API for that speed.
I’m worried Google won’t like it someday. It’s such a hassle if they shut you off that I want to seem like the most normal user to them. Pay Mimestream, skip ads, avoid Gmail app telemetry… any incentive for Google to permit it longterm? (Like maybe you’d switch to Fastmail if they killed Mimestream… or maybe not!)
> Got an example of a well-implemented natice app for email?
Mail.app isn't total shit. It's not great. But it doesn't fumble the basics, like Outlook for Mac, which thinks it's fine to take like 10s to show me my inbox.
Why does it seem to take so long to get & read one new email?
I can use get new mail or synchronize in Mail.app, but always spoiled by the instantaneous Gmail app notification. Often don’t have patience to wait for Mail.app for 2FA codes (just OCR or manually type from the Gmail notification mirrored on Mac).
Also should back up a bulk of ancient emails clogging the app, might be partially my fault.
It has its quirks. For example it can’t attach an image without inlining it. Or if the sender has several email addresses saved it can’t show which one sent you a particular email. And it can’t show you which of your email addresses received a given email.
it really feels like that not progressing past the loading animation all of a sudden has gotten worse. like yea, used to happen like once a week for me, but now it's probably once a day
There is actually a photo of a Model 3 in factory line doing that precise positioned target stuff, so they do that precise positioned target stuff at the factory. It's also instant compared to a 10-minute drive.
I think the real reason why Tesla is known to require 10-minute calibration drive is, they shipped APHW2 long before the software matured, so they needed means to do it after the cars were shipped "blank". Other manufacturers only ship finalized hardware and software, and so they don't need a scalable tool-free calibration method.
Anyways, my point is that, Tesla cars need calibrations like anything else. This is same for any multi sensor SLAM systems, whether it uses sets of color cameras or laser spinny thingy or laser flash cameras or laser flash color camera thingy or combinations thereof.
The measure voted on is "Extension [of Chat Control 1.0]", it was voted 36% "for" and 49% "against" (so result is "against"), and looking at "Political groups", majority of EPP MEPs voted "against" (137 out of 164 votes).
That's exactly what Tesla is doing with their validation vehicles, the ones with Lidar towers on top. They establish the "ground truth" from Lidar and use that to train and/or test the vision model. Presumably more "test", since they've most often been seen in Robotaxi service expansion areas shortly before fleet deployment.
I don't have a specific source, no. I think it was mentioned in one of their presentation a few years back, that they use various techniques for "ground truth" for vision training, among those was time series (depth change over time should be continuous etc) and iirc also "external" sources for depth data, like LiDAR. And their validation cars equipped with LiDAR towers are definitely being seen everywhere they are rolling out their Robotaxi services.
They've acknowledged an issue now on the status page. For me at least, it's completely down, package installation straight up doesn't work. Thankfully current work project uses a pull-through mirror that allows us to continue working.
