Point it, call it, get it right (2018)(flightsafetyaustralia.com)
flightsafetyaustralia.com
Point it, call it, get it right (2018)
https://www.flightsafetyaustralia.com/2018/01/point-it-call-i
13 comments
I tap my pockets for the same items in the same orders and say the item outline. Wallet, phone, keys and vape.
Done it everyday for years and I haven't left anything for about that long, it's pure auto pilot but I know straight away if I've forgotten something.
Silly the things that work sometimes.
Done it everyday for years and I haven't left anything for about that long, it's pure auto pilot but I know straight away if I've forgotten something.
Silly the things that work sometimes.
[deleted]
When I fly and go through the checklists, I call out the setting and touch the pertinent item ("Fuel Selector - BOTH"), and sometimes even flip it to the other position and back ("Alternate Static Air - [move to on, then back to] OFF").
Benefits:
* makes it more likely that I actually check, rather than just see what I expect to be the case
* co-pilot (or passengers!) can follow and verify what I'm doing
* for rarely used items (such as the alternate static air) it makes sure that I know where it is and don't have to fumble for it,
* I check how it "feels", so I could detect if something feels off (for example, throttle cables have occasionally broken loose from the control knob).
Several aircraft have come down just because crews "followed" the checklist, but didn't actually check.
* "After the aircraft was returned into service, the flight crew overlooked the pressurisation system state on three separate occasions: during the pre-flight procedure, the after-start check, and the after take-off check. During these checks, no one in the flight crew noticed the incorrect setting."
https://en.wikipedia.org/wiki/Helios_Airways_Flight_522
* "The flight engineer was found to have failed to open the slat system bleed air valves as required on the pre-flight checklist."
https://en.wikipedia.org/wiki/Lufthansa_Flight_540
Benefits:
* makes it more likely that I actually check, rather than just see what I expect to be the case
* co-pilot (or passengers!) can follow and verify what I'm doing
* for rarely used items (such as the alternate static air) it makes sure that I know where it is and don't have to fumble for it,
* I check how it "feels", so I could detect if something feels off (for example, throttle cables have occasionally broken loose from the control knob).
Several aircraft have come down just because crews "followed" the checklist, but didn't actually check.
* "After the aircraft was returned into service, the flight crew overlooked the pressurisation system state on three separate occasions: during the pre-flight procedure, the after-start check, and the after take-off check. During these checks, no one in the flight crew noticed the incorrect setting."
https://en.wikipedia.org/wiki/Helios_Airways_Flight_522
* "The flight engineer was found to have failed to open the slat system bleed air valves as required on the pre-flight checklist."
https://en.wikipedia.org/wiki/Lufthansa_Flight_540
I have “looked” and called out "airspeed alive" on a failed ASI before. (It clicked a moment later in time to abort, but if there were a CVR, the word “Alive” would have been on the tape.) Seeing what you expect from rote is a genuine problem.
Personally I like to use a call-and-response style checklist and have passengers read through it for me when possible. They call out the item, I respond with the value, they confirm it against what the checklist says.
There are so many similar stories of not completing checklists in aviation.
A plane was painted and they failed to remove tape placed over the pilot tube (followed by a series of more bad choices after the plane took off).
In another case a military plane crashed after the flight engineer asked of they completed the landing checklist, they hadn't.
A plane was painted and they failed to remove tape placed over the pilot tube (followed by a series of more bad choices after the plane took off).
In another case a military plane crashed after the flight engineer asked of they completed the landing checklist, they hadn't.
I tried this, but my co-workers asked me to quit yelling "use strict" while pointing at the top of the file.
This is the role of code comments for me:
- Point It: Comment itself
- Call It: Comment explicates why potentially surprising or ambiguous thing that follows is the way it is.
- Get It Right: Eliminates potential error in future. (Or maybe helps spot one if explanation doesn't mesh with observed behavior.)
I was just reviewing a PR requesting clarification of some config settings and this article (which I looked at earlier) came to mind.
- Point It: Comment itself
- Call It: Comment explicates why potentially surprising or ambiguous thing that follows is the way it is.
- Get It Right: Eliminates potential error in future. (Or maybe helps spot one if explanation doesn't mesh with observed behavior.)
I was just reviewing a PR requesting clarification of some config settings and this article (which I looked at earlier) came to mind.
You'd think they'd already be yelling after reading the shebang...
maybe if william hung is on your team...
Brings to mind:
Why Japan’s Rail Workers Can’t Stop Pointing at Things
A seemingly silly gesture is done for the sake of safety.
BY ALLAN RICHARZ MARCH 29, 2017
https://www.atlasobscura.com/articles/pointing-and-calling-j...
April 2018 HN discussion: https://news.ycombinator.com/item?id=14011793
April 2018 HN discussion: https://news.ycombinator.com/item?id=14011793
The nuclear industry has something very similar, and in my experience it's extremely effective. It also gives anyone else in the space with you a chance to speak up if you're about to do something wrong.
I do the same when commissioning our products - winch systems for the offshore industry. My assumption is that the big, bad piece of machinery is actively trying to kill me and anyone in the vicinity if we give it even half a chance.
Calling out the checklist items lead both me and others to not take any shortcuts and never assume anything, also ensuring everyone is up to speed on what is about to happen.
I knew I was doing something right when, after intentionally leaving out a step to see if the apprentice was paying attention, I immediately got a good dressing down for my trouble.
Calling out the checklist items lead both me and others to not take any shortcuts and never assume anything, also ensuring everyone is up to speed on what is about to happen.
I knew I was doing something right when, after intentionally leaving out a step to see if the apprentice was paying attention, I immediately got a good dressing down for my trouble.
Amen, hermano. Good practices in mechanical systems industries seem to cross disciplines because they work.
Not being a UX/ergonomics buff, I wonder how something like this might be employed in software UIs, particularly those controlling/monitoring safety-critical systems.
Any UX experts in the house?
Any UX experts in the house?
You could reproduce the IRL process by adding "hover" / "speak in the microphone" steps, by I don't think they are necessary. After all, "Point it, call it, get it right" is just a mean to an end, we don't have to do exactly the same to get the same benefits.
For the "point it", it is a signification of proper intent, and it is what sliders, long click and triple fingers gestures are for: make it obvious you opt in for that feature.
E.G: the slider to open your phone so that it's not an accident, the long click to select an sms for deletion or the 3 fingers gesture to screen capture an android and not scroll.
Now, "calling" makes it sure you follow the mandatory step by step checks. So for a tool that requires it, it's easy to enforce programmatically. E.G: "multi part forms" or "first visit tour". It also lets other people survey you do the right thing. We have software rules for immediate feedback for that, and audit trails for the long term.
As for the "get it right", the "point it" is usually enough. If you want more, you have 5 strats:
- "are you sure" ?
- ctrl + z (possibly with history)
- "type here 'I confirm that I want deletion'
- please enter your password / totp code, etc
- proper permissions and checks
For the "point it", it is a signification of proper intent, and it is what sliders, long click and triple fingers gestures are for: make it obvious you opt in for that feature.
E.G: the slider to open your phone so that it's not an accident, the long click to select an sms for deletion or the 3 fingers gesture to screen capture an android and not scroll.
Now, "calling" makes it sure you follow the mandatory step by step checks. So for a tool that requires it, it's easy to enforce programmatically. E.G: "multi part forms" or "first visit tour". It also lets other people survey you do the right thing. We have software rules for immediate feedback for that, and audit trails for the long term.
As for the "get it right", the "point it" is usually enough. If you want more, you have 5 strats:
- "are you sure" ?
- ctrl + z (possibly with history)
- "type here 'I confirm that I want deletion'
- please enter your password / totp code, etc
- proper permissions and checks
This feels like it runs along the same lines as the "type the name of the item you want to delete" requirement some confirmations windows use.
Not UX. It's traditionally called things like "human factors engineering", or "human-computer interaction" (HCI).
UX is more what used to be "graphic design", especially for marketing collateral, adapted to the more dynamic new media serving the same purposes.
UX is more what used to be "graphic design", especially for marketing collateral, adapted to the more dynamic new media serving the same purposes.
Maybe if you had to say "DELETE" out loud when hovering over the "are you sure you want to delete this?" confirmation to verify it.
GitHub requires you to type the word "delete" into a text box in order to delete a repository.
It's an interesting example of how a seemingly "anti-usability" feature can actually help usability by preventing a wrong action.
Usability is mostly about making it easier to do the right thing, but sometimes making it harder to do the wrong thing helps too.
It's an interesting example of how a seemingly "anti-usability" feature can actually help usability by preventing a wrong action.
Usability is mostly about making it easier to do the right thing, but sometimes making it harder to do the wrong thing helps too.
> Maybe if you had to say "DELETE" out loud when hovering over the "are you sure you want to delete this?" confirmation to verify it.
I think that's almost useful, but better if it displays and asks you to echo a key fact that helps you recognize an action as important and/or confirm it's what you intended. Typing is fine; no need to do voice recognition.
* the number of machines your action will affect (for cluster management tools)
* the amount of traffic (qps, Mbps, etc) you'll affect (for routing changes, taking down servers, etc.)
* the amount of data you're deleting (some rounded form is fine) in files, bytes, database rows, etc.
* since someone else mentioned deleting a github repository: the repo's number of unique commits (ones not found in the repo it was forked from), issues, PRs, or even just stars/forks.
* the number of people you're adding to or removing from an ACL group / mailing list
I think that's almost useful, but better if it displays and asks you to echo a key fact that helps you recognize an action as important and/or confirm it's what you intended. Typing is fine; no need to do voice recognition.
* the number of machines your action will affect (for cluster management tools)
* the amount of traffic (qps, Mbps, etc) you'll affect (for routing changes, taking down servers, etc.)
* the amount of data you're deleting (some rounded form is fine) in files, bytes, database rows, etc.
* since someone else mentioned deleting a github repository: the repo's number of unique commits (ones not found in the repo it was forked from), issues, PRs, or even just stars/forks.
* the number of people you're adding to or removing from an ACL group / mailing list
This gets my vote. Keep a recording of the confirmation for any potential legal issues.
Plus the image of the silence in an office being punctuated by the occasional "DELETE" or "CONFIRM DROP TABLES" is hilarious.
Plus the image of the silence in an office being punctuated by the occasional "DELETE" or "CONFIRM DROP TABLES" is hilarious.
That makes sense, but forcing the user to change modes is bad. If I'm using a touchscreen, I often can't make noises; if I'm using voice, I often can't touch the screen.
>forcing the user to change modes is bad
Congratulations, you named the very reason this technique is effective. I am not being facetious here.
The whole idea is to make the user perform disruptive, unfitting actions -both in the mind and physically- to improve chances of catching errors.
First, to both make the mind "shift gears", or perform a "context switch", with all the related cache-flushing and prediction-discarding and all that.
Second, to activate brain regions that were hitherto suspended; the ones associated with other senses and skills, in particular with vocal skills. Fleshing out abstract concepts into concrete words helps catch mistakes, just like putting abstract feature requests into concrete diagrams or code helps with catching errors or inconsistent expectations & assumptions.
Congratulations, you named the very reason this technique is effective. I am not being facetious here.
The whole idea is to make the user perform disruptive, unfitting actions -both in the mind and physically- to improve chances of catching errors.
First, to both make the mind "shift gears", or perform a "context switch", with all the related cache-flushing and prediction-discarding and all that.
Second, to activate brain regions that were hitherto suspended; the ones associated with other senses and skills, in particular with vocal skills. Fleshing out abstract concepts into concrete words helps catch mistakes, just like putting abstract feature requests into concrete diagrams or code helps with catching errors or inconsistent expectations & assumptions.
Fair enough; I missed that mikro2nd mentioned safety-critical systems. In that case, sure, let's adapt the whole environment to allow for those mode changes.
I was thinking more about systems where no lives are at stake, and there I think there's no need to change modes, one can be DISRUPTIVE ENOUGH by using the same IO channels, which are quite flexible already.
I was thinking more about systems where no lives are at stake, and there I think there's no need to change modes, one can be DISRUPTIVE ENOUGH by using the same IO channels, which are quite flexible already.
This reminds me of somthing I tend to do when paring on an ops-like task. I will point and speek the resource name that I am about to delete or CMD I am about to run and get my pair to conferm before proceeding. Honestly makes tasks (espishaly production tasks) a lot less nerve racking. Would recommend it.
espishaly is especially special.
I do this after eating dinner, before going to bed. I do it for the door locks of the house, the knobs/dials of the stove, the gas valve behind the stove, the fridge door (giving it a push instead of pointing at it), the sink (to make sure it's clear of dishes), the windows.
I also do it for my car locks and windows to make sure they're closed and locked before leaving it. I'll make a point of it to touch the windows at the top edge and pull the handles.
I also do it for my car locks and windows to make sure they're closed and locked before leaving it. I'll make a point of it to touch the windows at the top edge and pull the handles.
Commitment but it makes me wonder where to draw the line.
Checking toilet and sink faucet before leaving bathrooms?
Site looks like it's down. Text-only Google cache version: http://webcache.googleusercontent.com/search?q=cache:hPbnMAa...
This reminds me of lifeguards, which seem to have changed their techniques since I was a kid.
They seem to point at one end of the pool and move their finger back and forth to the othe end of the pool.
They seem to point at one end of the pool and move their finger back and forth to the othe end of the pool.
Something a bit like this is practiced by NYC subway conductors: https://youtu.be/i9jIsxQNz0M
I point left and right to look for oncoming cars before crossing the street. I feel safer and more aware of my surroundings this way.
TDD in a nutshell.
So every time, before I pull the trigger on the saw, I now touch the side of the safety glasses with my free hand and say out loud, "glasses on."
It felt super goofy at first, but after a while the safety check became part of the cadence and rhythm of turning on the saw. I feel much less likely to get a shard of wood or aluminum in my eye as long as I keep it up.