I would press that button just to make it go away. ;)
Not that it matters -- the data matter -- but I can certainly rationalize why such a button would be more effective than a standard form submit button: My peripheral vision has seen a hundred thousand form submit buttons by now. I'm not quite as blind to them as I am to standard-sized non-animated web ads, but it's close.
And it seems to me that the problem with being a designer is that it's physically impossible to design a web form in less time than the average user will spend looking at it. You will necessarily spend orders of magnitude more time looking at your forms than a visitor will: Visitors don't look at forms for fun. They click through them fast, or they click away from them even faster. If I had to stare at that button for an hour, as opposed to simply finding it and clicking it as fast as I could, I'd design it differently. Which might very well screw it up.
You are clearly underestimating the compatibility & accessibility challenges of reinventing the form submission code of a web browser from first principles.
Believing you can do so and not fuck it up is sheer hubris, not to mention, wrong. Doing so because you don't like the browser edge cases, is how websites end up suffering from even more edge cases, and harks back to the bad old days of "Sorry your browser is not supported".
Financial institutions are amongst the worst offenders - ironic since pulling this kind of naïve stunt vastly increases the attack surface. I've been in a position to redesign financial institution systems and rewrite their technology policies, and when doing so this kind of off-standard NIH crap is something I seek to stamp out.
Want to submit a form? Use a damn form, with a plain old submit button, and rely on the standard behaviour. Want to put some UI polish around it? Progressively enhance the standard behaviour.
What not to do: imagine you can write better UI<>protocol interaction code than that already in Chromium and Webkit, or hope to infer and reimplement the behaviours of any more specialised user-agents.
I find that different browser brands react differently putting BUTTON tags inside of forms. Tread with caution. Internet Explorer versions are usually the biggest bottlenecks.
While neat, browser navigation isn't a bad thing on forms considering it is good to notify the user that the form was submitted. Otherwise, they will likely just keep hitting submit.
Another annoying trend is buttons that look like text boxes. Oh. A white rectangle with a gray border? I guess I’m supposed to type there. Nope. It’s a button cleverly disguised as an input.
Unfortunately this effort will barely matter since most pages re-style form controls, ignoring one of the foundations of good UX (familiarity). We are in 2020 and web forms are still a mess. We can hope better / more familiar default form controls will decrease this demand for customization a bit.
Modern web culture is very much the problem. The tech can be keyboard-friendly, sure... but in practice, even the most basic stuff, like Enter to submit forms, is often not working because the "Submit" button is not a proper button, but a bunch of JS.
Yes, at least in some respects, HTML forms could have been that way, but in practice, they are not:
For one thing, and this is important, with every browser I tried, I get periodically interrupted by messages that the browser displays and that are not part of the form. Just recently, I was again asked for security updates by the browser. Sometimes when opening a form it gets prefilled by the browser, sometimes not, and sometimes only some of the fields. Some other times I get asked whether the browser should translate the form. Sometimes it asks me whether some fields should be prefilled. Sometimes when submitting a form the browser asks me whether I would like to store the form contents for later use. Sometimes the browser asks me at unpredictable times whether I would now like to restart it.
An important prerequisite for getting a lot of work done is for the system to behave completely consistently and predictably, and not to interfere with unrelated messages, questions, alarms etc. This is also very important for training new users, writing teaching material etc.
Another important point, and that is very critical as well, is latency: Just recently, I typed text into my browser, and it stalled. Only after a few moments, the text I entered appeared.
I never had such issues with COBOL applications. Today, we can barely even imagine applications that are usable in this sense, because we have gradually accepted deterioration in user interfaces that would have been completely unacceptable, even unthinkable, just a few decades ago.
I disagree. The form is really poorly designed. One big specific issue is the Submit button is red, it should be green, this violates a design 101 principle. Thanks.
No, form submit buttons did something i.e. submitted the form. While this had the effect of going somewhere the expectation was straight forward and obvious. Using forms as links was roundly advised against.
I attended a talk on UI design for devs a few months ago. The presenter asked us: "Do any of you run an S&M website? No? Then your buttons shouldn't say submit!"
It’s intuitive to any user who has used a web form anytime for the last 2 decades.
Breaking default browser behavior because you find it unintuitive is generally a bad idea.
Now if you’re dealing with something that isn’t really a web form—as in you’re overloading input fields for some interactive non form like behavior—then I can see it.
In my case, if the person had some well thought out reason for doing it, I might let it slide. But the vast majority of times I’ve seen it, it’s because the person doesn’t even know how to use forms. Not understanding the underlying technology at at least a very basic level is a strike against you in my book.
At last. Now if only designers could jettison that useless "Clear" button from forms...
So much was written about web form UX. Even if some advice is conflicting with each other, having the dinosaurs implement the least common denominator would come a long way to ease users' frustration.
Plain old web forms are actually not so bad these days, since browsers are pretty good about keeping any entered text around if you accidentally hit the back button (or even if the browser or computer crashes). It's really the big fancy web apps with lots of stateful javascript that are a problem, since the URL doesn't necessarily describe the state of the page and the form fields the browser tried to preserve may not even exist anymore.
In the specific case I'm talking about, it was a big (and rather buggy) pile of stateful javascript, and whose failure would leave a crowd of angry sports fans and player waiting for it to start working again before the game could continue. In retrospect, not using in the the first place would probably have been the better option, but ripping out the backspace keys seemed like a reasonable compromise at the time.
Users expect forms to submit when the click the button. If they change their mind about signing up or purchasing something, they don't expect to get emailed if they didn't click the button. That's the dark pattern. Not the worst I've seen, but not great either.
reply