Forms on the web have become terrible. Lost state. No keyboard nav. Weird refreshes. Mobile hostile.

The reason is #frontend developers that think clientside state management is how to implement a form. It is not.

Good forms work without client #javascript (and then are progressive enhanced by js to work even better).

Good forms always submit. Good forms remember values and display problems inline.

How do we fix the misconceptions and, in the process, fix the forms on the web ?

We teach how to do this properly on https://enhance.dev but we are only one of many different frameworks..and the techniques SHOULD be framework agnostic. That said, many frameworks conveniently ignore POST unless it's client fetch. Which is cheesy.
Enhance

The HTML first full stack web framework

Enhance

Two other notes.

1. Luke W has THE book on design of forms here https://www.lukew.com/resources/web_form_design.asp

2. Most of this is downstream frontend frameworks ignoring POST so they don't need to teach/handle httponly session state for persisting values. Arguably these types of framework are a poor choice for UX.

LukeW | AI Has Flipped Software Development

For years, it's been faster to create mockups and prototypes of software than to ship it to production. As a result, software design teams could stay "ahead" of...

@brianleroux this stuff is so crazy… like it is a damn form, one of the oldest things. why do people do these wrong?
@sayrer the boot camp industrial complex and YouTube influencer education depend on "break into tech" content being primarily about GET requests so they can skip anything backend. At least that's my theory. Cc @slightlyoff @polotek
@brianleroux Oh my, this is absolutely the most convenient reading in relation to some forms that I’m working on right now, especially with the team’s relative proximity to Luke…in meat space. @hunterloftis @bendelarre #🤣
@westbrook @hunterloftis @bendelarre it's a great book ... definitely supplement with progressive enhancement tho!
@brianleroux I LITERALLY have a post sitting in drafts that goes into extreme detail on how this can be done in Rails (and the frameworks to best choose to make this possible). I can definitely let you know when it's live (sometime next week!)
Thomas Cannon (@[email protected])

I just published ~3K words + diagrams + code samples + demo videos on the frontend networking stack I’m choosing for Little CRM, and all my apps going forward. https://thomascannon.me/guides/fixing-the-rails-networking-stack I know that’s a ton to dig into, but I believe this is a very strong path forward for resilient and maintainable web apps.

Ruby.social
Forms that Work: Designing Web Forms for Usability (Interactive Technologies): Amazon.co.uk: Caroline Jarrett, Gerry Gaffney, Steve Krug: 9781558607101: Books

Buy Forms that Work: Designing Web Forms for Usability (Interactive Technologies) 1 by Caroline Jarrett, Gerry Gaffney, Steve Krug (ISBN: 9781558607101) from Amazon's Book Store. Everyday low prices and free delivery on eligible orders.

@brianleroux LOL your previous tweet made me think “I wish there was a HTML first framework” 😂
Home

Design your service using GOV.UK styles, components and patterns

@brianleroux Also: good login forms work with password managers.

@brianleroux 💯

Couple of notions…

Making Jeremy’s Building talk mandatory learning for new devs would be a start https://mastodon.social/@urlyman/111844078858504140

And it wouldn’t hurt to embed the philosophy of frugal computing as an inevitable direction of travel https://wimvanderbauwhede.github.io/articles/frugal-computing/

Frugal computing • Wim Vanderbauwhede

On the need for low-carbon and sustainable computing and the path towards zero-carbon computing.

@brianleroux This is such a pervasive issue on the web.

I build form interfaces incrementally, with native HTML and a server endpoint. I make sure everything works fully before touching a line of JavaScript.

Colleagues will ask why I'm not "doing it in React." It's not until a few iterations in, once I've added client-side progressive enhancement with native JavaScript that the full picture starts to take shape. Then, "Wow, this is fast and snappy, and it works even when scripts fail to load."

@brianleroux I am still fighting folks trying to put form state in redux.
@brianleroux There are addons that do this, but I would love browsers to have a usable short term memory for form contents by default. Maybe not 'for all time', but for maybe a week?
@mhoye @brianleroux for all the things I’m forced to do annually and can never remember where to find the magic incantation for some fields, I’d go for 60 weeks
@mhoye @brianleroux I also haven’t found a good addon for recovering old entries in Firefox, the one I used to use is only for Chrome
@ShadSterling @mhoye @brianleroux Yep. Until something like that is implemented though I personally prefer that state be saved with Javascript. I do not want a work in progress to be transmitted to the server prematurely. It should submit only when I tell it to submit. Anything else is a vulnerability.

@brianleroux I once found myself implementing a GraphQL mutation and several React components to submit what was in essence a simple form.

I remember wishing, sarcastically, for a protocol that literally had this built in.

@brianleroux I feel not only FE community is to blame but the UX community as well. I've come across a lot of UX improvements/nice-to-haves (which are considered best practices) that led to a11y bugs.
@brianleroux browsers should have some sort of input history built in and a way to refill forms even if field identifiers change. At this point I blame the browsers, not the web apps.
@tlhunter @brianleroux But that's already there: browsers *have* an input history, often depending on the name, sometimes in the id or a combination of both. And they have autofill features for known tokens, e.g. shipping or billing addresses or personal information - these are useable without identifiers.
@brianleroux as long as unqualified teams are given this task this problem will be forever endemic.
@brianleroux This is a sweeping claim that I haven't witnessed. I've seen the _occasional_ form the way you describe. In all cases it wasn't frontend devs who were the problem, they understand how to make forms. Instead, it was "enterprise" devs implementing some waterfall requirements (eg: "no pasting in a password field") without understanding the tech.

@soviut it happens to me daily. Banks. Hotels. Airlines. Medical clinic. Grocery order.

Critical stuff. Being let down because devs don't know how forms work truly.

@brianleroux Banks are usually the ones I see being poorly developed by said "enterprise" developers. They lack any knowledge of browsers or frontend. I once spoke with a dev who worked for the bank I use and I complained about the 8 character limit on passwords at the time; he argued it was entropically fine.

All the frontend devs I know are intimately familiar with forms. If they're not, they aren't really frontend devs; they're just devs who happen to be writing frontend code at the moment.

@brianleroux Forms should do all the necessary formatting for the user.

It took 4 tries for me to contact a company today because the contact form wouldn’t accept a copy-pasted phone number regardless of the punctuation or lack thereof. They almost lost a sale over that.

@brianleroux What do you mean by "always submit" and "without JS"? If it's the full page refresh, then I'm not a fan. This brings (back) so many issues which I'm so glad that we've eradicated that I don't see it as a good UX path forward.
@MichalBryxi exactly what I said. But I never said "without js" *ever*. I just make sure it works without it. It's called progressive enhancement. And it's a way better experience

@brianleroux every peace of curriculum needs a section of forms.

99% of development is handling forms. Instead of the next big wenn development framework we need decent standards and libs for forms, which are widely understood and adapted.

It's not exactly rocket science. But probably forms are just not sexy enough for most devs to care much about them

@brianleroux I am not a web dev (not my professional thing), coding forms is horrible experience for me, maybe the worth part of the front end. I use framework but I need to add multiple libraries that are difficult to link. Too many lines of code.

@brianleroux first, I would get rid of your assumption that it is "front end devs" responsible for this

Many (most) forms are created by "full stack" devs who - speaking for myself - never had a day of training on best practices & work things out to the best they can, following instructions from a manager with no formal UX experience

Looking at the problem from that POV changes the answer quite a bit

@codebyjeff I'm not entirely sure what a fullstack is or how a dev becomes one but the only devs I hear talking about or claiming that particular title are squarely in the FE frameworks side of things

@brianleroux you become one by being a database programmer and having your manager say,

"Great! Can you fix the responsiveness on this web page?"

And joking aside, that's what I mean in saying many of us are doing a job we were not trained for, and don't even realize when we aren't following best practices

@brianleroux agree. Was trying to buy tickets for a local football match for my son recently on mobile and the form was a difficult to use mess of JS.

I think web forms education has to start with HTML, not frameworks that process the data.

Also, what do code camps/colleges/universities use when teaching students this stuff?