Breaking down a long form

Hey everyone,

I have a bit of a silly question/issue which I have been struggling with now for a few hours, so I thought I would turn here and ask you guys whom are more experience than me!



I am trying to create a mock-up form I want to use potentially from my phone as well as computer to illustrate to some colleagues a concept. I tried using a jqueryform form builder but it wasn't what I wanted. The idea is to create an interactive responsive form so I am using this:

<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=0">

Code (markup):

which seems to be working really well for that in terms of having a responsive webpage size!

What I am stuck with I suppose is trying to "spruce up" up the form, if you know what I mean. In my head, I imagine it to be multi-page/multi-step form that would only submit once all the data has been collected.



I have tried to illustrate that with the use of the horizontal rules. Is it possible to show/hide+reset an entire "page/step" depending on the value of option 1?



Form validation is another minefield which I haven't even began to tackle! Almost all fields will be mandatory depending on the choices and they will have variable value ranges as well. The other thing as well, some fields would need to be reset/zero'd if the parent choice is disabled, for example the value of range input if option 2 is unchecked.



In this form, I have used W3's toggle switch (which looks cool as hell) and struggled to apply rangeslider.js to my range input (the CSS/styling wouldn't show up for some reason!).



Also, whilst I am here, I am going to have a moan about my calcbal function which works now but makes no sense! I am trying to get it to subtract val5 from val6 (val6-val5) yet when I put it like that it doesn't show the right answer. I've had to resort to (val5-val6) which is fundamentally wrong on pen and paper. But I don't know what's going on there!



I guess my most pressing issue right now is how do I change this form into a multi-page form and if I am lucky get the form to respond to option 1's value by added/disabling an optional page/step.



I look forward to hearing your thoughts



Thanks

 

Well, your first problem is throwing scripttardery at something JavaScript shoudln't even be involved in. The FIRST thing you should be doing with ANY form is to write it so it works AS IF JAVASCRIPT AND CSS DO NOT EXIST so it is usable to ALL users, not just the magically priveleged and ignorant. People disable JavaScript to save battery life. People BLOCK JavaScript out of distrust on sites they don't know... and hackers can bypass/modify JavaScript so anything you do with it CANNOT be trusted! CSS doesn't apply to the blind, the visually impaired, or search engines.

To that end your semantic gibberish of throwing paragraphs at text that does NOT qualify as grammatical paragraphs, <strong> doing <label>'s job, empty <label>, and lack of fieldsets is just plain nonsense! Where's your bloody fieldsets?!? Seriously, what in the blue blazes makes this:

 <p><strong>Expenditure/Var6</strong>: 
    <input name="var6" type="text" id="var6" value="0" onkeyup="calcbal()"/>
  </p>

Code (markup):

A GRAMMATICAL <p>aragraph? What makes that text "recieve more emphasis" (what <strong> means) when it is CLEARLY a <label> for that <input>?!?

What makes this:

  <p><strong>Step 1 - Review recent measurements</strong></p>

Code (markup):

A grammatical <p>aragraph recieving "More emphasis" instead of a LEGEND or numbered heading?

Why are you using HR when there's obvious sections each of which should have their OWN headings/legends?

So throwing halfwit bloated BS like jQuery, much less the dumbass ignorant nube predating scam artist RUBBISH that is a 'form builder' at it? NOT THE ANSWER!

Your woes are only compounded by this next claim:

Since THIS PART:

maximum-scale=1, user-scalable=0

Code (markup):

Is the OPPOSITE of making it responsive, or at least accessible AS YOU ARE DISABLING THE ABILITY TO ZOOM!!! You basically just told users on mobile to go **** themselves. Those two values should NEVER be set in your viewport <meta>, anyone telling you otherwise is talking out their arse. Hence what I recommend is:

<meta name="viewport" content="width=device-width,height=device-height,initial-scale=1">

Code (markup):

So you do NOT break the ability to zoom. I include the height as some Android devices will report their height as width when in landscape.

On modern browsers (IE9/newer) you don't even need JavaScript to do it. Make each section a fieldset, give it an ID, your "next" button would be an ANCHOR to the next sections ID. You then use :target to show the sections one after the other. This CAN have the problem of "how do I hide the first one" which is why such forms often have a "start form" anchor to point at the first one. Another approach would be to abuse <input type="checkbox"> sharing the same name as siblings to the fieldsets, using label tags as the buttons so you could use CSS' :checked attribute, but this in the case of a form can introduce its own set of accessibility woes.

Even then, the use of 'required' and trying to make multiple pages out of what PROBABLY SHOULDN'T BE unless you're intent is to make the form harder to use (google "false simplicity") means that multi-paging is just going to be a pain in the ass. You want multiple pages? DO THE WORLD A FAVOR AND JUST MAKE IT MULTIPLE PAGES!!! As in real separate pages with *OH NOES* a *SHOCK* page-load!

Again handle that server side as much as possible. Whilst you could ENHANCE the ranges using JavaScript, at the end of the day a well written form shoudn't RELY on it for basic functionality.

FIRST OFF, let's be perfectly clear. You mean W3Schools, not just "W3" -- a nube predating scam artist site full of bad practices and disinformation that is COMPLETELY unrelated to the W3C. Much as I often use to describe Java's relation to JavaScript, it's like how Ham is to Hamburger.

Second whilst an interesting implementation, it's accessibiility rubbish because it uses display:none, meaning it is non-functional in EVERY version of IE, doesn't account for labels properly since even wrapping with no FOR attribute some browsers will ignore it, and of course it throws it at all browsers instead of just modern ones which is why that CSS override belongs in a media query. (sneaky trick, @media (min-width:1px) { will target JUST CSS3 capable browsers!). More so the actual part that makes it "look" that way probably has no business even being an element in the markup when we can leverage generated content to do it from the CSS. Again it's a CSS only effect, so the CSS should be doing it, NOT a span in the markup!


Even so, fany stuff like that and rangeslider ARE accessibility headaches and should only be used when you are DAMNED sure of what you are doing and who the audience is.

1) Try not to do stuff like this client side except as an enhancement. NEVER send a client side calculation server-side since it CANNOT be trusted. To that end your 'balance' area has no business in the HTML and should be added by the JS when JS is available.

2) Avoid using the onevent attributes. They're sloppy crap for things that have ZERO business in the HTML, and if you ever end up deploying under the "Content Security Policy" THEY NO LONGER EVEN EXIST!!!. You want to hook events, do it from the SCRIPTING! (addEventListner for modern browsers, attachEvent if you care about old IE)

So I guess the first step would be to fix your markup, dragging it kicking and screaming into the proper semantics and structure... but honestly it's such an accessibility and design mess, I'd be putting serious thought into rethinking how you are even asking users for information.

When it comes to something IMPORTANT like a form, don't go full scripttard. You never go full scripttard.. The fancier you make it with artsy fartsy show/hide the more likely you are to just piss off visitors no matter how pretty or "gee ain't it neat" shiny the result.

 

Thank you for a scathing but eye opening reply.

I have decided to re-format the form as you have advised, however I am still sticking to the multi-step approach since I still believe that's what I need. I just need to do it well!

 

That is a common (an all too common) method of presenting forms. Another use of that multi-step approach lies with polls. Let me tell you, from a user's viewpoint, that approach well and truly sucks for either. I won't tell you what it sucks, but it has to do with boar hogs. All users know how to scroll down to the next question or group of questions. More important to the users, they know how to scroll back up to review or correct their entries.

If you are absolutely convinced that a multi-page form is necessary, try to make it no more user UNfriendly than it already is. An example of kicking your visitor in the privates is locking him into the entry or the page until an error is corrected. Politely notify him of the problem and allow him to proceed. There may be something he needs to find, e.g. paperwork, an address, phone number, etc.. If he'd rather get to the end, find what he needs and then continue, let him.

By the way, it's not about what you need, it's about making it easier for your visitor to provide the information. Your presentational needs aren't worth a green f--t up against his need for an accessible, responsive and device independent web site.that makes it easy for him to find, learn and buy what he came for.

gary