Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

And for a login page with what is effectively a form element with two input fields that IS is overkill.


sort by: page size:

This is not what I meant at all. If you have JS, you'd see one field. No JS, you see a regular login form. It has nothing to do with onclick attributes.

Also, just because it looks like one input field, doesn't mean it has to be one input field. It could be two fields masquerading as one.

Still, I don't think this is a useful design pattern.


Don't worry web developers will come up with more ways to over-engineer a form with 2 inputs.

Why do I need all this overhead for something as simple as a button or other native form input elements?

Seriously, this almost seems like they went out of their way to make an unintuitive page. Who makes a form field without an enter button? And the forfeit box covers the input.

Yeah I still can't get over the fact you're using 4 huge code bases just to replicate the functionality of a standard html input form.

Had to make a form with over 3000 input fields for a project. Figured that input fields shouldn’t be so resource intensive as to become a problem. Except that the form manager used JS inputs leading to the browser crashing constantly.

In my experience, these decisions are usually made by product or design people.

The one that annoys me most is whenever someone needs to enter a code with a fixed length. Like a 6 digit OTP code. They want to have a UI with 6 separate input fields: _ _ _ _ _ _ that behaves like one input and only allows the correct values and has the cursor behave correctly jumping from one box to the next as you type / backspace. Turns out, creating that UI element is kinda time consuming and adds NOTHING and at best results in the same user experience as just tossing in an HTML input element, and more often than not results in some non-standard behavior that breaks something (auto-fill, paste, arrow key, accessibility, etc, etc). Just use a standard input, throw some css on it to make it the characters big if you want.


Honestly I find one of the biggest missteps for me is that they started injecting UI into the web page itself.

I'm sure it reqires less work from the locally installed app (and lets them do away with it altogether, even), but it creates issues - it obscures UI elements in the page with a hard to dismiss overlay (no obvious clickable way to do it) that fits below webpage UI elements when it's heuristics identify it as an appropriate field.

edit: plus I regularly find that when I try to fill form fields in Safari and Firefox that selecting the appropriate login and hitting autofill does absolutely nothing.


Yes it really is. And now imagine someone would instead use a custom multi-select, because their browser has a bad implementation. Actually the best example why custom form elements shouldn‘t be used.

You can still write one as an add-on for your browser and help others or use it as poc for a ticket to the browser vendor.


So you think it's safer to rely on every engineer adding that (and the other facilities provided by web browsers by default when using native elements) to every input field in a form, than relying on them not doing weird things with that one form tag?

The article is right, but it’s also an indictment of just how poorly designed HTML is for dynamic applications.

Preventing double submission of data is a thoroughly basic feature for any UI library. It should be easy and obvious. But for HTML forms, the properly accessible solution shown here involves a non-intuitive combination of JavaScript, CSS and custom data attributes on an element.


I don't know whether this is a usability issue or not. But, I really don't like the extra long input text area:

This issue is quite critical on acquiring new users. A good read on designing sign up form.

http://www.smashingmagazine.com/2008/07/04/web-form-design-p...

http://www.smashingmagazine.com/2008/07/08/web-form-design-p...


> A login form will be accompanied by a Login button

Forgive me for this tangent, but please please please follow the above advice. I've had it with login and search forms that replace their submit button with javascript.


Exactly. For a login screen with a post that exalts the design, I thought it was a glaring usability mistake. Even a simple cue, 'Hit Enter to Continue' that appeared when the fields were being filled in, would up the usability. I know I won't look for it, but my mom would.

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.


No, web browser [form] buttons are not pretty.

No, having identifiable form elements is freaking important, computers are hard enough for a novice to learn without the basic idioms change shape and meaning because designers want to get creative.

The real world needs consistent form inputs.

Also. Damn you firefox, Implement the bloody date input.


A few modern form features like placeholder text, required, and input type-casting for email, tel, number, and date reduce the need for JavaScript if you're willing to let the experience degrade pretty drastically on legacy browsers.

On a side note, I found the clip art at the top of the white papers distracting. Formatting, spacing, class names such as "nav", value="passwo".


Me wishing every UI/UX person understood this.

In fact, the more bells and whistles I find on the requirements for individual form inputs, the more annoying it is the work on.

Simplicity is god for most of front-end.

next

Legal | privacy