Comment by reaperducer | Hacker News Reader

Comment by reaperducer | Hacker News Reader

Parent Full thread

But the thing is, almost as soon as you have any kind of significant user input to handle (multipart forms, date pickers, autocomplete elements, conditional input elements) you are instantly dealing with complex frontend state. And then your choice is not "SPA vs plain HTML forms," it becomes "SPA vs (ad hoc jQuery tangle + ad hoc server side endpoints that know to speak to random jQuery UI libraries)."

In my experience, this is false.

In the last two years I've built five very complex forms for the healthcare industry that not only had crazy looking flow-charts, but had to be multi-lingual, predictive, mobile-friendly, and fully accessible.

They use all those little bits that you talk about - multi-part forms, date pickers, autocomplete, and conditional input.

The only JS is for the autocomplete. The rest is all HTML5/CSS3.

We did user testing on three of them (100 people from our target group, selected randomly at two of our facilities, with generally low levels of technology literacy), and the paginated HTML5/CSS3 versions all scored higher than the previous Javascript SPA mess the preceded them.

I can believe that in your user testing people would score a non-spa higher, but that isn't relevant to the question of whether an spa had more complex state management hidden from the user than a mpa.

What I imagine happened in your tests is, you didn't compare two different implementations of the same UI, you implemented the form via two different UI's and the users preferred the experience of new one to the old one.

I believe that you compared different UI's because otherwise you wouldn't need user testing: you could just measure the latency and code complexity.

The person you are responding to is saying, for a fixed user interface design, the necessary state management will be the same and your only choice is how to implement it. You say you believe this to be false but it doesn't seem like you are responding to the point.

Isn't it unuseful to be pedantic to the point of completely missing the point of the post you're replying to?

That person had something to contribute that was worthwhile. Sorry it wasn't a double-blind placebo controlled clinical trial, but it was still useful info and very much related to the topic replied to.

You must've missed the "vs plain HTML forms" part.

As a top level comment, it is valuable to point out that many executions of SPAs are lack lustre and will not deliver a superior user experience. If it was a top level comment and didn't lead with contradiction of the prior comment, I would have affirmed and probably not have posted anything. That is why I started by telling the commenter that I believed he actually produced better implementations, because he has a point but not a point that is meaningful to back up his disagreement.

The point of the comment chain in question is that a given UI has a need for a given amount of state. That is the point that was "[believed] false" and the point I was reiterating. User feedback is not useful at all for determining whether SPA's will require more state than multiple "plain HTML form"s. Moreover, the key assertion of the article is that this is necessarily the case, a point which is asserted without evidence and used as the foundation of the entire article. If you remove that assertion, the whole article collapses.

The comparison doesn't make sense though. There's absolutely no reason you can't build an interface using single-page that functions to the end-user identically to any multi-page form. You can't necessarily do the reverse (multi-page to emulate single page), but that is also irrelevant to the top level -- if the SPA has 10 times the complexity to build an identical UI, then it's probably going to be harder to maintain for no value to the end user (which isn't to say no value).

What I got is that they built different UIs and found one of those UIs was better than the others; that says nothing about single-page vs multi-page. Maybe it was easier for them to build the "winning" UI as a multi-page app, but I didn't see that being said.

If you didn't use JS for date pickers, you didn't have very inclusive browser support - especially for something like a healthcare website. [1]

Were the designs and layout of these SPA and HTML5/CSS3 website also identical?

[1] https://caniuse.com/#search=input%20date

It's more than a little absurd that there isn't a passable date picker implemented across the major browsers. I have wasted far, far too much of my life fighting with different half-baked JS datepicker components already in my life.

Still better than supporting IE6.

If it's public facing, that's a huge concern.

If it's intended for business users, particularly if on an intranet site, it's often very easy to limit the number of browsers and versions you need to support to just a handful.

The Web has been collecting dates from users in forms long before date-pickers existed.

The Web has been doing lots of things poorly for a long time as well. I know I've seen some implementations of date-pickers I don't like, and more old school implementations without date pickers that were just clumsy.

86% isn't bad, particularly considering you can easily polyfill a date-picker in the missing browsers and attach it to input[type=date] elements.

>In the last two years I've built five very complex forms for the healthcare industry that not only had crazy looking flow-charts...

Can you maybe elaborate a little bit more? I've had to do some pages for configuring industrial machinery, some having over 100 parameters, many of which would affect what other parameters could then be used or selected. Used Vue.js which worked pretty good, but I'm curious of other ways...

Some of our forms have 150+ fields with a rule engine that hides/shows various sections of the forms or hides items from particular drop downs, even auto populating fields with custom data via 60+ rules. All using jQuery, and it's impossible to work on.

I was wondering if I might be able to ask you some questions about those healthcare forms? (I wanted to send a private message but couldn't find any contact information.)

I'm working on a product that can fill out very complex PDF forms, as well as automatically generating web-based forms for people to fill in, so I would be very interested in hearing some more details.

Were you able to stop page refresh after form submit without JS? That's something I've been looking for, for a long time.

yeah that's also what I'm curious about, unless he adds a confirm page for some actions (which is actually more work) than just confirm('Text');

Reply on news.ycombinator.com