[leapius]

How about instead of two email input fields you do this:

One email field, when it loses focus (or you submit the form) a pop-up displays the email you entered and asks you if this is correct (Y/N). If you hit no then it focuses onto the email field for the user to make changes, and repeat.

The second field is just about forcing a user to be careful so why not make it a bit easier with a simple 'Yes' click instead?

[chilldream]

Based on everything I've read about how often people actually read pop-ups, that sounds like it would make things more annoying and help nothing.

[leapius]

well if you have a question blocking the submission of a form the user would have to acknowledge it and surely click 'yes' is less annoying (and time consuming) than having to re-type the whole address?

[chilldream]

Not for people who were happily navigating with their keyboard. Not for people who were going to copy/paste anyway. Not for people who wanted to look at something in another tab before finishing your aggressively self-important webform. Not for people who will inevitably accidentally hit something in the dialog before even seeing it because they were typing too fast and it accepted their keyboard input. Not for people who will resent you on principle for stealing their focus to stop the proceedings with idiocy (google it). And certainly not for the people who are so tired of dialog boxes that they've given up on reading them altogether.

What you want: User reads your dialog box notifying them to double-check their email address.

What actually happens: User maybe looks at your dialog box just long enough to figure out what it is before clicking whatever they think will make it go away. A tiny proportion of anal-retentive users who would have never gotten it wrong in the first place actually do what you asked them to do.

http://arstechnica.com/security/2008/09/study-confirms-users...

> Follow-up questions revealed that the students seemed to find any dialog box a distraction from their assigned task; nearly half said that all they cared about was getting rid of these dialogs. The results suggest that a familiarity with Windows dialogs have bred a degree of contempt and that users simply don't care what the boxes say anymore.

http://mikepope.com/blog/DisplayBlog.aspx?permalink=480

> It's not that users are morons or that they "forget" to think. Its that users are trained to not think... dialog boxes usually say "If you want to tech the tech, you need to tech the tech with the teching tech tech. Tech the tech? Yes / No" If you press one of those buttons, something happens. If you press the other one, nothing happens. Very few users want nothing to happen -- in the majority of cases, whatever happens is what the user wanted to happen. Only in rare cases does something bad happen.

http://blogs.msdn.com/b/oldnewthing/archive/2003/09/01/54734...

> If you are trying to accomplish task A, and in the process of doing it, an unexpected dialog box B appears, you aren't going to stop and read and consider B carefully. You're going to try to find the quickest path to getting rid of dialog B. For most people, this means minimizing it or clicking "Cancel" or just plain ignoring it.

http://www.joelonsoftware.com/uibook/chapters/fog0000000062....

> This may sound a little harsh, but you'll see, when you do usability tests, that there are quite a few users who simply do not read words that you put on the screen. If you pop up an error box of any sort, they simply will not read it. This may be disconcerting to you as a programmer, because you imagine yourself as conducting a dialog with the user. Hey, user! You can't open that file, we don't support that file format! Still, experience shows that the more words you put on that dialog box, the fewer people will actually read it.

http://alistapart.com/article/neveruseawarning

> What about making the warning harder to ignore? A subtle warning will get passed by, so let’s pull out all the stops: we’ll blink the screen and play a loud stretching noise to ensure that the user is paying attention. Try as we might, it still won’t work. The more in-your-face the warning is, the faster we’ll want to get away from it (by clicking “Okay”) and the more mistakes we’ll make. The thing is, no matter how fully in-your-face the computer presents the warning, we’ll still make the same mistake—clicking “Okay” when we don’t mean to.

http://ignorethecode.net/blog/2008/10/31/nobody-reads/

> We all know that people don’t read dialog boxes, yet when there’s a problem with our UI, when people don’t understand what they’re supposed to do or when they do something wrong, we tend to try to solve the problem by adding more text to more dialog boxes.

[leapius]

I take your points but I still think dialogue boxes are important additions to interfaces when used right. What about a delete function, which is genuinely accidentally clicked upon? Should we go ahead with a damaging delete instead of issuing a warning? Adding duplicate fields to fill out is a massive pain to all users, that cannot be denied.

My idea wasn't to invoke a dialogue pop-up but rather a visual light-boxed div pop-up in that tab, which wouldn't take control of the browser. They click no then they don't get to continue, yes next time they might just hit yes to proceed without reading. But as with duplicate field entry this is just about making an attempt to get accurate data from the user with the minimum of hassle.

[chilldream]

Ah. First let me apologize for incorrectly assuming you meant "popup" as in "JavaScript `alert`." Technically speaking, the thing you describe is no longer obnoxious.

In your hypothetical case of a delete feature, if it's something the user doesn't click on a regular basis, and if you can't offer an Undo feature (as explained in one of those links above), then it could be fine. Even if it's a focus-stealing JavaScript popup. You have to be careful not to put it on common tasks, though; if the user sees it all the time, they'll train themselves to blindly click through. That's explained in one of the links above.

In this specific case, I think it's still useless. You can't ask a user a question you just asked them and expect the answer to change. Even if the user looks at your dialog, they're usually going to interpret the question as asking "Are you an idiot?" and the answer is "No!" Even when it's "Yes."

It's analogous to the situation in tech support where the solution is something silly like "the battery is in backwards." Nearly no one will believe you thanks to the Dunning-Kreuger effect, so you have to ask them to open the battery cover and blow the dust out, hoping that they put it back in correctly (and yes, there are various reasons why they'll often be more careful than when they first made the mistake)

Someone else already mentioned the correct answer, which is finding an excuse to repeat their email address elsewhere in a context other than "Are you sure you said what you just said?" Imagine having an email address field near the top, then near the bottom of the form having a field labeled "password recovery email" with their already-typed email already filled in. Or maybe have a list of checkboxes saying "send the following types of communications to email address". And if they finish, have a confirmation page saying "Your activation email has been sent to address. If this is incorrect, click this link to fix it."

[leapius]

I really like the idea of 'sneaking' in a confirmation surreptitiously somewhere where they might take more notice. I do agree with your idea that if you confirm right at the point of initial data entry, the user could question if the program is itself an idiot. This is the problem with double address entry on the same form as well (is this program deaf or something?!).

In thinking through this problem I was actually applying it to a real-world scenario I am dealing with right now; Shipping / email address entry for a checkout. Barrier to entry (to making a sale) has to be very low and easy enough to complete an impulse purchase quickly. (No user accounts or registration - just let me buy the damn thing already!)

In this scenario I figured having a pop-up upon submission would not usually be expected (i.e. this is not an account registration) and so would maybe surprise the user into reading it.

However, I definitely agree when confirmation boxes are situated in well-trodden interface routes, they are pointless and annoying.