Push to open (but not yet!)
Why the way door buttons work has changed, I think.
The train is pulling into your station. Standing by the door buttons, you find yourself de facto door openerer, with the great responsibility such a role carries. A gaggle of commuters crowds behind you, ready to be on their way as soon as the train stops and without a moment’s delay. Now, all of this rests on you. Finger on the button. Are you up to the challenge? Can you handle the pressure?
Oh, you pressed it too early - you lose.
Hold to open
It used to be the case that on many trains, you could just hold the door open button and - when the doors were released or unlocked - they’d open. This seems very obvious, and on the face of it, logical, and that’s because it was. In fact, on most trains that are more than 5-10 years old, it still works like this.
As nominated door button operator, everyone else could see that you were diligently holding down the button and therefore be confident that you were already doing what was required of you. No further action needed - once the doors were released, they’d open. There was no pressure involved.
What’s changed?
On newer trains, though, this is no longer the case.
If you press the button before the doors are released, instead it angrily lights up in red at you. “How dare you press me before I am ready?!” And if you hold it in anyway, it just ignores you, even if the doors are released in the meantime.
Instead, in a game of fastest finger first, to open the doors, you have to be ready for the button to light up in green and invite you to press it, accompanied by the beeping that signifies doors have been released.
One must not press the button before one has been invited to do so.
This changes the dynamic of the much lauded role of door button operator - now, you must be ready to react - eyes on the button, because it lights up milliseconds before it starts to beep, and once it’s done so (but only then) may you press it. And then the doors open.
Why?
What’s hard to understand at first, is why the effective ‘mode of operation’ of these buttons has been changed in a way that seems to be counter to what users want and are accustomed to.
When new trains were introduced on my local London Overground line a few years ago, my local Facebook group was awash with people whinging (quite rightly) about how annoying it was to change the habit of a lifetime on their commute. “Bring back the old trains!”, they cried in hyperbole.
As someone who’s mobile, can hear and see (at least with my glasses on), of course I recognise that this change is little more than an annoyance for me. And while my suspicion was always that this change was one made for accessibility reasons, I’d never quite given it enough thought to work out exactly what those reasons might be.
So now I’ve done my homework, or at least tried.
The regulations
As it turns out, but completely unsurprisingly, there are an eye-watering number of regulations surrounding everything to do with trains. I’d heard of some of them - they’re the reason the Pacers were finally retired, for one.
It also turns out that there are a lot of regulations surrounding buttons on trains - particularly those to do with opening doors - known officially as door control devices.
PRM TSI (Technical Specifications of Interoperability relating to “persons with reduced mobility”… my gosh) is the big name in all of this, a cross-European framework covering everything from toilet seat colour to gap fillers.
So why can’t I hold in my door buttons?
Well, after having done some digging, it’s actually hard to say.
I can find information about how door buttons need to be visually and physically identifiable, what size they should be, how they should be positioned and whether open or close should be on top. I can also find information about how they should beep, which colours they should light up in and for how long, and how much force it must take to press them.
But I don’t seem to be able to find an exact set of rules on how they should work.
The closest I was able to find is a German button manufacturer’s paraphrasing of the requirements of something called EN 14752, which is a European standard titled “Railway applications - Bodyside entrance systems for rolling stock” (an impressive word salad, if ever there was one.)
Of relevance, this particular button manufacturer states:
Push button for an operational, not released door should not light up
Button for an enabled door area, must be constantly lit green
Push button for unaccepted input, must light red (100 percent of available red light), constantly for min. 1 second or as long as the push button is pressed
A door that is locked and out of service should be indicated by the area of the push button is permanently illuminated red (100 percent of the available red light)
This sounds promising, so you may think that I could go and see what the standard itself actually says, but no - that costs anywhere up to £462 for the latest version (and frankly, I’m just not that curious).
So I figure I’ll just try and work backwards with some design logic.
What’s wrong with old buttons?
Let’s try and think about what’s wrong with older door buttons, from the perspective of accessibility.
If I press the button before the doors are released, how do I know that it worked or didn’t? I suppose I don’t, because it doesn’t do anything. But even if it did, there’s no sound, no lighting up, no nothing. In this scenario, given pressing the button does nothing, is it appropriate that there’s no feedback either?
And if I hold the button before the doors are released, again - no feedback, until they are released, at which point the doors will open. I suppose that’s a sort of feedback that it worked - right?
If I press the button when the doors are released, how do I know that it’s going to work? In fact, how do I know that they’re even released? There’s no way for me to know that the buttons are active - I wouldn’t know if there’s something wrong or the door is out of service? And when I press it, does it give me feedback that the doors will open (sometimes this can take a few seconds), or does it tell me that it’s broken?
Can you see the problem yet?
Feedback
Given all I have to go on are four bullet points from an 85 page standards document, my working theory is that this is all about providing feedback.
If I push a button, it should provide feedback that it has either worked (and is doing something), hasn’t worked (and isn’t), or was never going to work in the first place (and so I shouldn’t have pressed it). It should absolutely not under any circumstances do nothing.
If someone’s visually impaired, and they’re stood at a door that’s out of service (perhaps marked with a notice on the door saying so), they’ll just find themselves mashing the door open button until someone offers assistance. And they shouldn’t need that assistance.
The button - I beg your pardon, door control device… - needs to be able to provide feedback for possible user interactions in all states. It also needs to indicate if it’s currently in a state that means it can be interacted with.
But I just looked at some videos (YouTube will be recommending me videos of train door buttons for at least the next six months thanks to this) to see what they actually do (in this case on the Bombardier Aventra trains used on the London Overground and Elizabeth line) and frankly - they’re not as good as I was misremembering them to be.
Because I have too much time on my hands, here’s a graphic kinda-sorta showing the different types of visual feedback for their buttons:
I hate to be a pedant, but I feel like there are some glaring omissions here:
There’s no visual feedback that the door is opening once you press the button, other than the door itself actually opening - it just stays solid green, even if the beeping changes. If we have to give negative feedback for an unaccepted button press, surely we have to give positive for an accepted one?
The door buttons continue to stay solid green while the doors are open, despite there no longer being any reason to press them. Surely these buttons shouldn’t be lit at this time?
If you push the button while the doors are open, or while they’re closing, what happens? I don’t know, and I’m not sure I want to get See it, Say it, Sorted trying to find out.
How the buttons behave does appear to match the rules as summarised above, but there’s quite a lot of unknowns which make it feel like a system only partly thought out.
Does this negate hold to open?
The problem with hold to open is that it kinda breaks this model. You’re pressing the button knowing that it won’t work yet, but on the understanding that it will eventually.
But as far as the button is concerned, you’re trying to open the doors when they’re not released, and it wants to tell you that you can’t do that (or that it hasn’t worked). And so it gets all angry at you.
Does this mean that hold to open isn’t possible anymore?
While the industry (or at least the big button lobbyists) have clearly decided that this is the case, I don’t know if it has to mean that necessarily. What if I just hold the button in despite it glowing red, and then once doors are released, it just opens them anyway? What if there’s some intermediate state, where it glows orange or something else? Is there something in the very expensive and secretive standard which precludes that? I guess I’m just too poor to find out.
Request to open
One possibility is the logic I’ve seen on trams - you press the button once and it treats this as a request to open the doors once they’re released - and then they automatically open at the next stop.
I haven’t been on a tram in ages (when did I last go to Croydon IKEA?), but I seem to remember the button would flash to show that the request was pending. I think it may have been possible to cancel it by pressing again.
This seems to be the next best thing, but again, is it ruled out by the regulations? Are the rules different for trams? How could you effectively provide feedback in this scenario in a way that isn’t confusing? It seems kind of obvious as a solution, and still allows the buttons to provide feedback for all possible interactions.
Conclusion
From a user experience perspective, I completely agree that providing both positive and negative feedback for any interaction, and giving an indication of state is important - not just for accessibility purposes but as good practice. But the new buttons don’t actually appear to do this, or at least not in a way that seems totally coherent.
Either way, there should be no doubt in a user’s mind whether something has worked or not - when you press a doorbell you ought to be able to hear it faintly ring behind the door.
Once again, it seems that had I read more of The Design of Everyday Things instead of writing (I’m getting through it, I swear!), I could probably elaborate on this further.
What’s for certain though, is that changing the way something works without telling anyone, and leaving it up to users to discover for themselves that you’ve done so, leaves a bad taste in everyone’s mouths. If there’s a good reason to make a change, you need to communicate it. (And if there isn’t, don’t make the change.)
Instead, every single passenger who had been used to the old trains had to go through the frustration of finding out for themselves that it simply doesn’t work that way on their replacements. And five years after the new trains’ introduction, I genuinely still resent a little bit that I can’t hold the door button and now have to pay attention, even if I secretly enjoy the challenge of pressing the button as quickly as possible when it lights up.








I suspect the change is more to do with the technology than with accessibility.
On older trains the tech is much simpler - simple button closes the circuit, if doors are powered - which is controlled by a master switch - then they open or close. On some old trains (I believe the venerable ex-508 carriages within class 455s?) this could even mean that letting go of the open button too early would see the doors close again!
On newer trains the buttons will be part of a digital control system, where a button press sends a request to a controller, which makes the decision in software as to what action needs to be taken. This allows for, among other things, more sophisticated selective door opening (SDO) so that, for example, individual sets of doors with a carriage can be kept closed at specific stations, rather than the whole carriage having to be locked out.
Anyway, in my view, the best solution is the one you mentioned on the trams - on approach to a station, a button press should show some kind of green flashing response to indicate that the door will open automatically as soon as the train has stopped. But this isn't as simple as it sounds - you do want to limit this capability to just station approaches, particularly for longer distance trains with longer times between stations. Otherwise there are risks from accidental/unwanted presses.
And I was also always a "holder", not a "waiter" (nor a frustrating "tapper") and I miss being able to reliably hold the button on newer trains.