We added a clause in our coding standard to make all booleans reference the positive frame of reference only. This happened after I got fed up with dealing with too many if !(!not_has_missing_field) operators. Just.... make everything positive: if (is_field_present)
I try to keep to that, but sometimes the flag is turning on a negative feature, disabling that which is the default and will remain so for compatibility reasons.
Sometimes it is worth the effort of going through and changing the logic elsewhere to keep the boolean positive, sometimes that would be too much effort to retest at the time.
Another option I like, when I have a config object interpreting things so I'm reading doing “if (config.IsWhateverThatThingIsEnabled)” then I can just have paired properties to pick from when I want to check IsEnabled or IsDisabled.
Agree. And I've been flagging double negatives in PRs for years (e.g. `not undead`). It makes me feel like the Ned Flanders of programmers.
But RuboCop detects `!!something`, and I actually like that idiom, because I prefer to convert into true boolean types before passing them to a method, since it makes the intention clear in the code.
I agree that such forced choices are insulting. It's about the same as also including a disabled "No" button with hover text that reads "disabled because fuck you".
One of the most influential books I ever read was About Face by Alan Cooper. What he said about this bad modal dialogue is that you should simply not ask the user, and let them undo later.
This was heresy at the time, but turned out to be the native user flow for iOS later on. And now it's common in web apps.
Remember in 1990 (the pictures are from around then) there wasn't unlimited fast disk space. There was a good chance you were saving to a floppy disk which not only was slow, but might not be in the drive all the time. At least in 1990 you could assume a hard drive - but you couldn't safely assume there was enough free space on the drive to save anything, since 40mb drives filled fast.
35 years latter we live in a different world where you can assume an unlimited fast data connection to a data center. Saving and allowing undo is possible today.
It took me quite a while to get used to the "save continuously, keep revision history" of Google Docs, but in that context I've gotten used to it. For something like code, or image edits, etc. I still prefer explicit "Save" or "Save As..." operations that I control, because quite often I get myself boxed into something that I just want to throw away and start over.
Sydney Padua's awesome, mostly true, steampunk graphic novel "The Thrilling Adventures of Lovelace and Babbage" jokes about the error messages that might have produced by the difference engine. One example occurs when a character tries to stop a sequence that may or may not destroy a precious manuscript:
Annulation lever activated!
Do you wish to continue?
Engage STOP lever to continue. Engage CONTINUE lever to stop.
A program I occasionally use has a "Don't close" button in that dialog. Of course I'm more used to "Don't save", so I often hit it and then am surprised when the program stays open.
Aspirin had (though this is increasingly dated) unique cultural currency as a headache medicine for quite a while after it stopped being the overwhelmingly dominant first-line OTC remedy.
“Maybe later” and variants annoyed me to no end until I realized that the implication is that you’re not making an indelible choice. As with anything, it can be overused, but I personally enjoy not having to think about whether I can change my mind later.
Rip John C. Dvorak, writer of the Abort/Retry/Fail column from PC Magazine.
On a different note, never underestimate the value of a modal dialog that gives you a chance to retry an IO operation that failed. Loose USB cables and network shares over Wifi can make those happen a lot more often.
Keeping one of the disks from the pile was peak bff/sibling rivalry antics. It's like keeping out one of the pieces of the puzzle so nobody can finish it but you.
For a site about usability, I was going to gripe about the tiny font, low contrast, and unresponsive layout until I saw that. It does look more suitable at 1024x768.
I’ve always loved how TextEdit’s “don’t save” button is actually a red button that says “delete” for unsaved text files.
There’s no ambiguity there. The user is very well-informed that they’re about to quit and lose the document they were working on.
The example of Pages from the article has actually since been changed to do the same thing.
Red "Delete" on the far left, then on the far right a gray/neutral "Cancel" button, and an orange (the app's primary color) "Save"
We added a clause in our coding standard to make all booleans reference the positive frame of reference only. This happened after I got fed up with dealing with too many if !(!not_has_missing_field) operators. Just.... make everything positive: if (is_field_present)
I try to keep to that, but sometimes the flag is turning on a negative feature, disabling that which is the default and will remain so for compatibility reasons.
Sometimes it is worth the effort of going through and changing the logic elsewhere to keep the boolean positive, sometimes that would be too much effort to retest at the time.
Another option I like, when I have a config object interpreting things so I'm reading doing “if (config.IsWhateverThatThingIsEnabled)” then I can just have paired properties to pick from when I want to check IsEnabled or IsDisabled.
Agree. And I've been flagging double negatives in PRs for years (e.g. `not undead`). It makes me feel like the Ned Flanders of programmers.
But RuboCop detects `!!something`, and I actually like that idiom, because I prefer to convert into true boolean types before passing them to a method, since it makes the intention clear in the code.
This is more or less the reason why bool is not recommended as a type, instead use a enums which add semantic value
1. LibreOffice's recover files dialogue series of steps is frustrating like this.
2. Still better than "Yes, Ask me Later" dialogues that are so insulting to users.
I agree that such forced choices are insulting. It's about the same as also including a disabled "No" button with hover text that reads "disabled because fuck you".
One of the most influential books I ever read was About Face by Alan Cooper. What he said about this bad modal dialogue is that you should simply not ask the user, and let them undo later.
This was heresy at the time, but turned out to be the native user flow for iOS later on. And now it's common in web apps.
https://www.amazon.com/dp/1118766571?lv=shuf&channelId=500&p...
Remember in 1990 (the pictures are from around then) there wasn't unlimited fast disk space. There was a good chance you were saving to a floppy disk which not only was slow, but might not be in the drive all the time. At least in 1990 you could assume a hard drive - but you couldn't safely assume there was enough free space on the drive to save anything, since 40mb drives filled fast.
35 years latter we live in a different world where you can assume an unlimited fast data connection to a data center. Saving and allowing undo is possible today.
In the world of 2TB SSD’s, it does seem silly to risk inadvertently deleting an important ~2kb word document.
It took me quite a while to get used to the "save continuously, keep revision history" of Google Docs, but in that context I've gotten used to it. For something like code, or image edits, etc. I still prefer explicit "Save" or "Save As..." operations that I control, because quite often I get myself boxed into something that I just want to throw away and start over.
My favorite is apps that offer a way to cancel a long-running operation, where clicking "cancel" on the confirm dialog cancels the cancellation.
Sydney Padua's awesome, mostly true, steampunk graphic novel "The Thrilling Adventures of Lovelace and Babbage" jokes about the error messages that might have produced by the difference engine. One example occurs when a character tries to stop a sequence that may or may not destroy a precious manuscript:
Annulation lever activated!
Do you wish to continue?
Engage STOP lever to continue. Engage CONTINUE lever to stop.
Time remaining 5..4..3...
A program I occasionally use has a "Don't close" button in that dialog. Of course I'm more used to "Don't save", so I often hit it and then am surprised when the program stays open.
Not understanding the aspirin reference.
Aspirin had (though this is increasingly dated) unique cultural currency as a headache medicine for quite a while after it stopped being the overwhelmingly dominant first-line OTC remedy.
Pretty sure "causes Aspirin sales to soar" is an attempt at cleverly saying "gives people headaches"
Thanks, I also found this unclear.
An active "yes/no/cancel" prompt is a paragon of usability compared to the modern standard of constant yes, except for when it fails with a silent no.
"Maybe later..."
“Maybe later” and variants annoyed me to no end until I realized that the implication is that you’re not making an indelible choice. As with anything, it can be overused, but I personally enjoy not having to think about whether I can change my mind later.
(A)bort? (R)etry? (F)ail?
Rip John C. Dvorak, writer of the Abort/Retry/Fail column from PC Magazine.
On a different note, never underestimate the value of a modal dialog that gives you a chance to retry an IO operation that failed. Loose USB cables and network shares over Wifi can make those happen a lot more often.
And it came from the days of floppy disks, so we often needed the chance to put the correct disk back in the right drive!
When the game comes on 14 floppy disks, sometimes you forget how to count in the excitement.
Keeping one of the disks from the pile was peak bff/sibling rivalry antics. It's like keeping out one of the pieces of the puzzle so nobody can finish it but you.
As I remember, standard operating procedure was to retry 4 or 5 times, then turn off the computer and walk away in frustration.
(2007)
For a site about usability, I was going to gripe about the tiny font, low contrast, and unresponsive layout until I saw that. It does look more suitable at 1024x768.
Good year
Every year was better before 2020!
I thought this was going to be about a marketing success example for Aspirin! ... Although, I guess in a roundabout way it was.
Great title. Great topic. The tiny details are all here, including the 4th option (X), the Abort/Retry/Fail link, and they even have RSS! Subscribed.