Hacker News Reader

Comment by psychometry | Hacker News Reader

Technically, they're both wrong. Button labels should be verbs. The Cancel - Open example from OS X is the right way to do a dialog box.

View on HN

It's awkward sometimes. AWX: "Are you sure you want to cancel? Cancel/Proceed"

e.g. Cancel cancelling / proceed to cancel. To me, that always seemed like a place where a simple "Yes/No" would be more appropriate.

Proceed seems to be the wrong verb here, as that dialog looks like it appeared after clicking a cancel button, and if I don't want to cancel I "return" to the previous screen where my data still is and don't "proceed" to somewhere.

That's what cancel does - you click proceed when you want to cancel. If cancelling isn't what you want, you simply click the button labelled "Cancel"

Clear as mud, right?

Well years ago at a convention I came across a little company that made Key caps out of Tempe, Arizona.

I bought a couple of bags of just two keys. Red panic buttons "Panic", and, "Any" keys.

We replaced the escape key cap with those when we sold new systems.

The "Any" key was a big hit and quite popular with the n00bs back in those AT (286) days.

I think I may still have a few of those around lolz.

I agree, but what's the use-case for such a dialog in the first place?

If there is a cancel button for a long running expensive operation it sounds like a good idea to confirm the cancellation.

Or if you are half way through paying for your cart, the merchant should check you really meant to press cancel.

Those verbs need nouns. Cancel what? Proceed with what? Most of the time, it's possible to make buttons self-explanatory if you give some thought to the choice architecture.

As andoid camera delete confirm does: [Cancel][Delete] Translated to my locale: [Zrušiť][Zrušiť] Verbs can be wery (un)helpful.

Not really, Ok can be a verb. You can “Ok” a change.

Technically, but it doesn’t tell you much about what you’re doing. Having the action be more descriptive allows users to act more quickly.

In that context "Ok" is merely a euphemism for "Accept", which would probably be a better label

At least it's not "Submit", which is just oppressive and demeaning. "Approve" would be more active and positive.

In all fairness, the "Submit" button in standard HTML is using the second definition of "Submit", not the first:

https://www.merriam-webster.com/dictionary/submit

1 a : to yield to governance or authority

b : to subject to a condition, treatment, or operation * the metal was submitted to analysis

2 : to present or propose to another for review, consideration, or decision; also : to deliver formally * submitted my resignation

3 : to put forward as an opinion or contention * we submit that the charge is not proved

It (the "Submit" button) is "present[ing]" (or "deliver[ing]") the form data field contents to the server. And in fact, myself, until I read your comment, never even considered the word in the context of the "yield" definition due to how it operates.

"Ok" for a change (that's described in the body of the dialog's text) is... okay, I suppose.

But it's better to mirror the action verb for your confirmation button, because users don't necessarily read the text you present them with. So, instead of this:

    Delete xyz.jpg?
    --------------------------
    The file 'xyz.jpg' will be
    permanently deleted.
    --------------------------
             [ OK ] [ Cancel ]

You have:

    Delete xyz.jpg?
    --------------------------
    The file 'xyz.jpg' will be
    permanently deleted.
    --------------------------
         [ Delete ] [ Cancel ]

And you get one more chance for the user to see what action they're about to perform.

There's very good, detailed guidance on this in the Windows design guidelines (the design-specific aspects are a bit dated since everything there refers to Vista/7-era UI elements, but their guidance on text and dialog styles is still applicable):

Text: https://msdn.microsoft.com/en-us/library/windows/desktop/dn7...

Dialog Boxes: https://msdn.microsoft.com/en-us/library/windows/desktop/dn7...

Yes, precisely. The worst UI I've ever seen was:

"Cancel this action?" "Yes" "Cancel"

Seriously?!

If you get lucky, it has a window close button on the right top as a safe way out. If you're unlucky... better have that power cable in reach.

Reminds me of this gem from Microsoft:

https://tech.slashdot.org/story/16/05/24/171215/windows-10-u...

> In a move guaranteed to annoy many people, Microsoft has "jumped the shark" on encouraging users to upgrade to Windows 10. Microsoft has faced criticism for changing the pop-up box encouraging Windows users to upgrade to Windows 10. Clicking the red cross on the right hand corner of the pop-up box now activates the upgrade instead of closing the box.

And people wonder why so many are concerned about the github buyout

I have a feeling pulling the plug would cancel the action.

Hmmm, maybe... or perhaps you get a call that their monitor doesn't work...

On reconnecting the power cable we find all files deleted anyway.

That also shows why the "repeat the verb again" can be more confusing. At least it wasn't "Cancel this action?" "Cancel" "Cancel"

On the other hand, I think Yes or No are clearly an answer to "Cancel this action?"

This is the edgiest of edge cases. Intuitively I would assume that such a dialogue box may be a UX smell and there could be better ways to perform a two stage confirmation.

Or you can just bend the UX rules for this one instance.

Or you can consider whether cancel is the best verb anyway; what about “end” or “stop” or “abort”?

The problem is in the verbiage of the question. A person writing a dialog should consider "Cancel" something like a reserved word in a programming language.

I've seen "Cancel this action?" "OK" "Cancel" before. Not fun either

I'm currently in the process of writing together some basic UI guidelines at work, and one of the special cases was exactly this: If the dialog asks for confirmation to cancel a process, it must ask, "cancel this process", and the buttons must be labeled "yes" and "no", never "cancel".

Actually "mirror the action verb" surprises/confuses me even more than "OK" "Cancel", since the latter are standard and almost expected, whereas anything other than a positive/negative response feels unexpected. It's like the real-life equivalent of asking someone a yes/no question --- you're expecting a yes/no answer. In fact, I'd say this is even clearer, putting the question at the end and immediately following it with the two choices:

    The file 'xyz.jpg' will be
    permanently deleted.
    --------------------------
    Delete xyz.jpg?
    --------------------------
                [ Yes ] [ No ]

...and this also coincidentally gives a reason for the order of OK/Cancel --- affirmation on the left, denial on the right.

> Actually "mirror the action verb" surprises/confuses me

To a certain extent, I would think this is the point of using this approach (at least for a "delete" action). I'd prefer the user to stop and think, "wait, what is this?" instead of just blindly clicking through.

Please force the reader to directly click an action verb. It is much easier to skip over text (even text that comes immediately before) misinterpret the dialog, and click the wrong button when using generic button labels "yes" and "no".

And more generally, before disregarding industry best practices and findings from research literature and implementing something based on ad-hoc personal hunches, make sure you run some experiments on real people.

industry best practices and findings from research literature

That's the cop-out answer I get whenever I ask about unnecessary and infuriating UI changes. It has only given rise to increasingly dumbed-down, stupifying interfaces.

Huh? It is a “cop out answer” to suggest reading the research literature as a general practice? It is an “unnecessary and infuriating UI change” to roughly follow UI guidelines written down by experts with decades of experience?

I am recommending that instead of just making something up based on the developer’s speculation and personal preference (which in your particular example happens to be terrible, as you would discover if you actually tested it in a real-world setting), it is a better idea as a general rule to go read actual user studies about what works and why, or if you are too lazy to do that go find some interface guidelines written by someone who did large-scale user studies and spent decades honing their interfaces in response to user feedback and copy it.

If you insist on rejecting those findings and past experience with a novel implementation, then I am recommending running your own mini studies (ideally something semi-formal, but at least test the two versions on a couple buddies at a coffee shop), to make sure you don’t shoot your foot off. To do anything less is in my opinion lazy and irresponsible.

Why do you think that will lead to “stupefying interfaces”?

You think that doing at least a tiny bit of user research before blindly rushing ahead based on personal preferences renders people unable to think or feel?

Or maybe you have a non-standard definition of “stupefy”? To be honest I don’t understand what you are trying to say.

which in your particular example happens to be terrible, as you would discover if you actually tested it in a real-world setting

My points all come from real-world experience, both as a user and developer. These unwanted UI changes irritate me enough to complain about them, but apparently my opinion doesn't count at all, because these so-called "experts" will only parrot their vague "studies show that X, therefore you are wrong"? These "user studies" naturally bias towards the worst of the worst. In fact, you are displaying exactly the sort of dismissive holier-than-thou attitude that I've been on the receiving end of, multiple times, and I can personally tell you that it really fucking pisses me off.

Think about it: if I'm the user of your software, and you change it so that it breaks my workflow, I am not going to be happy regardless of whatever justification you provide.

Having been on the receiving end of that, I've learned not to do it to my users, because I know how it feels.

I honestly have no idea what you are going on about. Nobody else is talking about “changes”, workflow-breaking or otherwise.

You said “In fact, I'd say this is even clearer, putting the question at the end and immediately following it with the two choices:”

Did you ever test this explicitly vs. the recommended alternative of using verbs for labels? (Ideally by doing a user study, but heck, I’ll take anything...)

I claim that this has been empirically tested and found to be inferior (i.e. result in higher error rate) in a variety of studies, both in published research and internal to various large companies which then got baked into their design guidelines. This was a subject of active research in the 1970s–1990s (and perhaps before).

You can find reasonably good advice about the subject in any number of introductory interface design textbooks, etc.

In this particular case, where user data is being irrevocably deleted, errors are especially harmful.

Edit: Maybe the word “terrible” in my previous comment was unfair. Sorry to be inflammatory.

I agree. When I initiate an action like "delete" and a dialog pops up, my mind is already assuming it's asking the question "Are you sure?" regardless of what the text says, and my eyes are just scanning for a "Yes" or "No". I would give preference to it being on the left (probably because "yes or no" is so ingrained... when's the last time you heard someone say "Answer me, it's a simple no or yes answer!"), but, realistically, if the buttons are close together I'm reading them both at the same time while my eyes are still moving toward them. As in many reading contexts, my brain knows the shape and length of the words I'm expecting so I'm mostly on autopilot until the very last moment.

If the action is to move forward with something or not, I think I prefer the "next"-type button to be on the right, and "cancel" or "back" on the left, probably far left.

But, my thinking does violate the "pick one and be consistent" suggestion. So... I dunno :)

When you initiate action like delete, you might be thinking “yes/no” in the moment, but you couldn’t possibly argue that “cancel/delete” is less intuitive or breaks flow.

And we don’t always react to confirmations instantly. What if you’re distracted away, or you suddenly second guess your decision and perform some auxiliary research? Or what if you have more than one dialogue box on the screen at a time? From a UX standpoint, it is far safer to repeat the verb rather than use a generic.

To be frank, the only reason why I could imagine using generics is laziness.

A problem with Yes/No (and OK/Cancel, etc.) is that one program will ask

    Unsaved changes will be lost. Save your changes first?

and another program will ask

    Unsaved changes will be lost. Are you sure?

Or within a single program, "Yes" will be the safe option everywhere except one place where it's the dangerous option because nobody thought about that.

If the user is exposed to one convention 90% of the time, the other one will always cause some confusion and feel sloppy.

What about "Yes, [Action]" and "No, Cancel" to get most of the best of both worlds?

Better:

  Delete xyz.jpg?
  --------------------------
  The file 'xyz.jpg' will be
  permanently deleted.
  --------------------------
          [ Delete xyz.jpg ]
            [ Keep xyz.jpg ]

Action buttons sometimes need to be single verbs for the sake of brevity. A verb-noun pair is much more legible than a standalone verb. Self-explanatory buttons are usually preferable to buttons that depend on explanatory text.

In English, you can verb any noun (https://en.wikipedia.org/wiki/Conversion_(word_formation)#Ve..., https://www.gocomics.com/calvinandhobbes/1993/01/25)

One can verb nouns in lots of languages, English just happens to have "0-derivation" verbing of nouns ("photoshopped the picture", "googled Dan"). As well as "0-derivation" nouning of verbs ('did the user submit an "ok" or a "cancel"?').

> Ok can be a verb

My gut feeling is that when written as a verb, it should always be the longer form, ex: "I will okay it, like I okayed the last one."

I believe it's from the same writing-sense that intuits "I have three main points" as superior to "I have 3 main points."

>Button labels should be verbs.

According to who? Why? I've never heard this before and it doesn't sound like a remotely necessary rule.

Because verbs are actionable.

Maybe you forgot to read the article? All of the (non-obsolete) screenshots of Factorio have verbs, except for "Back", which is pretty clear to me.

No, I read the article. That's how I was able to directly quote an example of a dialog where not all of the buttons are verbs.

Reply on news.ycombinator.com