>The employee monitoring the smoke alarm panel at Notre-Dame cathedral was just three days on the job when the red warning light flashed on the evening of April 15: “Feu.” Fire.
and
>Finally, the guard radioed the fire security employee to call the fire department. It was 6:48, 30 minutes after the first red signal lit up the word “Feu.”
The message specifying the location of the fire could have been more clear, but the fact that the fire alarm was going off was clear. When you see "Feu" flashing red on the alarm panel, the correct course of action is obvious. The greatest failure was that the guards tried to go find the fire, wasting 30 minutes, instead of just calling the fire brigade immediately.
If a tsunami warning is being sounded, would you go down to the beach to try to spot it first, or would you run for the high ground?
If a warning of a bombing came, would you go outside with binoculars and try to spot the planes first, or would you run down into the air raid shelter?
If air-raid sirens (which we do have here in Switzerland) would start sounding, nobody would seek shelter, because everyone would consider an attack too unlikely.
Of course, in retrospect, it would have been better to call the firefighters first. But to make such consequential decisions three days into a new job requires proper training and clearly defined procedures.
This is actually standard procedure in many places. Security guards often have x minutes to see if it's a false alarm:
* https://gps-securitygroup.com/the-role-of-security-guard-reg...
Non-residential buildings are often charged for false alarms, so the landlord may wish to first confirm if the fire brigade is actually needed. If you work in an office tower, or live in an apartment or condo, you'll often have multi-stage fire alarm system: you don't actually evacuate unless either (a) it's a confirmed real incident, or (b) the confirmation timeout has been reached.
They were using a industry standard operating procedure (SOP) in a non-standard environment. Sometimes it's hard to know the situation is non-standard until after the fact.
[0] https://en.wikipedia.org/wiki/Berlin_Brandenburg_Airport#Con...
Accepting an error rate at 98% for Notre Dame should be a no-brainer.
The question is what to do about it. Simply taking a step back and analyzing is not enough. Most of us have been on the projects that were overcomplicated and knew they were overcomplicated and knew a simpler solution and yet didn't have the power to do anything about it. The ultimate power is to be able to walk away form the project but how many people can afford that?
So, I believe the problem is not technical but rather socio-economic.
I am not sure how to solve it.
Been using it since I learned of it on HN and it's impressive the number of times it makes you take a step back and realize you were getting lost between you and yourself.
Find someone in the range of who your average user is, and offer to pay them a beer if they agree to use your interface to do some simple task on it for five minute while you take notes and record the screen. It's a sort-of game for them, short enough that it won't be a hassle, and they get a free beer out of it 'it's inexpensive for you and will reveal some obvious issues faster than a team of dedicated qa tester can ever hope to be.
Here it would be a simple "here is the alarm you get, identify what is the problem and where it is". Given parent post, 5$ and ten minute of beer testing would have told them how terrible it is.
Works fine with group too, ensure one person is the dedicated user, and offer to pay their drink tab.
Be ready to engage with them if they have question and do not be timid about keeping their drink coming if they so desire, as long as they provide valuable input.
It's so obviously stupidly simple, but the result are insane, it's very cheap and you get a perfect case of "how will average person x understand and deal with my software in that situation".
(first learned of it on a hn post years ago, adopted it for fun, kept it because it works too well)
What I thought of was:
- State the problem
- Get drunk
- Find an answer
- Sober up
- Study the problem again
- If you came to the same conclusion as when you were drunk, you are OK.
Find someone in the range of who your average user is, and offer to pay them a beer if they agree to use your interface to do some simple task on it for five minute while you take notes and record the screen. It's a sort-of game for them, short enough that it won't be a hassle, and they get a free beer out of it 'it's inexpensive for you and will reveal some obvious issues faster than a team of dedicated qa tester can ever hope to be.
Here it would be a simple "here is the alarm you get, identify what is the problem and where it is". Given parent post, 5$ and ten minute of beer testing would have told them how terrible it is.
Works fine with group too, ensure one person is the dedicated user, and offer to pay their drink tab.
Be ready to engage with them if they have question and do not be timid about keeping their drink coming if they so desire, as long as they provide valuable input.
It's so obviously stupidly simple, but the result are insane, it's very cheap and you get a perfect case of "how will average person x understand and deal with my software in that situation".
(first learned of it on a hn post years ago, adopted it for fun, kept it because it works too well)
I've seen at least as much stakeholder or designer (backed by stakeholder) ego keeping UX-harming crap in, while plenty of people on the project are very aware of it, despite its being pointed out to them repeatedly. Sometimes they even make you spend more time (money) doing things the wrong way. It's bizarre.
This is a lack of training and a procedural failure - the usual configuration/process is that any alarm either automatically calls firefighters/police or via procedure the guard manually does this - immediately, not after 30min.
We'd expect a phrase to provide more granularity: (or YYYY-MM-DD), and as such, you'd read it exactly as: fire in the attic of the sacristy. The "nave" text is a bit weird, as the sacristy doesn't have a nave, but at the same time, the nave doesn't have a sacristy.
So the entire zone is called "Attic Nave Sacristy", and from that all you know is that there's apparently a fire somewhere in that zone -- could be on the floor of the nave, could be in the cathedral attic, could be somewhere in the sacristy building (even in the attic of the sacristy).
The irony is that you've made a version of the same mistake that either the security employee or the cathedral guard made -- assuming a specific location within that zone. Yours ("the nave attic") happens to be correct; one or both of them assumed it was "the attic of the sacristy building".
Sacristy seems to give the location of where in the nave, which considering that the cathedral is cardinally aligned, is a rather poor choice.
"Attic nave south" would have been a perfect description.
The real problem was that both the main cathedral and the sacristy (a separate building adjacent to the cathedral) had attics; either the security employee got confused and told the cathedral guard to check the sacristy's attic, or the guard got confused and decided to do that.
I suspect the employee, having been on duty only a few days, was not.
“The fire warning system at Notre-Dame took dozens of experts six years to put together, and in the end involved thousands of pages of diagrams, maps, spreadsheets and contracts, according to archival documents found in a suburban Paris library by The Times.
The result was a system so arcane that when it was called upon to do the one thing that mattered — warn “fire!” and say where — it produced instead a nearly indecipherable message.”
The message (assembled):
“Attic Nave Sacristy.” “ZDA-110-3-15-1” “aspirating framework”