Solving the "Repeat Email Address" Form Issue. Maybe.

One of the mailing lists that I’m on had a question posed today about using “Repeat Email Address” in form validation.

I actually cringed as I typed that just now–that particular part of form validation is pretty annoying (to me, at least). I find it amusing that shift-tab, copy, tab, paste as a method for handling doesn’t cross anyone’s mind when creating these types of “validations” in forms.

There were a number of responses to the thread, but Steve Krug (yeah, that Steve Krug) put out the notion that he suspects most of the email address typos may originate in hasty typing, and they end up getting submitted because the user doesn’t realize that they’ve made a mistake.  Krug identifies that it’s possible, from his perspective, that the font used in many forms is fairly small and that makes it so that errors don’t actually jump out at the users.

Krug also suggested that it may be possible to help users catch the errors by displaying the email address in larger, clear monospaced font–possibly next to the or below the field where the typing occurs.

This stuck with me, but I wasn’t quite sold.

I pinged my friend Jonathan “Yoni” Knoll to see if he’d loan me about 15 minutes of his time to prototype something.  Lucky me, he had just that much time to spare.

We (and by we, I mean Yoni) put together a really quick prototype form–it’s important to note that we didn’t put much more than 15-20 minutes into this, and this is only to see how the form “feels”.  It can grow a number of different ways, styles and placements of elements can certainly be shifted around to your heart’s content.

The form looks pretty, uh, form-y:

Blank Form

Note at the bottom of the form the tiny little text letting you know that you should check your email address. In reality, I’m pretty sure most of us wouldn’t read it.

Also note that there was no “Repeat Email Address” text field in the form.

Instead, once you fill out your email address and tab away from it…

Form with Email Address

Notice that now my email address appears right before the Submit button.  Krug initially suggested that the re-display of the email address might work best in a larger font next to the field where you entered in your email address.

The way this placement works now, in the prototype version that Yoni and I worked-up, the last thing you see before you submit is your own email address.  I think this works particularly well in longer forms–it gives you the opportunity to re-check the most important piece of information in the form (to marketers, at least) right before you hit submit.  The little “edit” link jumps you back to the field where you can make edits quickly and continue on with the submit action.

See this live in action here:

Remember: this is a prototype.  One of the reasons that the edit link is to the left of the email address is because, after a couple attempts at placing it, this made the most sense to Yoni since email addresses are variable and that could cause the placement of the link to not always be in the exact same place.  Your mileage may vary; something may work better for you.

The important piece of this prototype is seeing how it works in action, and how it potentially solves for having the “Repeat Email Address” field in your forms.

Tinker with it–and let us know what you think!

68 Responses to “Solving the "Repeat Email Address" Form Issue. Maybe.”

  1. Love it. Wondering if it would screw the code up too much to have field validation in that field as well (ie when user moves to next field, it checks that typed in info contains @ for example and if not the line above submit could indicate the error instead of or in addition to inline warning).

    Kudos for trying this out


  2. I’m pretty sure we could validate to make sure that the field is at least as close to “properly formed” as possible given the @ sign. I wouldn’t see any problem with doing that, as well–especially in the case where it’s a required field, too.

    Glad you like it!


  3. Cool! I’ve been wrestling with this lately as we’ve been working to re-vamp a sign up form on our app. I hate having extra fields to complete and this is an interesting idea. Props to you and @Yoni–thanks! 🙂


  4. The root problem is that a typo in the email address is difficult to catch after the form is submitted. This comes from the email protocol; there is no “mail server, please check this address” provided for. If the email address was off by one character, then the web server cannot discover that reliably.

    So you are proposing that if someone mistypes their email address that they will recognize that typo when they see the address displayed in a large font. Then they will go back and correct it.

    I think the question of how many people first mistype their email address, and then secondly recognize their mistake, can be measured quite accurately with tests and different populations — instead of guessed at.

    To me personally, when I am prompted for email-confirmation, I avoid the copy-and-paste shortcut and recognize the opportunity that the server will check for typos, and that a typo might cause trouble for me personally, and so I try to be more careful.




  5. @Stephan I think that your logic is flawed around the “who” are the persons mis-typing their email addresses.

    There are too many variables at play–an email address is more than likely going to be spelled correctly more often than an email address. Why do I suspect this? I used to mis-type my email address quite a bit, but almost never mis-type

    Too many factors at play there, in my humblest of opinions.

    We all agree where the typo issue comes in to play, and what we’re looking at currently is the inconvenience and work-around factor to users.

    I’d be interested in seeing the results of your test, and I’ll be sure to share any findings that come from this little prototype that we’ve come up with.


  6. Russ / Yoni, beautiful work – really like it.

    @yoni why would you jump the user up in the form instead of doing an edit in place and replacing the value in the original field?

    By increasing the font size and positioning the feedback at the end of the form you force the user to do a double-take which is great, but if they made a mistake because they just didn’t ‘see’ it, it’s easier to correct right then and there then taking them back up to the original field where they made their mistake.

    @Liv I think doing on-tab validation is smart to combo this with, however I would display results (error messaging or any feedback) immediately below the field of the right of the field thus keeping the link between field and messaging so as to allow the user to correct whatever went wrong without having to move their focus between different content areas. IMHO.


  7. @Eduardo NOT editing in place was a request from me.

    My intention–and this could be wrong–was to keep the text you are reviewing away from a form field and close to the submit button to prevent any sort of “repetition blindness” from happening.

    I don’t know that your view or mine is right here, and this is very much a prototype, so that type of feedback is great. I’m working with a couple of folks and we’re hoping to get some additional feedback and testing around this.

    If nothing else, it’s an attempt that may get people thinking a bit differently!


  8. I definitely like the idea, I’ll see if I can work it into some of the registration stuff I’m currently working on — I’ll post comments if I can work it in.



  9. @livlab: Yes, validation would clearly be a boon, and a very easy thing to add as well. I’ve always thought it’d be useful to do some extra checks (possibly with Ajax) to double-check the validity of the domain.

    @eduardo: In-line editing/correcting is obviously an option, but I’d like to do some user testing on that before implementing it. Personally, I suspect its value would depend on the application, and, more specifically, the types of users; it might work great for users like us, less so for less techy users. I’d also be concerned about providing adequate affordance for such a feature without creating confusion. If it were left as a pre-populated form field, it might be as easily/quickly dismissed as so many other great ideas.

    BOTH: I’m all for on-blur validation, particularly for input errors that can be checked against a gold-standard of some sort. But the key “feature” here is, ultimately, a supplementary form of self-validation. Maybe it’s a step in the right direction; maybe not.

    Also, I believe the overall size, nature, and visual style of the form could both enhance or degrade this feature. Would love to experiment with several other variations.

    ~ yoni


  10. Awesome concept Russ/Yoni. It would be really interesting to test this by rigging a keyboard to always mistype one letter and see how many users catch the mistake?


  11. I tried it out a couple of times, transposing the letters in my often-transposed email address and the display made it much easier to detect.
    Have you thought about adding a thin border around the email validation indicator, to call it out on its own (I can see myself noticing the mistake as I’m simultaneously clicking the submit button).


  12. It feels too clunky.

    What if the verify email is moved to a confirm page.

    Thanks for submitting blah blah blah
    ————————————- is this correct? edit email

    If there is no change they close the window the original gets used. If they edit it then that gets used.


  13. I remember when I first got on the Internet I got a great deal of immature glee out of “fingering” people’s email addresses. (“Pinging” them just wasn’t as fun.) Why, in this age of AJAX, can’t we do something like that when the field loses focus? Just send a quick finger or ping to the email address to see if it exists? If it doesn’t, which it likely wouldn’t if the error were made due to hasty typing, then display an error message. Is this at all feasible or am I smoking an asynchronous crackpipe?


  14. @fred: Technologically, I’m not sure, offhand. But even if it were feasible, it still leaves too much room for error. Insted of user error, it become server (any one of many) error and or delays. Of course, perhap we could just “try,” but I’m not sure we’d get sufficient error-correction return on investment (time, server hits, case handling, etc.). I’m a big fan of simplifying/minimizing the process as much as possible, and since fingering (or some such) could never be 100% reliable, I’d consider that a supplementary enhancement, rather than a core feature. This is why I like the idea of checking against something simpler (like domains), so we might suggest, rather than force and/or overtly nudge.

    Or, I could be totally off-base and wrong.

    ~ yoni


  15. Nice!
    I had two people watch me filling out the form. I entered my address incorrectly, continuing through the form. I asked each person what they thought would happen when I clicked the ‘Edit’ link.

    #1: “It will open a little window where you can fix it.”

    #2: “I think it will open this same thing again in a new page.”
    Me: “Do you think my information will still be there?”
    #2: “No.”

    It’s just two people but I wasn’t surprised that they didn’t guess the ‘Edit’ anchor link would jump back up to the form field. This might be problematic especially on a longer form. I wonder about trying the Edit link to the right of the large email address display and having it say, “Edit email address above” or something like that.


  16. @julie a good point–but is their expected behavior based upon what they’ve previously seen?

    That is, I don’t think I’ve seen this before, and I’m not saying it’s right nor wrong to introduce it. But, what I’m asking is this:

    Did they understand what to do with the form once they clicked on edit?


  17. I like the concept of the e-mail address being the last piece of information one would act on before submitting a form.

    I agree with Livia that validation for a properly formed address would be a plus.

    Fred’s idea of supplementary live domain validation/finger functionality is a good one. This could be accomplished in the background during the time that it takes for someone to complete the rest of the form, assuming they aren’t using auto-form-fillers. In that context, there’s no reason I can think of that any server latency or timeout errors would need to be presented to the person filling out the form if a server throws an error. Yoni is right: it shouldn’t be core functionality.

    The one thing I don’t like about this prototype is the behaviour when one clicks the Edit link next to the address: it kicks the user back up to the original Email Address entry field (understood that this was a quick sketch).

    This behaviour breaks expectations for inline editing based on the standards for presentation that we already know and use. The kick-back to the original text entry field is a little jarring, and would be moreso on a larger form where the field scrolls off the top of the page. Inline editing that rewrites the original text entered would be a better way to go.

    (As an aside: I mistyped my e-mail address while filling out the comment submission form.)

    Great stuff Russ & Yoni!



  18. @Kaleem
    “The one thing I don’t like about this prototype is the behaviour when one clicks the Edit link next to the address: it kicks the user back up to the original Email Address entry field (understood that this was a quick sketch).”

    Just remember: The iPhone broke a lot of expectations.

    This is no iPhone, by any stretch, but if it breaks you from using a copy/paste method for your email address and/or it helps you catch an error, then following alleged “best practices” might be the wrong thing.

    Mind you, I’m arguing for this approach while still saying it’s far from perfect. I do, however, contend that breaking out of an expectation can sometimes help drive toward a better solution.

    Thanks for the feedback/comment!


  19. OK. So I’ve made a couple changes based on the feedback. I have a couple more tweaks to try out, but feel free to play with it some more, and offer your thoughts/suggestions. (I suspect I might’ve accidentally introduced a small bug or two.)

    Just remember, this is still just a sketch — barely a prototype. It’s ugly (both visually, and the code behind it). Still just feeling out the possibilities/issues.

    ~ yoni


  20. @Russ

    Fair point re: expectations.

    I like the idea and general approach you and Yoni have come up with and I’m definitely for breaking out of the copy/paste method.

    My objection doesn’t stem from alleged “best practices” or breaking out of expectations, either — we’re of the same mind on that and I’m cognizant that this is a prototype.

    Instead, it comes from anecdotal evidence and observations that the inline editing behaviour (where clicking the Edit link lets one edit the display text immediately adjacent — in this case, the e-mail address displayed above the Submit button) is just starting to be widely understood.

    The answers around form/link behaviour expectations from Person #1 and #2 in Julie’s comment seem to support the notion that not everyone understands what that Edit link next to display text means.

    Confusion is not a good thing when trying to accomplish a specific task like completing a form.

    That said, I don’t know if the kick-back to the original field will prove to be a better behaviour vs. the inline edit or not. Intuitively it feels wrong.

    Proximity of action to the instantiating link seems to make more sense, IMHO. Perhaps that people don’t yet fully understand what that Edit link means opens it to a new behaviour as implemented here.

    Thanks for the opportunity to discuss this idea! I’d love to talk about this more in person with you, Yoni and Luke when you’re in town next week. In the meantime, keep at it. You’re definitely onto something.



  21. Cool thought, we were also struggling with the same problem and implemented somewhat inline what you guys have done, we put the email address with inline edit functionality on next page with confirmation message, suggesting user to recheck email ID.
    *there was always the thought that some people does not see the confirmation message very closely and can miss this though we tried to make it clear visually.

    we didn’t thought of putting on same page, will try in my other project 🙂


  22. Maybe this is too simple or I missed it in the comment, but is there any reason you can’t ask for the email as the last field in the form instead of the first? That puts it even closer to the validation.


  23. @Jen: the problem we’re trying to solve is avoiding the need to type your email in twice to avoid mistake caused by typos and some such. I do not believe simply moving the field will solve this, as the user is not encouraged in any way to double-check for mistakes.

    Perhaps you do disagree with the original design problem as formulated?

    ~ yoni


  24. Was thinking about this and wondering what kind of errors are more common in mistyping an email address; username, domain or lack of ponctuation (@ & .) – any hunches? I’m wondering if there would be additional benefit in differentiating parts of the email address with different colors as a visual aid for quick check of correctness.

    Thanks for doing this; it is rare that I get to think about innovating at this level of granularity in the UI 🙂


  25. Also wondering if above concerns about ‘edit’ setting an expectation of editing in that spot could be resolved by labelling it ‘change’ or a variation. I suspect the label edit setting this very specific context is something people are being trained to do in new apps (seems to be from my observation) whereas change or another label may be general enough to help introduce this new type of interaction.


  26. @livlab: If you wanna think through some more variations/possibilities with us in Toronto, just lemme know. 🙂

    ~ yoni


  27. As one who never got his registration information for a conference because an administrative assistant mistyped the domain in his e-mail address the same way twice, I appreciate this attempt to overcome form blindness. After all, she got my name right (which is hard to do if you didn’t grow up with it) — it was a four-letter initialism that her e-mail address has in common with mine that got muddled. It works well for me. I’m curious to see what testing reveals.


  28. Now that I’ve tried this a little more, I like versions 3 and 4 better than 1 or 2. It’s great to be able to make a correction right where the error came to my attention.


  29. I’m thinking the user will spend just as much time reading the new supplemental text “Please make sure your email address is correct so we can get in touch with you”, scanning the edit button, and verifying the email address, as they would re-typing the email address. The user may also spend a second or so thinking about why they are verifying an email address that is not visually associated with the one they typed. This presentation I feel may even make the user think there was an error, as the larger text almost appears as an error or something out of context within the form. Just my opinion. Thoughts?

    Also, I know it is established that re-entering the email address is “annoying” which I agree. But are we trying to solve a form completion time issue, or an error rate issue. If it is an error rate issue, has it been established that the re-entering of the email address is not effective?


  30. If the user slows down and looks/verifies the new field at the bottom–which, again, I suspect that by simply moving the second field to being next to the submit button will remove what I’m calling “proximity blindness” from the original field–then, that’s great.

    I don’t think this is an issue of how long it takes, it’s an issue of forcing accuracy via a redundant text entry field.

    What we’re trying to solve here is…

    Finding a better solution. I’ve yet to see anyone say that the email address repetition isn’t annoying.

    As for your suspicions, I suggest you test them–that’s what the examples are for. I don’t think you’ve introduced anything new to what we have, so feel free to direct some folks to the various forms and let us know your results.

    Others have contacted us about putting these, or variations, into testing or showing their clients. We fully support this and hope it’ll provide additional information.

    Otherwise, we’re all just having suspicions and pontificating.


  31. After using all 4 forms, I have come to 2 conclusions.
    1. I like the idea of not having to repeat typing in the email address. I have thought about this issue on several occasions. Therefore, I like the attempts made here to solve this problem directly on the page without having to leave the page to confirm on another page before submitting.
    2. In all 4 examples, I am not too fond of the fact that my eyes automatically jump from the top of the page to the bottom of the page where new information is populated for me to confirm, and then back up to the top of the page to continue filling out the form (even if this is not the intention, my eyes automatically and involuntarily are attracted to the new bigger, and different colored font.
    Also, the statement “Please make sure your email address is correct so we can get in touch with you.” is already populated at the bottom of the form away from the very field it is addressing.
    This is an important message and needs to be upfront for the user to see. Because users tend to make mistakes filling out forms we need to get this message across to them to immediately get their attention. By doing this, not only will you address the email issue, but now the user is alerted to pay extra attention when filling out the rest of the form.
    To solve these issues, I humbly present my rendition of the form taken from version 1 of the 4 samples provided.
    (I already know that Russ and Yoni have only proposed this to the group as a pioneering design and are not saying “this is the be-all-end-all, and neither am I. I am only building upon what Russ and Yoni have had the fortitude to address.)
    Please review:

    Keepin with Russ and Yoni idea, I think a better way to solve this issue may look like this.


  32. Hey Brett–

    That’s one we looked at a bit, but it didn’t resolve “proximity blindness” (to us). I think it’s important to consider it thought–and I’m glad you brought it up!


  33. Thanks Russ,
    I know exactly what you are trying to address. In my experience, (and by the very subject addressed in your post) I’m not too sure that “proximity blindness” is an important factor here when we’re only addressing one field. (I could understand if the subject matter was a number of issues spanned out throughout a form rather then just one issue).
    However, I do understand the reasons for your thesis and if your proposal (including Yoni’s) turns out to produce increased results, you can be sure that I will be implementing this style knowing that it has survived the fires of scrutiny.
    God I love this field.


  34. If you’re going to try and understand if this increases performance then you need to be careful. Right now the standard is of course to repeat the email address input field (or simply to not to).

    With something popping up it would, I imagine, lead to increased awareness of needing to verify the email is correct. But how long will this last? Did repeating the email field decrease the instances of errors in the beginning, and then fell back because people (like myself) would rather resort to the quicker copy and paste method (and get frustrated when some developers try to block that, I might add)?

    If it’s different it will get noticed, and therefore it will appear to “work” when adoption starts, will it work in the long term should it become standard practice? My gut feeling is perhaps slightly but ultimately not significantly.


  35. Do people read “submit” buttons?

    Why not:
    (1) Have a really big submit button
    (2) Make the submit button text read: “Send confirmation to

    Here’s an example (e-Commerce scenario):



  36. Stephen–

    I love that!

    The only issue in this case (and it’s not an issue, I guess) is that if you’re NOT sending an email.

    It’s a registration and it’s all self-contained for whatever reason? You’re signing up for something…


    Okay, maybe you’re exactly right.

    Yoni! We’ve got some work to do!

    Thanks for that comment!


  37. Just noticed Vimeo, in their ‘sharing’ popup, have you confirm the email of recipients by typing (validated), then clicking the name to add to a separate field.
    Not ideal, and has a few bumps, but perhaps another model to watch?
    e.g. > “Share”


  38. @stephenanderson: We’ve added a version to reflect your idea. Whaddaya think?

    ~ yoni


  39. Awesome!!

    Nice to see this get implemented so quickly– you rock!

    Two comments:
    1. Make sure to include affordances that communicate this is a button

    2. Language could be refined based on context/action. For example, instead of “Submit with address:” I’d use something like:

    “Register as [email]” (if email = username) OR
    “Register with [email]” (if email + username)
    “Send confirmation to [email]” (if registration requires email confirmation)



  40. Really interesting approach, and I love the Stephen Anderson’s idea for the button label.

    I’m wondering how this solution would be presented if you had to enter email address/repeat email address and password/repeat password.


  41. @stephenanderson: Yeah, we actually discussed this a bit, weren’t sure which way to go. Thing is, the form we’ve got up is generic. It is literally without inherent purpose, thus incorporating action and/or context while obviously vital to any form’s function (in fact, its existence), I’m concerned about skewing the impression/impact of the prototype if we add this. Of course, another option would be to create a set of form examples, each contextualized differently, so we could get a feel for those effects as well.

    Thanks for the great ideas!

    ~ yoni


  42. @stephenanderson: Excellent. I love the “read the button” approach as I have here:

    It is a fine thing to witness the innovation of design proposals and solutions.


  43. […] Kaynak: […]


  44. Version 5 is what came into my mind immediately when I read this post. However, I would alter the design of the submit button and display the contained e-mail-address in a larger font. Or, in other words: (small) Submit with address (linebreak)(strong), plus an appropriate icon within the button.


  45. Perhaps the problem is that people who need to fill out forms don’t understand why we ask for the information we do. Validation is in their interest, yet we never explain why we want folks to fill in something twice. The fact, Russ, that you use copy-and-paste to fill out the second form suggests that your goal is to get through the form fast, but not necessarily correctly. For my own part, I used to do the copy-and-paste bit, until I copied something I had typed wrong. It took forever to straighten things out.

    We need to be designing forms that folks want to be correct, not just forms folks want to go away.

    I found the discussion of the “edit” button amusing. The fact is, people expect to be able to use skills learned on one site and apply them on another. Although annoying, I’m not sure you’ve really solved the basic problem of e-mail validation, but you certainly have introduced some new cognitive variables.


  46. Turning the Edit link into a HTML Label for the Email Address field would save some JavaScript work.


  47. I like it (version 1) a lot. However, I could see myself making the mistake of looking at the email address _while_ clicking the submit button, and at that point discovering a mistake is too late (although not disastrous, since I can hopefully go “back” to fix it and resubmit).

    Also, forms that can be submitted by pressing Enter won’t be helped by putting something near the submit button.

    Still, I think this beats “Repeat Email Address”.


  48. I agree in that the problem is not necessarily about time, although that is a factor. The main problem is accuracy. People cutting and pasting a mistyped email address is still a problem with the repeat. I personally like the edit link because links are so universally understood. I would like see testing to see if proximity is a problem. If people are afraid to click on the link, that’s an issue.

    Also, I see a lot of people writing about what they think they would do. I fall into that habit myself, but think it’s important to remember human factors/usability rule #1. Know thy user, and you are not thy user.


  49. […] Solving the “Repeat Email Address” Form Issue. Maybe. UserGlue UserBlog (tags: usability forms ux uxd ui) […]


  50. […] after IDEA, Yoni and I worked up a few samples for how to tackle the Repeat Email Address issue. It was wild to work on something like this together–sketching ideas in IM and code and […]


  51. The link doesn’t work, but the concept is clear. I believe this is a very good idea! Thanks.

    P.S. Placing ‘Edit’ to the RIGHT is ok since users get to see registration form only once (hopefully) and it’s OK if ‘Edit’ would be placed differently for shorter or longer email.


  52. Oh and one more thing. I believe that displaying 2 email fields isn’t that bad an idea since even if you copy/paste you get to see your email more often.


  53. I think this would help a bit, but I’m not sure that font size is the problem. I think people see their own e-mail address so much that they don’t read it anymore, no matter how big it’s displayed. It’s just a blur of characters. I know this is true for highly frequent words like ‘the’: research shows that people look at them as units, not as sequences of letters.

    I think the real solution is in the browser offering to autocomplete or even prefill your e-mail address in a form field called ‘E-mail’. That way, you fill it in one time carefully, and then never think about it again. Firefox does this out of the box in many cases (but not in the e-mail field for this comment, for example).


  54. I liked the concept but found the behaviour of the “edit” link confusint. I’d expected it to let me edit the larger text at the bottom directly. I didn’t notice the change in focus to the email field until after I’d clicked it a couple of times.



  55. I think there is a danger of over engineering this problem – for such a small problem. User generally don’t mind entering their email address twice. However having looked at the 5 versions of the prototype, version 1 is by far the clearest and least obtrusive. As you mentioned, it definitely would hold more value on longer forms.

    Nice job.


  56. […] userglue – na końcu formularza wyświetlany jest podany adres, z prośbą o weryfikację.UserGlue UserBlog » Blog Archive » Solving the “Repeat Email Address” Form Issue. Maybe. – Via BuzzIt!Posted in google buzz Leave a Reply Click here to cancel reply. Name […]


  57. I would recommend updating the email “preview” on keypress.

    If a user gets their email wrong the first time, then clicks the edit link returning cursor focus to the email field, they may type it incorrectly again and click submit missing the opportunity to see their mistake (except for on the dialog after submit which I assume is for test purposes).

    Otherwise, solid solution to an annoying problem.

    – Jordan


  58. […] Dialog also suggested this as his preferred solution. Another idea that Dan Naumman sent me was this one that suggests repeating the email address at the end of the form before the final submit button. I […]


  59. […] One Consulting wordt echter geëxperimenteerd met een nieuw interessant patroon, in het artikel Solving the “repeat emailaddress” form issue. Steve Krug merkte namelijk in een discussie op dat de veel verkeerde e-mailadressen wellicht het […]


  60. Re version 5:
    When I came as far as to the submit button, I started to read “submit” and went autopilot to push that button without reading the whole text. Others might react differently, this was just my reaction.

    Interesting discussion and prototype.


  61. Very useful article. I think submit button must be there from the beggining. From my point of view that is the only version that may confuse users.


  62. […] One Consulting wordt echter geëxperimenteerd met een nieuw interessant patroon, in het artikel Solving the “repeat emailaddress” form issue. Steve Krug merkte namelijk in een discussie op dat de veel verkeerde e-mailadressen wellicht het […]


  63. […] One Consulting wordt echter geëxperimenteerd met een nieuw interessant patroon, in het artikel Solving the “repeat emailaddress” form issue. Steve Krug merkte namelijk in een discussie op dat de veel verkeerde e-mailadressen wellicht het […]


  64. Nice discussion and examples ! maybe something like:
    Display the entered email dress large in a red box (like example 5) with below big Green Yes / Red No and icons, When clicked Yes > box becomes Green (and after a second the submit happens.), No > the focus goes back to the email field.

    I think this is some more usable then an overlay afterwards asking if it is correct (example 5). Plus you can’t prevent a visitor to enter an wrong email address.. but you can try to prevent typing mistakes. Furthermore it is mostly more important that users fill out the form. Making it difficult to submit an form can prevent a user to fill it out.


  65. I’ve just seen this approach in an online survey I was completing. They did it twice, once to confirm my name, and then to confirm my email address.


  66. […] kolei Ross Unger i Jonathan Knoll zaproponowali, aby powtórzyć adres na końcu formularza. Dzięki temu użytkownik ponownie […]


  67. […] pattern suggested by Russ Unger – to echo the copy back to the user in a more salient form – is I think a very good […]


Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>