How to avoid the "local elevator" problem?

Question: I live in a high-rise apartment building in New York. Our building has four resident elevators which each serve every residential floor. (An additional fifth elevator (physically separated from the four described herein) serves as a freight elevator for movers, contractors, and building staff.)
However, "elevator #1" is special - it is the only one of the four that can reach the rooftop, as well as the only one of the four that can reach the parking garage in the basement. It is also slightly larger in size than the other 3 elevators, to accommodate wheelchair-using residents and strollers.
As such, the elevator banks on each floor have been outfitted with two elevator call panels - the one in the center of the bank (panel "B") can call any of the four elevators, while the buttons on the panel next to elevator 1 (panel "A") specifically call only elevator 1:
<code>          1               2                 3               4
    ┌─────┬─────┐   ┌─────┬─────┐     ┌─────┬─────┐   ┌─────┬─────┐
 A  │     │     │   │     │     │  B  │     │     │   │     │     │
┌─┐ │     │     │   │     │     │ ┌─┐ │     │     │   │     │     │
│▲│ │     │     │   │     │     │ │▲│ │     │     │   │     │     │
│▼│ │     │     │   │     │     │ │▼│ │     │     │   │     │     │
└─┘ │     │     │   │     │     │ └─┘ │     │     │   │     │     │
    │     │     │   │     │     │     │     │     │   │     │     │
    │     │     │   │     │     │     │     │     │   │     │     │
    └─────┴─────┘   └─────┴─────┘     └─────┴─────┘   └─────┴─────┘
</code>
A problem commonly arises (especially during peak times) that residents will walk by both panels and select their desired direction of travel on both, even if they are intending to go to a floor which is serviced by all 4 elevators. This becomes a challenge when those riding in elevator #1 are now stuck stopping at every floor in which another resident has pressed a button on the leftmost panel, whether or not the resident has already boarded one of the other three elevators headed in their direction. In these peak periods, this can easily add 2-3 additional minutes to a resident's travel time, effectively becoming the "local" elevator (as opposed to the "express" - for anyone who's ridden the subway, you'll certainly know the difference).
How can residents be guided to use the special panel ("A") as intended (only when intending to ride elevator #1)?
Comment: Neither, actually; I literally live in a building where this is a consistent issue, and wanted to understand if there were any UX approaches which could assist in solving it.
Comment: A ux vigilante! Sounds great.
Comment: @pajonk I currently don't have very much in the way of material limitations - I'm personally interested in understanding the "art of the possible" in this scenario. It'll go a long way if/when I and other residents propose some alternatives to our building's management.
Comment: Is this a problem you are tasked to solve, or is this an interview question?
Comment: Are users pushing both buttons because they're confused or because calling two elevators reduces their expected wait time?
Comment: @musefan The other 3 elevators are big enough for wheelchair/stroller access, but certainly less comfortable for those users than #1.
Comment: @J... I think anything short of replacing the elevators entirely is inbounds here. While I don't believe there is as much leeway in actuality for this specific scenario, I can't imagine this is a one-off issue that only my building has experienced; for that, I think it would be interesting to hear any and all novel approaches to this sort of situation.
Comment: You are dealing with two different problems here:
1. how do I tell users which lift to use for which purpose?
2. see Martin Kealey's answer below: users may actually have an advantage if they call all the lifts at the same time. How do I prevent them from doing that?
Comment: What are your limitations? Do you seek for a sign/sticker to place on every floor, or a complete redesign of elevator calling system is also an option?
Comment: You say elevator 1 is slight bigger, but are the other 3 elevators big enough for wheelchair and stroller access too?
Comment: @Brian Based on my small amount of conversations with others, it seems that they are under the impression that selecting both buttons will reduce their wait time.
Comment: Can we assume that your latitude for modifications to the system is restricted to, at best, signage?  Or do you have some budget from the building owner to actually design and implement a new control system for the elevators?  What is the scope of your ask, here?
Comment: @esqew - I gave you a solution we have used for our freight elevators in several buildings.   It works and its cheap.   Also you cannot just replace elevators or add absurd tech to them.   They are actually really really costly.
Comment: The only way I see is to make elevator 1 much slower for a month so people will stop using it unnecessarily.
Comment: Since there seems to be some debate below and in the comments here: there is a distinct freight/service elevator physically separate from these four residential elevators that is used for "freight"/etc. purposes. None of the four described in the OP are "freight" elevators in name or practice.
Comment: You write that the 'Panel B' call buttons call any of the 4 elevators. Are the buttons illuminated, and if so, does pressing a 'Panel B' call button also illuminate the corresponding button on 'Panel A', or does the 'Panel A' button only illuminate when a 'Panel A' button is pressed?
Comment: Well it seems I cannot propose an answer as I've never asked or answered any questions here, but it seems like this may be a human interface issue - it might actually be cheaper to hire a person to stand by the elevator on each floor for a month with only them allowed to press the buttons, interacting with the people to determine which button is appropriate. Sort of like how elevators originally worked except with the operator on each floor instead of inside.  After a month, hopefully everyone has learned how the elevators are supposed to work!
Comment: @Michael this might even work just having someone in the lobby. They'd have to interact with anyone taking an elevator from the lobby (every time they do so that month), at which point the user has recently been reminded that panel A is for those who need the large elevator, or roof/garage access.
Comment: It gravely disappoints me that so many answers here blatantly disregard the disability aspect of this. Yes, a person in a standard wheelchair might still be able to squeeze into elevators 2,3,4... but what about someone in a power chair, or a bariatric wheelchair? For that matter, what about the guy trying to deliver a refrigerator to unit 316?
Comment: @esqew can you take measurements of the elevator doors (and ideally, the cars) at some point, by any chance? On one of the answers there is some debate as to whether elevator 1 is actually intended as an elevator for disabled persons -- the width of the door and dimensions of the car of any of the other three will determine whether they're ADA compliant. If they are, then there's no particular concern around specifically using 1 for that. If they don't meet that, then yes, elevator 1 needs to be reserved for individuals with disabilities when possible.
Comment: I'd suggest having 3 buttons per floor: "Up", "Down", "I can only use elevator #1". Precise labelling & graphics to be studied later...
Comment: esqew's comment on the building's management somehow made me think of https://www.atomic-robo.com/atomicrobo/v12ch1-page-17...
Comment: it's odd how most of the top answers ignored the wheelchair requirement
Answer: Replace the panel A with buttons "to rooftop" and "to garage" instead of "up" and "down". Now elevator 1 is reserved for special floors and most people use elevators 2-4.
Comment: But isn't the first elevator also used for people using wheelchairs going to non-roof floors? "To rooftop" and "To garage" don't capture this usage.
Comment: @jamesdlin the panel for elevators 2-4 also calls elevator 1, as per the question's third paragraph
Comment: I've been to a building that does this. You don't just press an elevator "call" button but you press your floor range instead (though, there's only one panel instead of multiple - but with multiple call buttons). I don't remember how many call buttons there were on each floor but they were grouped like "1-5", "6-10" etc.
Comment: One issue with completely discouraging elevator 1 is that the goal shouldn't necessarily be to direct almost everybody to elevators 2-4, because that means even if nobody needs rooftop/garage/special access, one elevator is effectively out-of-order, and the elevator bank wouldn't be running at full capacity during peak times.
Comment: If there are regular users they are likely to figure out that 'to rooftop' doesn't preclude using the elevator to get to the other floors though.  People will experiment.
Comment: It doesn't matter if they figure it out. They key thing is that the "pressing both buttons" doesn't actually get an elevator faster - elevator 1 will respond to a normal button press if it is free, so the time taken for an elevator to arrive is the same, whether you press both buttons or just the one. The problem is convincing people of that.
Comment: If it's only a label change, I think people will unfortunately figure it out pretty quickly. If it's a functionality change, great, though this answer doesn't say so as clearly as the others...
Comment: This is not accessible design -- a wheelchair or stroller user (or package carrier with a hand truck) may not understand to use "to rooftop" to get to the 3rd floor.
Comment: @justhalf How about a third button with an International Symbol of Access?
Comment: Then people might assume it only goes there and never on any other floor, which is also not the point.
Comment: This is neither a good solution for wheelchair people nor does it fix the issue of the tenants prior knowledge of how the banks work.   You have put lipstick on a pig and caused more issues.   Now you will just have residents mad, for whatever reasons because you are highlighting an issue and acknowledging there is an issue (by making a change) without fixing anything.
Comment: @LukeSawczak This assumes that people understand the current behaviour. They may incorrectly assume that panel B only calls lifts 2-4, and they need to press both buttons to get the closest lift (see several comments that have assumed this behaviour).
Comment: I like it. Add text to indicate "+ handicap access to all floors" and you've probably solved 90% of the problem without rewiring anything. Now it's the garage/handicap elevator, and (nice) people are very reluctant to abuse resources provided for the handicapped.
Answer: On further thought, another solution could be to implement a singular, digital wall panel where users can indicate to which specific floor they are intending to go, much like the ones found in many newer high-rise office buildings and hotels:

Original image by Access Matters on Flickr, used under CC BY-NC-SA 2.0.
Once the floor is selected, the main computer decides which elevator is most appropriate to handle the request based on capacity, proximity, and ultimately whether a specific elevator can service the requested floor or not.
While I don't have access to any specific figures, I would imagine this is more cost-prohibitive than other solutions, and wouldn't make sense in many scenarios similar to the one posed above.
Comment: @JannPoppinga The panel just would need an extra button for special accommodations.
Comment: What about wheel-chair users  or people with strollers?
Comment: @JannPoppinga, jamesdlin: The panel in the photo does have a wheelchair button.
Comment: Valid answer but this is rather $$$$ to install these and their current elevators circuits may not even support this.   Its like saying drop this new engine in your car to make it run faster and the engine wouldn't even fit.
Comment: @CaiusJard sure but you need one of these *per floor*, and it's got 4 elevators so it must have a lot of floors!
Comment: Wouldn't have to be cost prohibitive.. I reckon I could solve that with a raspberry pi, touch screen, simple app and relay board to "click" the elevator buttons for about $150 of hardware. The cost of development time excluded of course
Comment: @MartinKealey: *Would* it necessarily be prohibitive, though? The panel is basically just a touch screen on a stand (plus the wheelchair button); it shouldn't have to cost more than, say, $50 per panel if mass-produced. Heck, a competent DYI-er could hack one together from an old tablet and some spare bits of metal etc. Of course there would also be installation and maintenance costs (and they'd likely exceed the cost of the panels themselves), but they still shouldn't be huge compared to the general maintenance of the elevators themselves.
Comment: @JannPoppinga when I've come across this (hotels), all were big enough to fit one or maybe two wheeled users. But this approach tends to fill the lifts more than the traditional way, so there wasn't always room at peak times.  Lift cabins that are too small for a wheelchair and one person standing are really quite rare in public places, and tend to be ancient. But it's a point that must be dealt with; a suitable icon/button to assign priority may be needed
Comment: @NotThatGuy The question clearly states "[Elevator 1] is also slightly larger in size than the other 3 elevators, to accommodate wheelchair-using residents and strollers."
Comment: @supercat: True, and a very good point. But that's not a per-panel expense. If you can install and certify the panel on one floor, it should not cost significantly more to install them on every floor (which is what the comment I was replying to seemed to be saying would be prohibitively expensive).
Comment: @IlmariKaronen: It is much easier for a building to get certification for an elevator whose control system is assembled from components that already have various certifications themselves, than to get certification for an elevator whose control system contains common off the shelf parts.  The cost of twenty certified panels at $5,000 each would likely be less than the cost of certification for an elevator that uses twenty panels that cost $50 each.
Comment: To those of you doubting the cost: in many places you need a special licence to install or work on elevators, and the elevator companies' prices tend to reflect the value to the user rather than the cost of installation. So stuff that can be implemented in software tends to be exorbitantly expensive, just to keep its cost in line with the hardware (which tends to require certification of manufacturers). Considering that you could do lethal harm to someone by messing up the control of an elevator, this isn't something to be dismissed lightly.
Comment: How about a single panel with a roof, up, down and garage button. A wheelchair button to the right. Pressing the wheelchair button before or shortly after making the call would call elevator 1. It's basically the same as this, but without an expensive touch screen display and software.
Comment: Installing such a panel on _every_ floor would be prohibitive; remember the problem statement is that the elevator stops on many floors on the way down, to collect people who've already left by another elevator.
Comment: @IlmariKaronen: Safety certification for elevators and related control electronics is a "big deal".  There might be some way to set up a control system interface such that it could communicate with "cheap" electronics, but it would be impossible for even a maliciously-caused malfunction in the "cheap" parts of the system to endanger anyone, but I don't know how one could certify that.
Answer: In an office building where I worked, they solved a similar problem by making panel A a bit less obvious than panel B.  Panel B was right out in the open, on the wall between two of the elevators, facing the lobby.
Panel A was located in the kind of door jamb space of elevator 1, perpendicular and right next to the elevator doors.
Comment: This was my office, too. Also, pushing the special elevator button lit up the main elevator panel, so that you couldn't call both. (It's possible that you could get on another one if it happened to stop there, but "get the special elevator guaranteed or another one if another one happens to stop first, but potentially have several normal ones go by while waiting for the special one" is much less tempting than "get whichever elevator is first available".)
Comment: Although this is still abusable, slightly, just less so--see comment on Martin Kealey's answer.
Answer: My thoughts would be to consolidate both sets of buttons into a single panel and draw focus to the primary action buttons.

Roof

UP

DOWN

Car Park
Comment: ... but also "up in a wheelchair"?
Comment: @musefan because elevator 1 serves all floors and is the only elevator wide enough for a wheelchair (and strollers and whatever else) that does so.
Comment: This answer would be substantially improved by an explanation of how this functions to reduce/remove the problem.
Comment: @teedyay: Why would you have a button specifically for "up in a wheelchair"?
Comment: If the system still functions the same, bringing elevator 1 only if you press the extra buttons, why would people not press both for faster service? If not, explain how.
Comment: @OmarL: Sorry, I overlooked that part of the question, thanks!
Comment: @JackAidley seems obvious to me, you don't press ROOF unless you're going to the roof.
Comment: @JackAidley Pressing both buttons will NOT result in faster service. The problem is the current design encouraging the myth of pressing both buttons having any benefits. Just as putting coin-rubbing-surfaces on vending machines encourage rubbing the coin, when it is not accepted. - The single panel design will not encourage the idea of pressing "roof" in the hopes of getting a faster elevator - and since it really does not, it is not deceptive, but rather more descriptive of the real functionality.
Comment: @Falco: doesn't it? That would be in the missing explanation.
Comment: @JackAidley from the OP "Based on my small amount of conversations with others, it seems that they are under the impression that selecting both buttons will reduce their wait time. " - A formulation like this strongly implies this belief to be misguided. But the OP does not explicitly address it.
Answer: This is a people problem.
This can be fixed by using some scotch tape and a piece of paper which reads:

Please use this panel only if you need roof or basement access, or need extra space for a wheelchair or other large belongings.
Thank you for your consideration.
Comment: @peter_the_oak Then dispense spiders from panel A whenever a transgressor uses the panel but candy from panel B.
Comment: I do not believe in this. People just won't realise "Oh, there is information I should process". They tend to not see such things.
Comment: People tend not to read signs like this. They just add clutter and further annoyance because the delayed elevator users are now annoyed both that people have unnecessarily pressed the button and annoyed that they have ignored the sign.
Comment: Unfortunately, having elevator 1 _only_ summoned by its own buttons will increase the incentive to use both call buttons.
Comment: @IlmariKaronen My intent was to put the note somewhere *around* the panel; not covering it. While I agree with the general idea to add inconvenience I think that the note would get ripped off in very short order; whether it be by normal use or by someone disgruntled at the deliberate inconvenience.
Comment: Darn... pretty much the answer I was just about to write
Comment: @thelem Given that OP's opening sentence is "I live in a high-rise apartment building in New York." I have high doubts that they are able to do anything more than what I've suggested so I'd love to read your answer which abides by OP's circumstances.
Comment: @MonkeyZeus They presumably have some means of raising issues with building management. If they can explain the problem and offer an affordable solution, they a good building manager would make that change. Solving the OP's problem will also benefit the building manager by reducing energy use and wear and tear on the lift.
Comment: I like the first part of your answer, but your second part will make the problem worse, so I can't give you an upvote. Please don't mix two completely different approaches in one answer, as it will make voting very ineffective.
Comment: @peter_the_oak: When I first read this answer, I assumed the intent was to tape the paper *over* the panel, so that you'd have to lift the paper in order to access the panel. On re-reading it, I'm not sure if that was the intent or not, but I think it could actually work better than just a plain note next to the panel. In particular, it would both make it more likely that people would notice the note and *less* likely that they'd notice the panel hidden under it in the first place, as well as adding a small amount of deliberate inconvenience to using that panel.
Comment: @MonkeyZeus Thank you :-) Take my vote ;-)
Answer: The variant:

If this is not clear - this is bad solution.
Comments:

Of course this is just a mockup.
Add accessibility icon at Panel A as most people respect this mark and will not use marked buttons.
Add notice to Panel B for rooftop and garage to make clear what to do - explicit allowance to use Panel A appropriate buttons.
Panel A button pairs Up and Rooftop as well as Down and Garage are electronically the same, so only panel should require upgrade but not whole elevator schematics.
Comment: @blankip Sorry about your head ) Try to answer in order of your questions. Once more - this is mockup just to illustrate an idea. Real designer possibly will depict one wheelchair and group in some way two buttons. Icons - available icons just for illustration. Buttons with text labels - the best solution I think too. You are right about expectation - this is possible an issue. But this could be solved by updating elevators schematic and firmware if it is possible.
Comment: The pictures you have made my head spin.  Why two wheelchairs?   Also the wheelchair icon is OK def not great.   The garage and rooftop icon...  really bad.   No way in the world I would think those meant garage or rooftop.   Maybe if you gave me 50 guesses I might say one of the words eventually.   Why wouldn't the button just say Rooftop?   What happens when you hit that button?   I would expect that it would already be pressed for me in the elevator.   Also I don't see how this solves the existing tenant issue... they will just hit the up and down with the weird icon next to it.
Comment: Why not use a single panel with 6 buttons? E.g. buttons arranged similarly to the arrangement of the icons on your current Panel A, with an icon on each button (just add the arrows to the wheelchair icons). The choice of the elevator would be left to the controlling circuit, which would decide the best option depending on user's needs.
Comment: @blankip Of course this isn't a final solution. Don't be so critical.
Comment: @blankip Addition to previous comment: Another solution is to remove extra buttons and label up button as 'To rooftop' and bottom button as 'To garage'.
Comment: Best one so far
Comment: it's a mockup! use your imagination
Answer: The heart of the problem is that people going to every floor except the roof & basement will on average get better service by pressing both buttons. Any modification needs to remove that incentive, or remove the ability of inappropriate users to "double call".
For the floors other than lobby, I would make the selectors mutually exclusive: pressing a call button for elevator 1 cancels the other call (if any) and disables the other call button until elevator 1 arrives. You want to make your trip slower by calling E1, go right ahead...
If there are busy times when lots of people leave a floor at the same time, there might be a need to relax the mutual exclusion rule. One way would be to cancel both calls when either elevator leaves a floor, unless the other call button has been pressed since it arrived. I would have the other button start blinking to warn people that it's about to cancel.
For the lobby there are several approaches.
One possible approach would be for elevator 1 to always go directly to the rooftop or basement directly, and only stop on other floors on the return. Other users would quickly learn that it's not in their interest to use that elevator.
Another would be installing a destination floor selector in the lobby, plus buttons for "wheelchair" and "freight". Elevator companies are notorious for charging excessively for trivial things, but the software logic is simple enough, and could be implemented as an after-market kit that simulates button presses within the elevator. (I suggest leaving the buttons inside the elevator in case the software screws up, but put them inside an alarmed cupboard to discourage people from using them.)
If you are in a jurisdiction that makes it difficult for "amateurs" to modify an elevator system, but where you have a centralized locking system then that could be used to enforce the elevator allocation without modifying the elevator system itself: instead of call buttons, the person taps their card in the lobby, and the system tells them which elevator will next take them to their home floor. If they get into the wrong elevator, their card simply won't work. There's a small chance of a sub-optimal outcome where someone doesn't want to go to their home floor. And in the short term, people may try to game the system by pressing "freight" until they realize their waiting time for an elevator is worse on average. It might be helpful to have separate card readers for calling "up" and "down" elevators.
(Other solutions that partially alter the UI have merit, but neglect wheelchair users' need for the extra space in elevator 1.)
Directing people to specific elevators also makes it easier to enforce elevator passenger limits, particularly when a town is in a Covid-19 lock-down. Tapping a card rather than pushing a button is also a hygiene measure.
Comment: How does a "card operated" system deal with lost or forgotten cards, visitors without cards, etc? (For example a group of residents all leave together using only one card to call the elevator, but when returning separately some of them discover they forgot to bring their own card)
Comment: This can still be abused slightly (source: office I worked in). Since the special elevator will prioritize calls that can only be serviced by the special one, if most people are only using the regular call panel, then using the special one will still get you an elevator more quickly. In a perfect knowledge situation where people always chose which one was fastest, this would average out anyway to make the special one the same as the others. But without perfect knowledge, people do weird things--probably some will always use the regular panel, and some always the special one, regardless.
Comment: @alephzero I'm not suggesting that such a system be installed where it doesn't already exist; when I said "_where you have a centralized locking system_", I mean you _already_ have such a system.
Comment: @user3067860 If people can game the system by calling the "dedicated" elevator, then the prioritisation is too strong. It should be tuned so that it gives slightly worse than average times for everyone using it, roughly in proportion to the number of extra floors it needs to traverse. Remember that the point is to improve trip times by removing vacant stops.
Comment: @MartinKealey Machine learning elevator, perhaps? I don't think elevators really support that much logic--at least not the garden variety elevator for mid-rise buildings. Who is even going to gather statistics to decide what the average wait time is?
Comment: @user3067860 Yes some people may habitually use the "wrong" buttons, but the purpose of this exercise is primarily to remove redundant stops on floors where there is nobody to pick up. That's almost entirely caused by the call buttons in the residential floors, not in the lobby. And I specified that the buttons on those floors would be mutually exclusive, so pressing both call buttons will only bring one elevator.
Comment: @MartinKealey By making them generally mutually exclusive you make it so that people who actually need the special elevator may have to wait an extraordinarily long time (if someone else is waiting who would rather get "any" elevator more quickly, it could become quite bloody). If you always override the non-special one with the special one when the special one is requested then the special one is back to being extremely slow. I suspect there's some form of Braess's paradox coming into play here: https://en.wikipedia.org/wiki/Braess%27s_paradox
Comment: @user3067860 That's an interesting point, but I would argue that the original scenario is a form of Braess's paradox. "Fair" (minimise worst case) and "optimal" (minimise the aggregate and therefore the mean) are contradictory goals; pick one. I have given multiple answers to this problem; perhaps one of the others better addresses your concerns.
Answer: I think this is especially tough because the combination of these issues:

E1 is the only way to access the roof and garage
E1 is the main intended elevator for for wheelchairs/strollers/accessibility
E1 is associated with panel A AND panel B

I'm going to assume that most users already have some way of knowing (existing labeling?) that E1 is the appropriate elevator for roof access or accessibility.
So looking at the main question...

How can residents be guided to use the special panel ("A") as intended (only when intending to ride elevator #1)?

A couple options with the goal of discouraging users from pressing panel A unless they need elevator #1, while not causing confusion if elevator #1 opens when panel B is pressed:
The nudge
Make Panel "A" more clearly associated with only elevator #1:
<code>          1               2                 3               4
    +-----+-----+   +-----+-----+     +-----+-----+   +-----+-----+
   A|     |     |   |     |     |  B  |     |     |   |     |     |
  +-|     |     |   |     |     | +-+ |     |     |   |     |     |
  | |     |     |   |     |     | | | |     |     |   |     |     |
  | |     |     |   |     |     | | | |     |     |   |     |     |
  +-|     |     |   |     |     | +-+ |     |     |   |     |     |
    |     |     |   |     |     |     |     |     |   |     |     |
    |     |     |   |     |     |     |     |     |   |     |     |
    +-----+-----+   +-----+-----+     +-----+-----+   +-----+-----+

</code>
The colors
(I'd have made diagonal stripes but who has the time)
Comment: My thought is that making panel A "special" would add a block to the mental flow of using panel A, resulting in (1) reduced unconscious use of both panels just because a user is in a hurry, and (2) reduced "selfish"/conscious use of panel A due to having that slight extra block of "this looks different from the rest"
Comment: I like your answer, it's good UX and design. The OP's users already know the left panel is elevator 1 only though, so how do you expect your suggestion to change their behaviour?
Comment: Very nice. Perhaps especially so if it had a disabled icon on it somewhere too.
Answer: Solution1
No hardware modification required. Just add two software rules:

full priority to the destination floor selected inside the elevator 1 when at the garage level or at the roof level
full priority to the elevator call buttons at the garage level and the roof level

This way the elevator 1 will not be affected by people pressing both buttons on all the other floors
Solution2
Have this:
Comment: I like your first suggestion very much. Also like the panel design but what I am missing there is something that discourages people from pressing Panel A if they do not need it. (however your solution 1 may be enough to discourage the frequent users, but not the new users).
Comment: I really love Solution 1. It's a very elegant solution. However, it does become a problem for wheelchair users on other floors: they'd end up waiting forever to get anywhere.
Answer: Many of the proposed solutions involve combining the panels or relabeling Elevator 1's controls. The problem with this is accessibility: anyone who needs the larger car (especially if they are not tenants -- visitors or delivery people mostly) may not understand they have to use that panel to get Elevator 1 if their destination isn't one of the specially-marked destinations.
Instead, I propose putting a giant blue-and-white wheelchair sign above the left panel (ideally with braille at the bottom, or below the panel):

Possibly include signage stating "ELEVATOR 1 ONLY", as well as signage above the center panel stating "ELEVATORS 1-4", so more astute users will realize the center panel can summon the first elevator as well.
This should be a clear indicator to disabled users (and stroller users and delivery people) that this car is a larger-capacity car better suited to their needs, while (at least hopefully) discouraging casual usage of the panel by people who are going to use the main panel anyways.
Comment: I think you'd also need a small sign by panel B saying "For roof and garage, use elevator 1"
Comment: Ultimately, user behavior modification is what we have to rely on. Short of having the elevator panel staffed by someone who can say "oh this person has a walker, they need panel A; this person wants to go to the garage, they need panel A; this person doesn't need any accommodations, we can use panel B"... you're not going to be able to *make* people stop using panel A when panel B would serve them just fine; the best you can do is discourage it.
Comment: Hmm... Although a parking area specifically designed for disabled people (sometimes) discourage casual usage, I think a totally normal but roomy elevator with that sign might not work so well, though it would definitely allow concerned people to quickly understand that this is the way. Mostly speculation though.
Answer: I think the functionality of the elevators and two panels are fine. The issue is with user behavior.
You have two sets of users:

Users who are in a wheelchair or want to go to roof or basement.
Users not in set 1. ie. non-wheelchair users who want to go to general floors.

For each set of users, we want to encourage and discourage a certain behavior.

For these users, we want to encourage them to use (special) panel A and discourage them from using panel B.
For these users, we want to encourage them to use (general) panel B and discourage them from using panel A.

Note that we will allow both users 1. and 2. to use the elevators simultaneously. Both panels will be used, but at the same time, both special and general elevators that get called down will be used by users 1. and users 2., respectively. We want to avoid the case where a user calls down an elevator and abandons it.
Design:
First, we can put a simple sign on top of each panel. panel B will have a sign "TO 1-N", where N is the topmost non-roof floor. panel A will have "TO B-ROOF <code><wheelchair symbol></code>". These signs are just to give a general idea and may be vague to the user. But we will try to reinforce/punish to get a certain behavior out of them.
To encourage users 2. to use panel B, we will put it closer to the entrance. There will also be a chance that panel B calls down the special elevator and that would also encourage users 2. to only use panel B as they would see that there is no need to use both panels.
To discourage users 2. from using panel A, we will put it a little farther off from the entrance. Not too far so that it would inconvenience users 1., but far enough that users 2. will be too lazy to walk the few extra steps.
The idea is that a user sees panel B before panel A. They have to actively decide to press panel A in addition to panel B by walking extra steps.
Having panel A come up first is bad because it leads to users accidentally using panel A. They would see panel A first and use it. Even if they go and correct their action by using panel B, they can't cancel their mistaken use of panel A.
We already encourage users 1. to use panel A since it is the only elevator that can go to the special floors and accommodate wheelchairs.
We discourage users 1. from using panel B because they might get 3/4 wrong elevators. If they are on a wheelchair, they will find out that there is not enough space. If they want to go to the roof or basement, they will find out the buttons for those floors are missing.
In addition to all of this, we can put up a sign with a few sentences on elevator etiquette for those that are not too lazy to read. They can help spread the word. For example, if a person sees a wheelchair user waiting for a panel B elevator, he can kindly tell the wheelchair user to use panel A.
Comment: This is one of the few answers I've seen here that actually considers users who need the first elevator for something other than roof/garage access. I think perhaps combined with my answer (put a large "disabled" placard above panel A) this might be the best solution.
Comment: Maybe have panel A require a key or card to use. Then no one wants to dig out a card instead of press the panel B button.
Comment: Thanks for the recognition. Yes, I was specifically trying to utilize the first elevator to improve efficiency. We don't want an elevator sitting around when there are no group 1. users. I like your idea. I actually typed `` in my original answer, but it didn't show up. I guess it was an escape sequence. I edited my answer now.
Comment: That's a good idea. They can just reuse their apartment key/card, so we don't have to pass out any special key/card. As long as we don't mind preventing people without cards from using panel A.
Comment: Hello! Can you clarify what you mean by "There will also be a chance that panel B calls down the special elevator"? Thank you!
Comment: Hey Pedro. In the question, OP said "the one in the center of the bank (panel "B") can call any of the four elevators, while the buttons on the panel next to elevator 1 (panel "A") specifically call only elevator 1". I think this is for efficiency purposes, because group 2. users don't care which elevator they use.
Answer: Current system:

Panel "A" - Calls elevator 1
Panel "B" - Calls elevators 1-4
Panel "A+B" - May end up calling two elevators

Below are 2 proposed fixes, intended to be used at the same time.
Fix 1:

If a user pushes any button on any panel, the corresponding light will turn on.
If a user pushes a direction on panel "A", it will silently cancel that direction on panel "B" (the light on panel "B" will remain on).
If a user pushes a direction on panel "B" while panel "A" is active, it will silently be ignored (the light on panel "B" will still turn on).

This has a few effects:

If multiple people want to use an elevator, only one elevator will be sent.
Users will learn (or be told) using both panels is slower (i.e., because if elevator 1 is in use, elevators 2-4 won't arrive).  If they do so anyways, they're only hurting themselves.
If a user is fine with any elevator but someone else wants elevator 1, they'll be penalized.  This is mitigated by fix 2, since having multiple people request an elevator at once is more common in the lobby.

Users can still game the system by pushing the wrong direction and hoping an empty elevator shows up.
Fix 2:
Set elevator 1 to rest in the lobby when not in use.
This has a few effects:

Optimizes delivery of freight/packages (freight typically only goes in one direction; the delivery person can go down on any elevator).
The lobby will tend to call an elevator faster.

Notes:
The people who know/care/understand the current system should already realize that pushing both panels is not necessarily faster, since panel B already calls elevators 1-4.  The goal of this solution is not to penalize people who abuse the system.  Rather, the intent here is to ensure that people who use both panels don't slow down the elevators for everyone else (i.e., by using 2 elevators when they only need 1).
Comment: I like fix #1.  Another addition may be to add presence detectors to the elevator lobby so that calls will get canceled if everyone who was there, leaves.
Answer: <code>Elevator1   Elevator2   Elevator3   Elevator4
~4 min      ~1 min      ~3 min      ~3 min
            >CALLED<
</code>
The problem seems to be people believing they get a benefit out of pressing both buttons, when in fact they will not. I think this can be addressed by communicating the state of things more clearly. By displaying an estimated waiting time for each elevator (calculated by distance and requested stops on the way) the users will clearly see the fastest option is reserved for them after Pressing Panel B.
The estimated times are always displayed - so this will encourage people to use Panel B if one of the three Elevators displays the smallest estimated waiting time. And if Elevator 1 has the smallest waiting time it does not matter if they press B or A.
This solution could be quite costly to retrofit on your building, but I think it could solve the problem quite nicely by informing the users.
Answer: I'd put a timer / a usage sensor in the circuits for Elevator 1 during peak periods, so once its been called it will always go directly to the set destination ( the roof or the basement )
Anything to do with trying to get users to modify their pattern of behaviour is going to be too complex.
EDIT: this doesn't address the disabled usage issue which I couldn't resolve.  Of all the answers and comments to the Question, a comment by Supercat is the simplest solution which cracks both problems.
Comment: This will make elevator 1 the express elevator. Everyone will want to use the express elevator if possible. This will actually worsen the problem, by making elevator 1 more desirable an less available, increasing congestion.
Comment: I don't think modifying user usage pattern is "complex", but that it just doesn't work. People do random stuff.
Comment: I think this will reduce the amount of time you spend waiting while *on the elevator* but increases the amount of time you wait *for* the elevator by almost the same amount. The last person to call Elevator 1 still has to wait for it to visit every other call before reaching their destination, plus all the round trips that wouldn't otherwise be needed. They just wait outside the elevator instead of inside. It'll prevent someone from waiting due to a call that came in after they board, but at the cost of increasing wait time for whoever made that call.
Comment: The problem is, how is a disabled user (or delivery person, or stroller user, etc) going to get to the third floor?
Comment: Agreed, what I wrote initially doesn't solve the disabled issue.
Answer: How about:

Make panel B light up the buttons on both panels, summon any elevator, and have both go out when any elevator answers.

Make panel A light up only panel A, and summon only elevator 1.

Make elevator 1 responding to a panel A summons or use NOT respond to panel B summons.  This mode would probably end when either the elevator is closed and not directed, or when it reaches the end of travel and turns around.

The fact that panel A doesn't get all the elevators but panel B does should filter through to most people over time.
The one problem with this is that some people will work out that they can get an express elevator... so you might need a key or password system to discourage this.
Comment: The problem is, if someone who *needs* elevator 1 approaches and the button is lit, they may assume *that* elevator has already been summoned, and not press anything.

Perhaps make it blink, or light up in a color, unless it's been explicitly pressed?
Comment: How about having one set of call buttons with a sign "Push and hold for handicapped or roof access", and a light to indicate when that was selected.  Selecting handicapped/roof access would indicate that only elevator 1 should stop at the floor.  Otherwise whichever elevator was closest (which might happen to be #1) would be dispatched.
Comment: @DoktorJ The psychology of elevators is that you press the button, even if it is already lit.  Someone who needs elevator 1 will push the panel A button even if it is already lit, thus requesting elevator 1 in addition to the current panel B request.
Comment: @DavidG. if a UPS delivery person or a visitor with a walker comes in, how are they going to just "know" they're supposed to push the button on panel A when it's already lit? A lit button is well-known elevator UX for "this button has already been selected"
Comment: I think Supercat has it:  the only way to stop people pushing 2 buttons is to have one (modal) button.  The default mode calls any elevator.  And to switch to disabled mode is just a long press.
Answer: I'm going to add yet another option, to address a separate aspect of the problem. (If you think this doesn't cover something, please read my other two answers before commenting to that effect.)
Part of the reason people hit both call buttons is because they can and without thinking.
Even if the buttons have different labels, they have the same affordance, requiring the same arm & hand movement, and are just a few seconds apart as one walks along the corridor.
I would fix this by changing one of the pairs of call buttons to something that requires a different physical action; for example:

a lever that you raise or lower against a pneumatic arrestor so that it takes 2 seconds to move the lever far enough; or
a knob that you rotate 60°, with a speed limiter (about 5 rpm or 30°/s) so you can't simply spin it; or
a kick-plate at knee level that you have to hold for 2 seconds; or
two pressure pads on the floor, each 250mm wide and 550mm apart, that you have stand on simultaneously (or park your wheels on); or
a smart pressure mat that recognizes the difference between rolling and stepping;
or even just a button that you have to hold for 5 seconds.

There are lots of options, but the important part is that you want something that you cannot activate while continuing to walk, and which requires a different muscular action from tapping the regular buttons (a long hold is sufficiently different from a sharp tap for this purpose).
Of course this won't be perfect, but the mental discordance of having to take two actions with a bodily stop should encourage most people to think about what they're doing and why.
Answer:
It is also slightly larger in size than the other 3 elevators, to
accommodate wheelchair-using residents and strollers.

Based on the above statement (emphasis on slightly is mine) I take it that the other three elevators can be used by wheelchair-using residents and strollers.
So, on floors other than rooftop and basement, we can dedicate elevator 1 for travel to rooftop and basement only by the panel A having "rooftop" and "basement" buttons only. The internal panel in elevator A should have buttons for all floors (more on this later) but only the "rooftop" and "basement" buttons must be enabled. The only way someone can exit the lift in an intermediate floor is when someone else is entering in that floor (which is why it stops there) but this is more a matter of chance than choice.
On the rooftop & basement floors, however, the panel A can have only one button: "down" and "up" respectively. Additionally, once the lift stops in the rooftop or basement floor, all floor buttons must be enabled on the inside panel, but the intermediate floor buttons must be disabled once the lift stops at one of the intermediate floors (because someone else is entering there).
This way, only users entering from one of the dedicated floors will get to exit at the floor of their choice. The other users (entering at intermediate floors) have the choice to exit at rooftop or basement only (they already made that choice while pressing the respective button on panel A, so there's nothing to complain).
Comment: A user could call elevator 1, ride it to either end of its' range of travel, and then push the internal button for their correct floor. Slower than the direct route the other elevators can take, but if those are crowded, it's a viable option.
Comment: @Psychemaster yes, that thought occurred to me. But as you said, that may happen only when the other three elevators are crowded. It is somewhat similar to people entering an elevator in the reverse direction just so that they can exit at their intended floor on the way back (and beyond) - when it's overcrowded while travelling in the intended direction.
Comment: Your assumption is likely incorrect in that this "slight" width increase may be the difference between a 36" door that comfortably accommodates a person rolling themselves in in a wheelchair and a 32" door that they'd scrape their knuckles on wheeling in and out.
Answer: Key-switches. Replace the call buttons with key-switches at all levels except Garage, Lobby and Roof. Yes, there's a loophole, in that people can summon it to the lobby and use it as a normal elevator to ascend to any floor. But it won't be stopping empty at all intermediate floors unless somebody with the appropriate key called it there.  You could prevent that by also using key-switches inside the elevator car for all floors except these three.
Answer: I propose disconnecting the panel B from elevator 1. This would at least reduce the duplicated floors from panel B.

When there are a lot of people waiting, as a common user I would most
likely see that both panels are pressed and has higher chance of
using elevator 2,3,4
In the minor case of going to the rooftop, basement and using the
wheelchair. I would be directed to elevator 1 (either by a sign or
visual cues). Since more people will be using the other 3 elevator,
elevator A might have empty space.
At this point elevator A users can:

Skip the empty pressed floors, as there are less people.
If there are people in elevator A actually need to go to the floors in between, I would say they have the fair travel time as everyone else in the elevator. In case there are wheelchair users, they may negotiate with others to go to their floor first.
Comment: I suspect this will only exacerbate the issue that people press the buttons on both panels: "Why wait for one of three elevators to not be busy, when I could wait for one of four?"
Answer: 2 separate answers:

My building has a similar set of elevators.  The #1 elevator is on the north side of the building and the #2-4 elevators are on the south side.  No one presses all 4 buttons.
I recall a building I visited that charged $0.10 for using the elevator.  If there was a per call charge - even a nominal amount - then people would probably stop doing that.  I think you would have to make trips to the ground floor free, but you could charge for other trips.  It seems like you could package charging and requesting into a mobile app so no one would have to touch the elevator controls.  I would be happy to pay a small fee to never again have to push elevator buttons.
Comment: Adding an accessible elevator in a separate location can make people who need it feel segregated and "othered". Often times those are in less-convenient locations, and they're used for freight, so generally they're not as nice to be in.
Comment: @Izquierdo I agree.  To be clear in my building all elevators are fully accessible.  The north elevator is the freight elevator and does not service the two garage floors.  If we need to take something heavy to the garage we can drive it in a truck.  But if the elevators were all in a central location we would have the same problem.  Some people want to go to the lobby (any elevator will do) and others want to go to the garage (only some elevators) so there would have to be two separate controls.
Answer: If any solution goes
Make all four elevators equal in size and floors they attend. Then you only need a single button and everyone will be treated equally.
More realistic
Similar to a disabled toilet, which we'd all use if it's free and no other toilets are available, you would refrain if there was a disabled person inside or in line.
If you can find a way to indicate on every floor that elevator 1 is being used for roof, garage or disabled access, you would have more chance to discourage people from pressing the button.
Answer: Is it really necessary to take Elevator 1 directly from any floor if your eventual destination is the carpark or rooftop?
What about simply changing elevators on the ground or top floor? So there's no "call rooftop" or "call carpark" buttons on the floors.
Instead every elevator has "carpark" and "rooftop" buttons, but if it doesn't actually go there, the system will instead arrange a rendezvous with elevator 1 on any suitable floor - either one that both elevators are already going to stop at, otherwise the last reachable floor in that direction of travel.
And play an announcement "For access to the carpark please disembark on this floor and transfer to elevator 1".
A back-of-the-envelope calculation suggests that this might actually be the faster way to get to the carpark or roottop on average, assuming the building has at least 4× as many floors as elevators.
In a sufficiently tall building, this would also be the fastest way to get between floors generally.
(Of course, the "disability" access buttons would still call elevator 1, but now they could be signposted as exclusively for that purpose.)
(edit)
Footnote: to make this a near-optimal solution, the system would need to schedule the elevators so that there's at least one running in the same direction as elevator 1 slightly before it. By which I mean, short enough that a fast person transferring would find elevator 1 arriving just as they step up to it, and long enough that a slow person transferring would get to elevator 1 before it decides to depart, and that minimal additional waiting time would be required.
Also, you would want to block the "close door" button in E1 while it's waiting for people to transfer.
(edit2) Clarification:
There's only 2 ordinary call buttons on each floor ("up" and "down"), and the "wheelchair" call buttons won't bring you an "extra" elevator. Rather, if you press one of those, you'll wait until either the larger elevator #1 is available, or an empty normal elevator is available. So you'll wait longer, but since the normal elevators can only take 1 wheelchair, you'll get an express ride when it does arrive. If you get elevator #1 then it might stop for other passengers, but fewer.
Comment: Interesting idea, but this doesn't help the root problem that Elevator 1 will very often need to stop unnecessarily at floors that have already been served by Elevators 2-4. This change won't result in people pressing the Elevator 1 button any less than they do now, so you'll usually have a long wait to go the last floor. You could make Elevator 1 go directly to the top/bottom when Roof or Garage are pressed in the other elevators, but that'll be very weird behavior for anyone else on Elevator 1 who's not going to the Roof or Garage.
Comment: @NuclearHoagie Sorry, I should have made clearer, there's only 2 call buttons on each floor, "up" and "down".
Answer: I suspect that the other difference elevator one has is that its load limit is 1000 pounds greater than the other three.  (There should be a small plaque somewhere, or a notation on the certificate.)
In short, it is the freight elevator.
Large deliveries, movers, etc use this elevator (and usually get the key to lock it out).  The loading dock is in the garage, so it must go down that far.  Similarly, rooftop deliveries require it go to the roof.
I suspect that the real failure in the UX is that there should not even be panel A.  Panel B should call all elevators any time, and any elevator not locked out will answer.
When a large deliver occurs, they will get the key and call elevator 1 from either the loading dock, a special call button in the office, or a key switch on the office level.  (Failing that, one can keep calling elevators and sending the wrong ones away until the freight elevator shows up.)
Comment: Panel A is needed if you want to go to the roof.  Without Panel A, I guess you would just keep summoning elevators until you get the one you needed.
Comment: Unless it's a large commercial facility that receives many deliveries (this was not my impression), all the carriers (DHL, FedEx, UPS, Amazon, USPS) are not going to be willing to add an extra key to every driver's ring on that route. Additionally, visitors with disabilities would be locked out of the very elevator that's intended for their use.
Comment: @emory I seem to recall living in such a building.  If one wanted the rooftop pool, one did a normal call button, and if you didn't get the special elevator, took the stairs the last level.
Comment: For clarity: there is a freight/service elevator physically separate from these four residential elevators that is used for "freight"/etc. purposes. None of the four described above are "freight" elevators in name or practice.
Comment: @DoktorJ  I think it is more likely that the carriers you refer to will just leave stuff in the office.  I can't see them visiting a dozen floors to place 30 packages in the hallways.  Can you?   The large deliveries I was referring to is somebody getting a bed, or a soft and chairs.  Large bulky objects.  These delivery people will check in at the office, and can borrow a key, or even be escorted (by the resident if nothing else).
Comment: @esqew, "name" is what you call it.  "practice" is how you use it.  Neither is how it was built.  If it has a larger load capacity, then it is a freight elevator just not used as such any more.  And that would have influenced the original wiring of buttons.
Comment: The building's original construction included the fifth freight elevator, and building rules/regulations prohibit the use of any of the four residential elevators for moving bulky materials or use by contractors/delivery persons to prevent damage to the cab and prevent any logjams that'd be introduced by taking one of the four out of service. Unfortunately the weight ratings are not posted in the cab and are likely on a certificate available in the manager's office, which I've never seen; as such I can't really say whether or not your assumption is correct or otherwise.
Comment: @DavidG. alternatively you could call the elevator and if you don't get the one you want dispatch it to the basement, step out before the door closes, and repeat the process until you get what you want.  Isn't that you would do if you were in a wheelchair?
Comment: @DavidG that still doesn't address disabled visitors, especially if they are visiting a disabled resident. Unless the office is staffed 24/7, being escorted isn't an option -- besides othering and demeaning said visitors in the first place.
Comment: @DoktorJ  While OP presented his view as to why one elevator is slightly larger, I suspect that all four elevators can accomedate a wheelchair or *two* without difficulty.  The only place you need to do anything special is to get beyond the range of the other three.  If nothing else, you ride one of them to the end, get out, and press the call button to go further in that direction.   (Now, if you have a "disabled" traveling in a 3000 pound device, things would be different.  I find this unlikely.)
Answer: Have only one panel (or 2 or more panels with same functionality) and buttons:
<code>ROOF
UP
DOWN
BASEMENT
WHEELCHAIR
</code>
Using appropriate symbols (see other answers).
All elevators are numbered and elevator 1 marked with symbols for wheelchair, basement and roof (on the door and the floor directly below it - so as not to get confused with the panels).
Only if roof, basement or wheelchair is pressed, will evelevator 1 stop. Otherwise elevator 2, 3 or 4 stops.
Additionally, people with wheelchairs who live or work in the building get access to the extra service elevator.

Apart from that (and slightly off-topic): Walking and climbing stairs is healthy. Encourage people to use the stairs.
Using stairs instead of elevator may effectively save time, especially if you compare it with time wasted waiting for and standing in elevator and time wasted sitting in the car and driving to the gym where you get your workout on a stepper. Absurdistan.
This will free the elevator for people who actually need it.
Answer: Building on @eskew 's excellent answer, as long as privacy is not a concern, why not simply move the full floor selector panel entirely to the outside of the elevator, instead of having multiple directional buttons on the outside and floor buttons on the inside? That would reduce input to a single interaction.
Pros:

Every panel on every floor would have every floor being stopped at illuminated. If yours is already illuminated, you immediately know an elevator is already on the way, and you may not need to touch the panel at all.

There's no way to "game" the system by pressing both sets of buttons, potentially reducing wasted energy of having two elevators show up unnecessarily. The computer will automatically bring any closest bay to your floor.

Cons:

Privacy could be a big concern. In case you don't want that creepy dude behind you knowing which floor you're going to, there's not really any way to hide which floor you selected. Then again, he may just as well jump in the bay with you regardless of how the elevator is designed.

I guess you'll also need a panel on the inside, because Forgetful Joe will invariably forget which floor he needs to go to, or which level he parked on.

If a special elevator is required, you would still need some sort of way to request that one specifically. Perhaps with a specialized button to call for that one specifically.
Comment: This is a good idea, but say there is a large crowd in the lobby waiting to go to multiple floors and I want to go to the 45th floor.  Nearly simultaneously a bunch of elevators arrive.  How will I know which elevator to enter?  I assume one has been pre-assigned to service my request and the others not.
Comment: Great observation @emory! What if we put the bay number on the button of the floor you choose. So there would be a hard number next to the button for the floor like usual, but on the face of the button, it would show the bay number of the elevator going to that floor. If there's a duplicate panel on the inside still, you could always hit the floor button there also in case you discover that you've accidentally walked into the wrong bay.
Comment: The hotel I'm staying at has an external floor selector. When you select a floor, it'll confirm your floor selection and assign you an elevator. The side of the elevator has all stops listed, so you can double check your floor when boarding. The inside panel only contains emergency buttons. These elevators integrate with RFID room keys. Perhaps it would be possible to save a "home floor" and disability preference on your key so that that buttons wouldn't be needed for normal operations (you could have quick selects for parking/rooftop, etc. and a full floor list buried a bit deeper).
Answer: This cannot just be solved with UX as your users already know.   If you kicked everyone in the building out, then some of the other answers would work for sure.   To alter your knowledgeable users you need to change the UX and the functionality and reprogram them.
My suggestion is a little bit simplistic.
It would include a brief bulletin or plaque outside the elevator saying the elevator's priority is servicing roof, garage, and handicap access.
In the elevator (most have this ability) you would need one button turned to a handicap button.   This would allow someone in a wheelchair to press the button and then their floor.
Here is the special part.   You have elevator 1 reprogrammed to give absolute priority to the handicap floors, roof, and garage.    So if I come on the elevator and press floor 12 and we are on floor 3, and then another person gets on after and presses "Roof"... we go to the roof.
And if someone gets on, on the roof and presses "Garage", it then goes to the garage, even though it has passed floor 12 twice!   If this happens to a person 1-2 times they will surely never get on that elevator again unless it is for intended use.
We have done this similar arrange for our "moving/freight" elevators.
The catch - anyone could press the handicap button then their floor.  I don't really see this as an issue as most people would be embarrassed to do this.   Also if it were referenced that the elevators were monitored I would think it would discourage almost everyone.
Comment: Looking at the many possible solutions, I think "this cannot be solved with UX" is wrong. The problem is that the users DON'T KNOW that their behavior brings them no benefit, they believe it helps, like pressing the tv remote buttons really hard, or pressing a button a hundred times to make the elevator come faster. And this can in fact be addressed by UX.


Knockout js: Viewmodel property not being bound for dropdown

Question: This is my fiddle. http://jsfiddle.net/aaScC/8/
Please check in the example, the Score property has 3 value but it is not being displayed . I know the score property is bound to dropdown value so its coming.
But I want 3.00 to be displayed.
var GoalsModel = function (goals) {
   var self = this;
   self.goals = ko.observableArray(ko.utils.arrayMap(goals, function (goal) {
       return new Goal(goal)
   }));
};

Comment: When I look at the fiddle I see 2 goals with 3.00 displayed. Could you be more specific about what you actually want? Thanks for the fiddle though.
Comment: @scaryman Please check the row with text "Goal1-1-1" which does not have rating. I want that row to have rating. Thanks for the comment.
Answer: you data has this line
        "GoalTitle": "Goal1-1-1",
        "GoalDescription": "",
        "HasSubgoals": false,
        "Score": 3

and your template has this line

If you want the score to display always just remove the visible binding.


c++/cli wrapper for variable of native smart-pointer class

Question: I'm new to C# and C++/CLI and not quite familiar with them. I searched but couldn't find an existing solution for a pretty simple thing (which I suppose should be common).
I am writing a simple C++/CLI project (a wrapper to C++ native dlls to be used in C#). There are many examples how to write a wrapper for native class:
class CNativeClass {
    CNativeClass() {}
    void Foo() {}
}

public ref class CNativeClassWrapper {
public:
    CNativeClassWrapper() {
        _Wrapper = new CNativeClass;
    }
    ~CNativeClassWrapper() {
        this->!CNativeClassWrapper();
    }
    !CNativeClassWrapper() {
        delete _Wrapper;
        _Wrapper = nullptr;
    }
    void Foo() {
        _Wrapper->Foo();
    }
private:
    CNativeClass* _Wrapper;
}

This is simlified example code. There may be more native classes, there may be late initialization... A lot minor but necessary code.
Is there any wrapper for variable of native class which hides all these details?
Like smart pointer templates in pure C++.
Moreover,
if a native class is actually a smart pointer (90% of my cases, we use boost::shared_ptr<>) the code becomes a mess:

check can be if ( _Wrapper ) or if ( *_Wrapper ) or even if ( _Wrapper && *_Wrapper ),
access to methods (*_Wrapper)->Foo();,
how to reset? both (*_Wrapper).reset(); and _Wrapper->reset(); are correct but it is too confusing.

Does anybody know a solution for this?
Comment: Smart pointers are about as useful as a chocolate teapot in interop.  The wrapper code is very boilerplate, you can auto-generate it with a tool like swig.
Answer: Well, I have finally come to such wrapper classes:

for holding general native classes:
template <class T>
public ref class native_auto_ptr
{
public:
    native_auto_ptr()
    {
        _pNative = new T;
    }
    native_auto_ptr(const native_auto_ptr<T>% rhs)
    {
        _pNative = new T( *rhs._pNative );
    }
    ~native_auto_ptr()
    {
        reset();
    }
    void reset()
    {
        delete _pNative;
        _pNative = nullptr;
    }
    T* ptr()
    {
        return _pNative;
    }
    T* operator->()
    {
        return _pNative;
    }
    operator bool()
    {
        return _pNative;
    }
    void operator=(const native_auto_ptr<T>% rhs)
    {
        *_pNative = *rhs._pNative;
    }
    void operator=(const T% rhs)
    {
        *_pNative = rhs;
    }
protected:
    !native_auto_ptr()
    {
        reset();
    }
private:
    T* _pNative;
};

for holding shared_ptr<>:
template <class T>
public ref class native_shared_ptr
{
public:
    native_shared_ptr()
    {
        _spNative = new boost::shared_ptr<T>;
    }
    native_shared_ptr(const native_shared_ptr<T>% rhs)
    {
        _spNative = new boost::shared_ptr<T>;
        *this = rhs;
    }
    native_shared_ptr(const boost::shared_ptr<T>% rhs)
    {
        _spNative = new boost::shared_ptr<T>( rhs );
    }
    ~native_shared_ptr()
    {
        reset();
    }
    void reset()
    {
        delete _spNative;
        _spNative = nullptr;
    }
    T* operator->()
    {
        return _spNative->get();
    }
    operator bool()
    {
        return _spNative && *_spNative;
    }
    void operator=(const native_shared_ptr<T>% rhs)
    {
        *_spNative = *rhs._spNative;
    }
    void operator=(const boost::shared_ptr<T>% rhs)
    {
        *_spNative = rhs;
    }
protected:
    !native_shared_ptr()
    {
        reset();
    }
private:
    boost::shared_ptr<T>* _spNative;
};

I am quite happy :)

They hide new/delete jobs.
They are safe.
Their syntax is close to common smart-pointer, which is convenient.

The only issue is with the ctors with parameters... (TBD)
Answer: I don't think there is a build-in class shipped with the C++/CLI framework, but you can easily design your own.
Take a look at this question: auto_ptr or shared_ptr equivalent in managed C++/CLI classes
I would not use smart pointers. The managed wrapper to the native object will take care of releasing the native object when the containing managed class is disposed or finalized.


Number of strictly increasing and decreasing 4 digit numbers?

Question: I have two questions:
(a) Count the 4 digit numbers whose digits decrease strictly from left to right and;
(b) Count the 4 digit numbers whose digits increase strictly from left to right
I have the answers which are $10 \choose 4$ and $9 \choose 4$ respectively. Can someone explain how to come to these answer? The number of ways to choose 4 elements of 10 or 9 respectively seems to simplistic.
Answer: Hint:  If you pick any four distinct numbers from the set $\{0,1,2,3,4,5,6,7,8,9\}$, there is one and only one way to arrange them so that they are in decreasing order.
For the numbers whose digits are in increasing order, simply observe that the leftmost (most significant, leading) digit cannot be zero.
Comment: Right, I see now, this makes sense. Obviously my problem was not being able to see the simple fact that there is only one way to arrange the number in decreasing order. Thanks!
Answer: Shouldn't the answer be 9C4 + 9C3 for question a and 9C4 for question b ?
Case 1. The first term cannot be zero of a number of format "abcd".
So we have 9 choices.
9C4 for either way of arrangement.
Case 2. Only the last term d can be 0. So we have 9 choices for a,b,c. 9C3 ways of arranging in strict decreasing order.
So when we have strict increasing from left to right we have 2 cases the last term being zero and none of the terms being zero. 9C3 + 9C4
When we have strict decreasing from left to right we have only 1 cases as the last term and first term can never be zero. 9C4.
Answer: (a) Since the digits must strictly decrease from left to right, there are 10C4 such numbers. For any selection of four digits from the ten digits, there is exactly one way of arranging those four digits in a strictly decreasing order from left to right. We need not worry about leading zeroes because the order is decreasing, and 0 can never be the left most digit. Hence 10C4.
(b) Here, since the digits must strictly increase from left to right, consider two sub-cases:
(b1) If 0 is not included - Then, there are 9 digits, and for every choice of 4 digits from them, we have exactly one way to arrange them in strictly increasing order. So, there are 9C4 such numbers.
(b2) If 0 is included - Then, 0 will appear as the left most digit, and this will not be a four-digit number. Therefore, there are no such numbers at all.
The answer is therefore, 9C4.
Comment: Welcome to MSE. For some basic information about writing mathematics at this site see, *e.g.*, [basic help on mathjax notation](/help/notation), [mathjax tutorial and quick reference](//math.meta.stackexchange.com/q/5020), [main meta site math tutorial](//meta.stackexchange.com/a/70559) and [equation editing how-to](//math.meta.stackexchange.com/q/1773).


Do epoxy paints need to cure after being heated in the oven?

Question: I am doing a project with a rattle can but it's an epoxy based paint (not oil like your off-the-shelf Krylon or whatever). I am also doing a step where I oven cure everything after I finish painting it. I am doing 200 degrees for 2 hours. So far my parts have turned out great, I'm really happy with them.
Do I still need to let them air cure for a few days after or are my parts ready to use now?
Comment: What sort of degrees? There are epoxies that bake at nearly 200C and are hard when they come out. 200F would be another story. What does it say on the tin?
Comment: The type of paint would help. Usually once epoxy paints are hard they are good to go.
Answer: Beware. Many products are marketed as "epoxy" when in fact they are not epoxy based, just normal paint with a small amount of already-cured epoxy in the mix, so they can make the marketing claim of being "epoxy".   Real epoxy is nothing like that.
Many paints don't like being oven baked. You may want to experiment with something unimportant.
Real epoxy comes in 2 cans. You mix them together in a mixing cup, and you have a limited "pot life" to apply it and clean the spray gun.  Which is why they can't sell it in rattle cans.

High-temp-cure epoxy absolutely requires an oven cure, but gives extremely long pot life - long enough they can sell it in one can.  I've never seen high-temp in a rattle can, but if that's what you have, awesome.  The oven schedule is mandatory - don't short it, or it won't cure.
When spraying (real) epoxy, make sure to wear a proper NIOSH respirator. The resin in uncured epoxy contains an immune system irritant, skin is a good barrier, lungs are not.  That health issue is why big-box stores don't like to sell 2-part epoxies and urethanes in products you might spray.


Detecting if the player is underwater

Question: I am in Java 1.14.4 and I'm trying to create an item that gives the player water_breathing if they are underwater, but I can't find a good way to detect if the player is fully underwater.
execute as @a at @s if block ~ ~1.6 ~ water

Problem with this command is that there could be some other block above the player's head.  There also doesn't seem to be any NBT data the player has to simply test for this.
scoreboard objectives add inWater minecraft.custom:minecraft.walk_under_water_one_cm

Doesn't work either since the player must actually be walking for this to occur.
Answer: It's fairly straightfoward to do this by exploiting the fact that, when a player is underwater, their air meter will begin decreasing, which can be measured by command blocks.
First, set up the necessary scoreboard objectives (running these commands once):
/scoreboard objectives add air air
/scoreboard objectives add difference dummy

Then, every tick, run these command blocks in order (using a repeating command block and a chain command block):
/execute as @a run scoreboard players operation @s difference -= @s air
<command goes here>
/execute as @a run scoreboard players operation @s difference = @s air

Between the two /execute commands, you can select underwater players using the selector @a[scores={difference=1..}].
This isn't 100% reliable for a few reasons, but it should work:

It fails to detect players who are underwater with a water breathing effect (which doesn't matter at all if what your command does is give players water breathing). You can detect players who gained the water breathing effect while underwater (but not players who had water breathing beforehand) with @a[scores={difference=0..},nbt=!{Air:300s}].
It fails to detect players the exact tick they take damage from drowning.
Comment: With your idea of air decreasing with the player underwater I was actually able to simplify this with: `execute as @a[nbt=!{Air:300s}] at @s unless block ~ ~1 ~ air run [...]`  Since air is kept in a player's NBT data, I didn't think scores were necessary.  Maybe this has drawbacks I haven't thought of yet, so I was looking for your thoughts.
Comment: @Hydra That doesn't work properly because the air meter takes a few seconds to recharge as of 1.13, meaning that if you emerge from the water and quickly move into a non-air non-full-block (ex, open doors), it will cause a false positive.
Comment: I didn't think of that, but I don't have any doors in my map so I think I'm fine with this simplified version.

Detecting if the player is underwater


According to JsonAPI specs, why disallow bulk updates?

Question: I quoted the notice in the ebook about Json API design. They said that

I need a detail example and an explaination of the reason why bulk updates must be forbidden.
Comment: in your quoted text is word: **may** not *must*
Answer: The text you have quoted is misleading. The specification requires a PATCH request to either "either completely replace every member of the relationship, return an appropriate error response if some resources can not be found or accessed, or return a 403 Forbidden response if complete replacement is not allowed by the server." (Source) But this is not the reason you should consider disallowing replacement of to-many relationships.
The specification lists one of the reasons you may consider to disallow it as a note:

Since full replacement (of to-many relationships) may be a very dangerous operation, a server may choose to disallow it. For example, a server may reject full replacement if it has not provided the client with the full list of associated objects, and does not want to allow deletion of records the client has not seen. (Source)

Another common issue are collisions. Lets assume clients A and B requests a resource including the full list of associated objects. If both are associating another objects and using full replacement via PATCH therefore, the second request will override the first one and therefore delete the relationship created by the first request without even knowing about it.
Updating relationship via POST and DELETE using relationship links avoids this issues. In that case the client is only modifying specific associations without touching the other ones.


What is the recommended time before a reset password link expires?

Question: I'm working on a financially leaning site and was curious — is there a standard amount of time to wait before expiring a reset password link once a user has forgotten his/hers and requested to reset it?
On the other hand, if there is no "standard" as such, how might a UX practitioner go about figuring out what would be a sensible and acceptable period for their use case?
Comment: This may be a duplicate post I think. Does this post answer any of your queries? http://ux.stackexchange.com/questions/42007/forgotten-passwords-should-the-temporary-password-expire
Comment: That Q has 4 answers addressing the 'why', none addressing the 'how much' of this question.
Answer: The closest thing to a standard that I found is the OWASP Forgot Password Cheat Sheet, which says:

no more than 20 minutes or so
Comment: [That OWASP cheat sheet](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Forgot_Password_Cheat_Sheet.md) no longer recommends 20 minutes, but rather says the link should "expire after an appropriate period".
Answer: There doesn't appear to be a standard.
https://postmarkapp.com/guides/password-reset-email-best-practices has a password email reset guide that includes this information:

Expiration information
If the link expires—and it should—include a sentence to let the
  recipient know that it expires and how long until the link expires.
  And, for convenience, include a direct link to where they can initiate
  another password reset request if the link has expired.
Well-engineered password reset processes will automatically expire or
  invalidate the password reset URL after a period of time. In some
  cases, the expiration window may be aggressive, and it's possible the
  link will expire before the recipient has an opportunity to check
  their email and reset their password. So it's important to clearly
  communicate both the fact that the link expires as well as when the
  link will expire.

I think it depends on the use case. If someone is reseting their password and wants access right then, a shorter expiration time would make sense.
If someone is sending password reset emails that may or may not be used immediately, a longer reset time would be useful to the user.
Comment: If you give the expiration information as the "time to expiry", make sure you mention when that time starts from, as emails may not always be received immediately.  E.g. "_This reset link was created at 09:34 on and will expire in 60 minutes_". Alternatively, specify the time at which it will expire ("_This reset link will expire at 10:34_"). For short durations (< 24 hours) it's probably sufficient to mention the date somewhere in the email; for longer durations, you might include the date/day of expiry more explicitly).
Comment: Great link, thanks.  The advice on avoiding the appearance of phishing was very useful, even though unrelated to the OP.
Answer: Generally when users initiate a password reset, they're actively in the process of trying to get into their account. I would set the link expiration between 30-60 minutes, and insert a message letting the user know when the link will expire and have instructions on how they can re-engage the process again if they need a new link.
However there is an approach where you could use a generic forgot password link for all users and wouldn't need to worry about link expiration at all. Since there are some security issues that arise when you provide a user specific link, you could have all users visit a forgot password page where they have to answer specific challenge and security questions before proceeding to the password reset screen. With this method you reduce the risk of a user's account being compromised if that same user's email account has also been compromised. This approach is outlined in this PDF file.
Answer: The longer is expiration time, the higher is the probability, that somebody else accesses this link. That's why the expiration time should be relative short.
Keep in mind that the Email (SMTP) server that you use may send Emails not immediately, but after some delay. Also the Email client of your user may have some delays between checking the server. So I recommend expiration time between 10 min and 1 hour.
Answer: I think 24 hours is a user-friendly (ie, convenient) time limit. It's easy to remember if you're the requesting party and it gives you plenty of time.
Comment: This answer expresses an opinion when the question asks for a standard.
Comment: The OP requested an opinion if there is no standard.  Personally I'd like a bit more explanation of the rationale behind a 24-hour window...
Answer: As someone who has done a fair bit of security compliance, I can say the answer is: ask your company's compliance officer.
Probably more important than setting the reset-window time, is ensuring your ping their SMS or other '2nd factor' when resetting.  This is important in case someone else is trying to reset to break in.   Consider that you can ping their 2nd factor (e.g. SMS) interactively, so that if they respond with 'freeze', or similar, then then you can immediately disable the password reset code.
20-minute resets are generally safe, though be mindful of whether your email deliverablity is good enough for them to get it in that window of time.
presume shorter time windows for financial logins, business SaaS, and similar critical systems. The same goes for social accounts if the account is 'high status' or the request comes from outside the normal activity profile.


How to access other module data table SugarCRM

Question: I am writing logic hook and I need to update 1 module fields by using other module elements.
<?php
class logic_hooks_class {

function after_save_method($bean, $event, $arguments) {

    if (!isset($bean->ignore_update_c)||$bean->ignore_update_c === false {

     //here I need to get module's reservations element: amount_reserved
     //should I load relationship like $bean->load_relationship('reservations'); ??
     //need to set total_reserved = amount_reserved;
     //by the way amount_reserved might have several values for one reserved

          $bean->goods = $bean->amount-$bean->total_reserved;
          $bean->ignore_update_c = true;
          $bean->save();
  }
 }
}
?>

Comment: i did not understand the problem properly , assuming that you need to update a field of module based on other module field , if that is the scenario than you can make use of this method : get_linked_beans(); in your hook , it worked for me !
Answer: You can load the beans for the relationship like this:
$bean->load_relationship('reservations');
$reservations = $bean->reservations->getBeans();

Now one can loop the $reservations and fetch and sum up the wanted value.
Just to clarify how load_relationship works. The parameter for load_relationship should be the link vardef pointing to the name of the relationship. A logical name is the plural name for the module, like reservations.


In Windows, Killing an application through Python

Question: I am trying to kill external running applications like Windows Paint, a .mp3 and similar programs through a python script.
I open the program throughos.startfile. Any ideas how I can close the programs efficiently? I am using a Windows 7 machine.
I'd appreciate the help a lot! Thanks!
Comment: Seems like the top answer to this question would do what you're looking for: http://stackoverflow.com/questions/5780425/run-external-program-in-a-loop-with-max-time-limit
Comment: What if I don't want to go through the subprocess method?
Answer: As of Python 2.7 os.kill works on Windows.  You could find the PID using this recipe.
Comment: You're welcome.  I agree it is more complicated than I expected.
Answer: Popen will let you kill an opened process, but that won't prompt to save files, etc.
p = subprocess.Popen(['notepad', 'tmp.txt'])
#later
p.kill()

Comment: Can I open non .exe files with `P.open` ?
Comment: I just tried and it doesn't look like it: WindowsError: [Error 193] %1 is not a valid Win32 application
Answer: When you ask Windows to launch something with os.startfile(), you don't get a handle to the created process. This is because the underlying ShellExecute() function does not return a handle to the created process. I believe this is because not all actions actually result in a process being created at all (for example with in-process COM servers or other esoteria).