Don't auto focus on OK button

[quasipickle]

In 100% of the cases I use a confirm dialog, I am making double sure the user wants to take the action they just indicated, because the action is dangerous or has big consequences. In these cases it's dangerous to have the OK button focused by default, as I want the user to do extra work to complete the action.

Can alertify get a new property, say focusOn, that allows one to set whether the focus should be on ok, cancel or none?

[fabien-d]

There's more to it than simply removing focus on the button (from a code's perspective). The ENTER and ESC keys are also bound to the buttons. This means you can click OK and Cancel via the ENTER and ESC respectively even if the buttons don't have focus.

I am making double sure the user wants to take the action they just indicated,

Agreed, that's fair and a common use case

as I want the user to do extra work to complete the action

Not sure I agree with this. Having to click twice (once for the initial action and once to confirm in the dialog) seems sufficient and standard practice. Taking away the ENTER key event, to me seems to go against best UX practices.

I'd love to hear people's opinion...

[quasipickle]

@fabien-d I guess I just view "clicking the button" as a more intentional action than hitting enter. For less savvy users (of which I have many), it is not completely obvious that hitting enter will confirm the action, whereas clicking the button is very clear.

My use case is: my user wants to disconnect a client's internet account. The user should click once on the "Disconnect" button, then once on the confirm dialog. With focus on the OK button, they only need click once, then hit enter once.

I realize not everyone will have this use case, which is why I suggested making this an option, not changing the default setup.

[dparlevliet]

I would agree that having it optional, with defaulted to on would be useful in some situations. But I'd encourage an alternative prompt box instead. We all have this need from time-to-time to alert people of dangerous actions so maybe a keyword repeater prompt would be good to include in alertify?

For instance, in this case, you could have an alert box come up with the message, but the confirm button is disabled until the keyword "Disconnect" (case insensitive, of course) has been typed in.

Just throwing it out there.

[fabien-d]

@quasipickle

With focus on the OK button, they only need click once, then hit enter once

I still think less savvy users (if primarily a mouse user) would not necessarily assume a focus state to the ENTER key and go from clicking a button with the mouse followed by an immediate ENTER key just because the button is focused.

The implementation of the native confirm dialog has OK focused by default. Maybe @dparlevliet is on to something. An extension of the confirm prompt which requires an actionable item (e.g. checkbox) before a user can confirm or deny.

Still not sure it's needed, alertify is already rapidly growing in size (want to optimize and shrink it) and want to make sure that all features implemented into the core are valuable to the majority of users and not unique cases.

Maybe starting an extension library would make sense and would also provide options for #39 and #70. Doesn't ship out with the core but extensions could be added as dependencies for users you want extra features/dialogs. Just a thought...

[quasipickle]

@fabien-d The innocuous nature of the enter key to non-savvy users is part of the issue. My desire is to have the confirm box be a double-check for the action. I want the user to think "Yes, I want to take this action". Clicking the button ensures they've made that thought. They might not think hitting enter means they want to do the action.

If I can get this newfangled Github thing figured out, I'll submit a pull request - I don't think this feature should contribute to bloat at all.

[fabien-d]

Feel free to open a PR, it's usually easier to have a discussion around physical code! Just follow the info on submitting a PR!

[quasipickle]

PR sent

[dparlevliet]

I agree about not including optional extras as part of the core so I agree a extension library would be best. If nothing is set up by the time I get to the area of my project that needs those sorts of extensions then I will submit a PR to get you started. Also, I also second the PR sent by @quasipickle. Having that option would be good.

[fabien-d]

Awesome @dparlevliet.

More food for thought, maybe instead of an extension library, a custom build would be better? Ala Modernizr.

That way you could essentially just include the exact functionality that is needed and nothing else. (e.g. just dialogs, just logs, add extras...)

[fabien-d]

Closing with ^ pull request