Prevent users from clicking submit multiple times

[lippytak]

Something to prevent users from submitting the same application multiple times. Maybe do the PDF stuff asynchronously and send them straight to the confirmation page? Maybe turn the submit button into a friendly spinner?

[alanjosephwilliams]

Can you describe the user interaction wherein someone has submitted an application multiple times?

[lippytak]

Click submit. Nothing happens. Click submit again.

On Tue, Sep 2, 2014 at 10:04 AM, alanjosephwilliams < notifications@github.com> wrote:

Can you describe the user interaction wherein someone has submitted an application multiple times?

— Reply to this email directly or view it on GitHub https://github.com/codeforamerica/calfresh-and-so-clean/issues/157#issuecomment-54183918 .

[alanjosephwilliams]

Roger that. Do we know what happens if a user clicks submit, hits the confirmation page, then hits back and tries to submit again?

[daguar]

Probably bad things.

Ideal fix would be JS that:

1. Greys out the button
2. Removes the submit functionality from the button
3. Does "spinning progress thingy" animation

On Tue, Sep 2, 2014 at 12:29 PM, alanjosephwilliams < notifications@github.com> wrote:

Roger that. Do we know what happens if a user clicks submit, hits the confirmation page, then hits back and tries to submit again?

— Reply to this email directly or view it on GitHub https://github.com/codeforamerica/calfresh-and-so-clean/issues/157#issuecomment-54204631 .

Dave Guarino Consultant, Health Vertical (2013 Fellowship alumnus) Code for America http://www.codeforamerica.org/ dave@codeforamerica.org LinkedIn http://www.linkedin.com/in/daveguarino/ | GitHub https://github.com/daguar/

[alanjosephwilliams]

Those all seem like reasonable v5 features.

On Tue, Sep 2, 2014 at 12:55 PM, Dave Guarino notifications@github.com wrote:

Probably bad things.

Ideal fix would be JS that:

1. Greys out the button
2. Removes the submit functionality from the button
3. Does "spinning progress thingy" animation

On Tue, Sep 2, 2014 at 12:29 PM, alanjosephwilliams < notifications@github.com> wrote:

Roger that. Do we know what happens if a user clicks submit, hits the confirmation page, then hits back and tries to submit again?

— Reply to this email directly or view it on GitHub < https://github.com/codeforamerica/calfresh-and-so-clean/issues/157#issuecomment-54204631>

.

Dave Guarino Consultant, Health Vertical (2013 Fellowship alumnus) Code for America http://www.codeforamerica.org/ dave@codeforamerica.org LinkedIn http://www.linkedin.com/in/daveguarino/ | GitHub https://github.com/daguar/

— Reply to this email directly or view it on GitHub https://github.com/codeforamerica/calfresh-and-so-clean/issues/157#issuecomment-54208120 .

t: @alanjosephwilli p: 817 713 6264

[alanjosephwilliams]

I think I'll probably change the text of the button, and pulse the color between the current "active blue" and something else.

CSS-only pulse effect for reference: http://codepen.io/tag/pulse/

Nice "candy-bar" effect http://codepen.io/cemre/pen/wFjIB

[alanjosephwilliams]

So this is not working in the current clean-dev app. However, our ability to diagnose and test is limited. We will need to sync up to move forward this first thing.

• Don't have access to the clean-dev app via Heroku.
• It's not clear what branch is being built to the clean-dev app. The styling of parsley validation for example, is different on on the clean-dev app than the v5-dev branch when run locally.
• Jake and I are getting an application error in the v5-dev branch (in vagrant) locally. This could be human error, but its preventing me from testing effectively locally. The bug is being triggered when we try to parse a valid DOB.

@daguar @lippytak

[daguar]

Don't have access to the clean-dev app via Heroku.

Added you both as collaborators.

It's not clear what branch is being built to the clean-dev app. The styling of parsley validation for example, is different on on the clean-dev app than the v5-dev branch when run locally.

It was a merging of your two PRs onto v5-dev Alan.

Jake and I are getting an application error in the v5-dev branch (in vagrant) locally. This could be human error, but its preventing me from testing effectively locally. The bug is being triggered when we try to parse a valid DOB.

There's a funky issue in running in development due to cookie encryption — uncomment line 17 in calfresh_web.rb (the line that says enable :sessions).

Sorry about this — it only affects you if you're sending real data down the wire, and so that's why you haven't stumbled upon it until (presumably?) you're clicking the button to submit the app.

[alanjosephwilliams]

@anselmbradford maybe you have some perspective on this.

Essentially, we are applying styles to a "submit" button after the user clicks the button. I was using simply jQuery to apply new classes that styled the button so that it was a) disabled b) styled to reinforce that lack of functionality c) had new copy communicating that the submission was in progress.

What I found was a cross-browser issue having those new styles painted. New value was fine, the actual disabling of the button was fine—i.e. the JS was being executed just fine. However, on certain mobile browsers, the new styles were not being rendered. Moving the application of those styles in-line solved the problem, but if feels like a hack.

Any thoughts on how this might be refactored going forward?

[migurski]

Can you instead make it safe to click submit multiple times?

Is it unsafe because it performs some Javascript voodoo to handle the form, or are users clicking it multiple times because the submission is so slow they get impatient?

[alanjosephwilliams]

Users were not experiencing a state change when they successfully tapped the submit button and posting the form data does indeed take a while. Some users were unsure that they had successfully submitted the form as a result, and would tap the submit button again—which indeed was resulting in an additional POST request (confirm or revise that @lippytak) , and a duplicate application for the business process team to review and ignore.

I think the approach we've taken is important from a user experience perspective—we don't want people feel the frustration of not successfully submitting a form unless that's actually what is happening—but we could probably also make it safe to click submit multiple times, from a robustness perspective.

[migurski]

So, it sounds like the form submission is slow, yeah? What can be done about that?

My interest here is mostly that spending a bunch of cycles on second-guessing browser feedback might be a poor use of time, when I'm seeing a root cause. If the action triggered by the POST is unavoidably slow, it might be time to set up a queue. Is it slow because of a file upload process?

[anselmbradford]

If JS is always going to be present, check that you have something analogous to this:

// in styles.css or whatever
.form-button-submit[disabled] {
  // disabled button appearance
}

// in form.html or whatever
<form id='form-main'>
<button type='submit' class='form-button-submit' disabled='disabled'>Submit to the form!<button>
</form>

// in form.js or whaver
var formMain = document.querySelector('.form-main');
var buttonSubmit = document.querySelector('.form-button-submit');
formMain.addEventListener('submit', formMainSubmitted, false);
buttonSubmit.removeAttribute('disabled');

function formMainSubmitted(evt) {
    buttonSubmit.setAttribute('disabled', 'disabled');
    // Classes and inline styles can be added to button here, if needed. 
    // buttonSubmit.style.backgroundColor = 'red'; // this is inline
    // buttonSubmit.classList.add('disabledButton'); // this is class based
}

[daguar]

@migurski:

If the action triggered by the POST is unavoidably slow, it might be time to set up a queue. Is it slow because of a file upload process?

It is slow, though not that slow — it's more that users click again after a few seconds when it takes probably 5-10s (ballpark), and that behavior is, I believe, driven a lot by iOS' weird foible of not showing the button push in a particularly noticeable way.

The slowness stems from a fairly queue-able event, namely PDF writing and sending. So it would be fine to implement this as a queue, but my opinion was (and is) that Javascript — either a transition animation and/or button disabling — is quicker and easier given limited bandwidth.

[migurski]

Hm, makes sense.