3 ms·

Ideally, when calling OpenFileDialog or equivalent user prompts, one should opt for using verbose action labels, instead of the often ambiguous defaults (Okay/C

Ideally, when calling OpenFileDialog or equivalent user prompts, one should opt for using verbose action labels, instead of the often ambiguous defaults (Okay/Cancel, Yes/No, worst yet: Yes/No/Cancel): Are you sure you want to delete this draft? [(Yes) Delete Draft] [Cancel (Deletion)] Are you sure you would like to Exit? [(Yes) Exit ($appname)] [No, Continue] ()*optional extra specificity for clarity With more sensitive commands with possibly dubious parameters, prompting the user to re-enter the dubious argument can help default mindless clicks or the occasional brain fog or mistype; even translates well onto command line: >>Are you sure you want to delete 12 folders, totalling 23,401 files? Please confirm the number of files to proceed: >>23401

kristopolous 4y ago
I'm a fan of first person sentences. Do you want to quit? > No. I'm still working! > Yes. I'm done for now. Especially in a mobile interface. The user is physically touching "I'm done for now"; it's a visceral interface; real hard to mess up unless some motility accident happens (like the phone slips)
- InCityDreams 4y ago
  Perfect. And standard practice would be... Do you want to quit? > No. I'm still working! > Yes. I'm done for now. ...until some twunt reverses the order of the answers. And others (about 35%) follow that, as a standard practise.
- fragmede 4y ago
  I disagree that it's visceral on mobile. First, close your eyes then toss your phone up in the air with a spin, catch it and try and then try and click on 'I'm done for now'. Feels exactly the same as "I'm still working!". "Visceral" should be reserved for things with physical buttons that make a satisfying ca-chunk and you're sure, blindfolded, that you didn't press the wrong one. Not slippery glass bricks.
  - kristopolous 4y ago
    Totally agreed! I meant within the confinements of the reality presented. I try to reduce the abstractions without breaking conventions so much that it would increase confusion
chungy 4y ago
> Are you sure you want to delete this draft? [(Yes) Delete Draft] [Cancel (Deletion)] > Are you sure you would like to Exit? [(Yes) Exit ($appname)] [No, Continue] I see you are starting to discover the GNOME Human Interface Guidelines. Yes/No and OK/Cancel are discouraged, opting for meaningful button names instead.
- Jerrrry 4y ago
  I did notice back in the Ubuntu Intrepid days how much clearer the labels were for the applications vs. Windows XP's three options.
xorcist 4y ago
It's hard to construct such phrases to be disambiguous. "Continue" as an answer to "Would you like to exit?" can be interpreted as continuing with the exit or with using the software. And there are plenty of similar examples.
- Jerrrry 4y ago
  avoid one word responses, especially functionally ambiguous ones. >Would you like to exit? >[Yes, Exit $appname] [No, continue working] If one word is a constraint, phrase the question better, or have the alternative be more specific too: >Are you sure you would like to Exit? >[Exit] [Cancel] >You have unsaved changes. Would you like to save the changes before exiting? >[Save Changes and Exit] [ Exit without Saving] [Cancel]
AnimalMuppet 4y ago
One horrible example was back in the MS-DOS days. FORMAT wanted you to tell it when you had inserted the floppy. So it said "Hit any key to continue". And it really meant "hit any key". Control-C? Continue. Escape? Continue. Cntrl-alt-delete? Continue. There literally was no way out except to power off the machine. (Well, if it was a floppy, you could remove the floppy.) Not accepting the normal ways of stopping execution, when it's a destructive operation, and not explicitly warning the user that you're going to proceed even on the normal "stop" keystrokes... that's a really bad combination.
- a1369209993 4y ago
  > And it really meant "hit any key". Control-C? Continue. Escape? Continue. Ctrl-alt-delete? Continue. `Hit any key to continue or any other key to quit.` "Wait, which one's the any key?" "Better question: which one's the other key?"
partdavid 4y ago
My problem with lots of these experiences is that they're still boilerplate (whether verbose or not) and require me to apply a conditional that the computer should tell me about. For example, quitting a game: "Are you sure (Y/N)? (Unsaved progress may be lost)" Don't tell me that. Tell me whether unsaved progress will be lost and what it consists of. Likewise, when I'm typing a description in JIRA and want to follow a link "Are you sure you want to navigate away (Y/N)? (Unsaved changes may be lost)" Wait--do I have unsaved changes? If so, what are they? That's what I should be basing my decision on--what specifically will happen if I click Yea or Nay? Not a general exhortation to be careful because waves hands something bad might happen: YOU get to figure out if it will or not!
- Jerrrry 4y ago
  Windows Notepad has gotten that right since inception, but a more detailed report of the magnitude of action/changes/loss would definitely be a trivial and welcome feature. I think the overall idea is that smaller dialog in prompt boxes are somehow better to avoid "warning/agree fatigue" but ultimately it worsens the overall clarity of the function and purpose.
  - partdavid 4y ago
    Sure, it would have to be thoughtful, careful, context-dependent and possibly optional (e.g. a "Details" toggle or something). But it would still be so much more useful to see "Do you want to navigate away? (580 characters of Description and two other fields will be lost)". Or "Do you want to quit? (0:28 mins of play will be lost)" versus just quitting when nothing will be lost because the auto-save is up to date. Just warning that something may or may not be destructive and leaving it up to me to guess how things work feels lazy to me, as a user. As a developer, I understand it entirely! And it would help avoid warning fatigue because the warning only appears when something actually is going to be lost--and then you can decide whether to keep it or not.
    - account42 4y ago
      > But it would still be so much more useful to see "Do you want to navigate away? (580 characters of Description and two other fields will be lost)". Or "Do you want to quit? (0:28 mins of play will be lost)" versus just quitting when nothing will be lost because the auto-save is up to date. For games, you could perhaps even omit the warning entirely if you just saved manually.

kristopolous 4y ago

I'm a fan of first person sentences. Do you want to quit? > No. I'm still working! > Yes. I'm done for now. Especially in a mobile interface. The user is physically touching "I'm done for now"; it's a visceral interface; real hard to mess up unless some motility accident happens (like the phone slips)

InCityDreams 4y ago
Perfect. And standard practice would be... Do you want to quit? > No. I'm still working! > Yes. I'm done for now. ...until some twunt reverses the order of the answers. And others (about 35%) follow that, as a standard practise.
fragmede 4y ago
I disagree that it's visceral on mobile. First, close your eyes then toss your phone up in the air with a spin, catch it and try and then try and click on 'I'm done for now'. Feels exactly the same as "I'm still working!". "Visceral" should be reserved for things with physical buttons that make a satisfying ca-chunk and you're sure, blindfolded, that you didn't press the wrong one. Not slippery glass bricks.
- kristopolous 4y ago
  Totally agreed! I meant within the confinements of the reality presented. I try to reduce the abstractions without breaking conventions so much that it would increase confusion

chungy 4y ago

> Are you sure you want to delete this draft? [(Yes) Delete Draft] [Cancel (Deletion)] > Are you sure you would like to Exit? [(Yes) Exit ($appname)] [No, Continue] I see you are starting to discover the GNOME Human Interface Guidelines. Yes/No and OK/Cancel are discouraged, opting for meaningful button names instead.

Jerrrry 4y ago
I did notice back in the Ubuntu Intrepid days how much clearer the labels were for the applications vs. Windows XP's three options.

xorcist 4y ago

It's hard to construct such phrases to be disambiguous. "Continue" as an answer to "Would you like to exit?" can be interpreted as continuing with the exit or with using the software. And there are plenty of similar examples.

Jerrrry 4y ago
avoid one word responses, especially functionally ambiguous ones. >Would you like to exit? >[Yes, Exit $appname] [No, continue working] If one word is a constraint, phrase the question better, or have the alternative be more specific too: >Are you sure you would like to Exit? >[Exit] [Cancel] >You have unsaved changes. Would you like to save the changes before exiting? >[Save Changes and Exit] [ Exit without Saving] [Cancel]

AnimalMuppet 4y ago

One horrible example was back in the MS-DOS days. FORMAT wanted you to tell it when you had inserted the floppy. So it said "Hit any key to continue". And it really meant "hit any key". Control-C? Continue. Escape? Continue. Cntrl-alt-delete? Continue. There literally was no way out except to power off the machine. (Well, if it was a floppy, you could remove the floppy.) Not accepting the normal ways of stopping execution, when it's a destructive operation, and not explicitly warning the user that you're going to proceed even on the normal "stop" keystrokes... that's a really bad combination.

a1369209993 4y ago
> And it really meant "hit any key". Control-C? Continue. Escape? Continue. Ctrl-alt-delete? Continue. `Hit any key to continue or any other key to quit.` "Wait, which one's the any key?" "Better question: which one's the other key?"

partdavid 4y ago

My problem with lots of these experiences is that they're still boilerplate (whether verbose or not) and require me to apply a conditional that the computer should tell me about. For example, quitting a game: "Are you sure (Y/N)? (Unsaved progress may be lost)" Don't tell me that. Tell me whether unsaved progress will be lost and what it consists of. Likewise, when I'm typing a description in JIRA and want to follow a link "Are you sure you want to navigate away (Y/N)? (Unsaved changes may be lost)" Wait--do I have unsaved changes? If so, what are they? That's what I should be basing my decision on--what specifically will happen if I click Yea or Nay? Not a general exhortation to be careful because waves hands something bad might happen: YOU get to figure out if it will or not!

Jerrrry 4y ago
Windows Notepad has gotten that right since inception, but a more detailed report of the magnitude of action/changes/loss would definitely be a trivial and welcome feature. I think the overall idea is that smaller dialog in prompt boxes are somehow better to avoid "warning/agree fatigue" but ultimately it worsens the overall clarity of the function and purpose.
- partdavid 4y ago
  Sure, it would have to be thoughtful, careful, context-dependent and possibly optional (e.g. a "Details" toggle or something). But it would still be so much more useful to see "Do you want to navigate away? (580 characters of Description and two other fields will be lost)". Or "Do you want to quit? (0:28 mins of play will be lost)" versus just quitting when nothing will be lost because the auto-save is up to date. Just warning that something may or may not be destructive and leaving it up to me to guess how things work feels lazy to me, as a user. As a developer, I understand it entirely! And it would help avoid warning fatigue because the warning only appears when something actually is going to be lost--and then you can decide whether to keep it or not.
  - account42 4y ago
    > But it would still be so much more useful to see "Do you want to navigate away? (580 characters of Description and two other fields will be lost)". Or "Do you want to quit? (0:28 mins of play will be lost)" versus just quitting when nothing will be lost because the auto-save is up to date. For games, you could perhaps even omit the warning entirely if you just saved manually.