Coded forms vs Wufoo/Jotform

I'm a web/graphic designer, but with only a working knowledge of html/css. In the past, when a client has needed a form made, it was really easy to use Jotform or Wufoo, even for a complicated form with dozens of questions and hidden fields.

However, I'm not sure how to proceed with some new changes. One client wanted a 9 digit zip code option added to their form, and I found a script for that and had a programmer implement it in Jotform, however, Jotform takes months to approve each change, so its taking too long. Wufoo doesnt have the option to have outside programmers add features.

Clients are also starting to ask for online signature capability with their forms, which is easy with jotform, however, though not with wufo..

I was thinking of hiring a programmer to rewrite these forms from scratch, though there are 6 forms with dozens of questions, so it could get expensive.

So, I'd just like others general thoughts on this, suggestions as to the best way to proceed. Currently their doesnt seem like an ideal option, though maybe through more research and feedback here the options will become clearer. Thank you for any suggestions.

 

Generally speaking what either of those vomits up and calls a "form" is a bloated inaccessible train wreck disaster. Poster children for how NOT to build website elements if you actually care about users... well... using it.

Hell, you can tell that from jotforms website -- with it's absurdly undersized fixed metric fonts, and that it's trying to do some sort of WYSIWYG bull.

Of course, you said the problem; you're a graphics designer who THINKS they're a web designer. It probably means your "working knowledge" is leaving you ill equipped in terms of accessibility norms to know what's good and what's bad from a usability and code standpoint. If you knew even the slightest thing about accessibility norms, the websites of either jotform or wufoo would scare you away from EVER using either of them!

You can tell this just from the fact that jotform only works via some stupid scripttard embed.

Just like WYSIWYG's, I've never seen a form builder that was worth a flying purple fish in terms of usability, accessibility or sane/rational development. Toss all that garbage in the trash, and learn how to build form PROPERLY instead of relying on gibberish nonsense that prevents you from learning how to do even the simplest of things properly.

Basically you took a sleazy shortcut because the scam artists behind those types of systems took advantage of you. Now it's going to bite you if it hasn't already done so thanks to users not even being able to use the result.

 

Thank you for the reply. What would you suggest as the best programming language(s) for form creation? These forms would need to have dozens of questions, some with hidden fields and conditional questions.

 

Also, I think I understand what you're doing here. You obviously post a lot of helpful info here, and maybe try to scare off people who will waste yours and others time. However, though there was a lot of truth in your reply, I feel mine is a legitimate question. If there is a way I can ask these questions more productively, please let me know. I've googled the question as far as 'best programming language for forms' and the answer doesnt seem too clearcut, so I was hoping to get some insight from someone knowledgeable like yourself.

 

The best programming language for a form is HTML. A form is incredibly simple HTML, even when done right. Styling it is done with CSS (Although some elements only let you style them via javascript, with element swapping). The background processing is where the magic happens, as that's where what is put into the form is made useful. Usually that will be PHP. Then you can do some fancy realtime information to the user filling out the form, so the user doesn't need to submit it just to get a "this isn't right" message back. A form is simple. There is no need for a form builder.

 

@cgl102770, I wouldn't say I'm trying to scare them away, though I can see how for some folks that may be an unintended side effect. I'm just trying to be honest with people and steer them on the right course; sadly there's a LOT of really bad advice out there, outright disinformation and misconceptions that exist mostly so ignorant fools can delude themselves into thinking they know what they are doing, or WORSE allow scam artists to slap the saddle on people to take them for a ride.

I've seen it far, far, FAR too many times the past decade; many of the "new" technologies not helping as they are in fact dragging things back to the worst of late 1990's practices.

Which is why I consider things like jotforms to be nube predating scam bait. The people who made it clearly don't know enough about HTML, CSS or JS to have any business writing code for others... but because it's so easy for people who don't know about HTML, CSS, JS or even accessibility to add to their site, it ends up being used no matter how badly it screws over the result by being an inaccessible broken disaster.

@PoPSiCLe hit it on the head, regardless of what "tool" you use to make the form, in the end it will be HTML. As such, cut out the bloated middle-men who blindly guess and generally wouldn't know a valid form from the hole in their rump and go STRAIGHT to the HTML.

This stems from the fact that HTML is NOT about what it looks like. The tags used to build HTML like <label> or <fieldset> or <input> all have meanings and relationships that are for MORE than what the page looks like, but also exist for users who are not sighted, devices that are incapable of the same range of visual expressions as a screen, and things like search engines. These "non-visual user-agents" are as much part of what the HTML is written for as the big fancy screen layout the layman associates with a site.

"User-agent" is the term for anything that presents HTML to visitors or parses it for some form of data processing; a browser is always a user-agent but a user-agent isn't always a browser. Search engines are user agents, screen readers (software that reads the page aloud to you) are a user agent, braille readers are a user-agent. There are even TTY and Teletype user-agents.

That's what HTML is supposed to have been about from day one -- device neutral delivery of content. We got away from that during the browser wars when idiotic nonsense like CENTER and BORDER were added to the specification, but the introduction of CSS, promotion of the concept of separating presentation from content, and HTML 4 STRICT were created to drag us back to writing properly accessible websites.

Which of course is why most people continued sleazing out HTML 3.2, the browser specific nonsense that came after, slapped 4 tranny on it and patted themselves on the back over how "modern" they were. NOW they get to wrap 5 lip-service around the same bloated broken outdated practices and once again pat each-other on the back no matter how broken the result.

Usually because said result is pretty on their magical combination of screen size and resolution; plow everyone else!

NOT exactly an attitude geared towards success.

Forms are simple. You have the form tag:

<form action="contact.php" method="post">

Code (markup):

The "action" attribute is what URL to call to process the form's data. The "method" attribute is how to send the data. "post" means it will be sent transparently in the HTTP request header, while "get" means the data will be sent as part of the URL using the ?name=Joe%20Sixpack&subject=Some%20Random%20Topic method.

As a rule of thumb for things like contact forms and anything with a lot of data, use POST. Get is better when doing something like a search so you can see the search terms in the URL or share the link with the data in it.

Technically it makes no sense for "inline-level" tags to be children of a form. Labels, inputs, textarea, etc are all considered inline-level and prior to HTML 5 taking a huge freaking dump on the structural rules, the validator would bitch at you about it.

There is a tag called <fieldset>, fieldsets are used to group labels and inputs into, well... sets. A normal form should have at least one fieldset containing all tags that relate to user input values. Typically one would also put the submit here, or as I prefer in a <div> that's a sibling to the form element. I use that same <div> for things like "hidden" inputs -- which are values passed along in the form the user cannot/should not edit. People like to overuse hidden inputs when for the most part the only thing that one really should pass there is something like a random verification hash.

Further fieldsets can be made as kin to the first if they are major subsections like "contact Info" vs. "message". You can also place fieldsets inside a fieldset to group together tags that function "As one" -- the most common of these would be radio buttons since they all can share the same name. In that case another tag <legend> comes into play.

Legends are... useful, semantically correct, and a PAIN IN THE ASS when it comes time to style them. Simple fact is no two browsers accept placement or padding of <legend> tags the same way, so they are VERY hard to have full "artsy" control over. When/if you need to format a legend differently, I suggest using the appropriate level numbered heading instead. Really since numbered headings are SUPPOSED to be about breaking the page into sections and subsections, they are redundant to both the table tag's <caption> and form's <legend>.

Remember, just like in professional writing numbered headings have 'levels', and those levels have MEANINGS. A H1 being the heading under which EVERYTHING on the page is a subsection, which is why it should be the FIRST content element on the page and really it only makes sense for there to be one on a page! JUST like in a newspaper or printed book where the name of the paper or book is at the top of every page and/or fold-pair. That's the H1. H1 does not MEAN "massive text", it means "everything here is part of this".

.. and H2 meaning the start of a subsection of the H1, H3 being the start of subsections of the H2, and so forth down the line -- hence why skipping over heading levels (like a h5 with no h4 or h3 even on the page) or having them in strange orders (H3 before you even have a H1) is utter and complete broken gibberish. That you'll get yelled at for the first time a non-sighted user tries to use the site! ASSUMING they're even able to contact you.

In that same way, HR does not mean "draw a line across the screen", it MEANS, well... Let's let HTML 5's clarification of it explain it.

http://www.w3.org/TR/html5/grouping-content.html#the-hr-element

"The hr element represents a paragraph-level thematic break, e.g. a scene change in a story, or a transition to another topic within a section of a reference book."

Or to put it more clearly, it indicates a new section where a heading with text is unwanted/unwarranted.

... and I bet not one of the things you've learned about HTML taught you any of that. I firmly believe people should be required to take some professional writing classes before diving into HTML; at the very least to learn "logical document structure"

Of course with numbered headings breaking a page into sections and subsections, why do we need a <section> tag again? Much less <article> or <nav>? Again why HTML 5 seems outright schizophrenic to me at times.

The big tag to learn is <input>, which comes in several types -- even more were intoduced by HTML 5. Big thing to remember is that all those new types like "number" or "email" will default to "text" in older browsers, and that ANY user side validation like "required" is easily bypassed by crackers. As such you should ALWAYS have your server side code re-validate the information.

Other tags for user input to learn include <select> with its <option> children and <textarea>. There's also <button> but really if you have to resort to using it, you're probably doing something wrong. It is INVALID/gibberish to use any of these tags outside of a form, no matter how many scripttards abuse <button>, <input> or <select> to do anchor's job in their scripttardery... and utter/complete ignorance of HTML. Yes bootcrap and jQuery, I'm looking at you... AGAIN.

All of those user input tags have a "name" attribute, which is what the element is called when sent to the server... in PHP for example if the form was method="post"

<input type="text" name="subject">

The $_POST['subject'] variable would hold the value of that input when submitted.

The big thing is that every <input>, <select> or <textarea> other than <input type="submit"> or <input type="hidden"> should have a <label> tag associated with it. This is the text that tells users what said element is. You can either wrap the label around your user interaction element thus:

<label>
	Subject:
	<input type="text" name="subject">
</label>

Code (markup):

to create their semantic relationship of "this label is for this input", or you can use the for attribute to point at an ID on an input if you need/desire them to be siblings.

	<label for="contactSubject">Subject:</label>
	<input type="text" name="subject" id="contactSubject">

Code (markup):

The latter is the preferred method since it's usually more versatile to format and the semantic relationship is more clearly defined. When making ID's I'll often like to put a ID on the form, and use that ID as the prefix for all ID's inside it; omitting that prefix on the name. Makes it clearer that the ID and name are two separate things. ALSO REMEMBER that ID's are unique -- you are only supposed to use them ONCE on a page -- using the prefix of the form ID

Sometimes you'll see people put the name attribute on a FORM, that's for outdated netscape style form element access in JavaScript and serves no legitimate purpose in modern code. Generally speaking the older JS method of document.forms['contact'].elements['subject'] was never officially part of the specification despite it's widespread cross-browser support, and you should be using document.getElementById instead; or in the case of more advanced form handling, getElementsByTagName and/or walking the DOM. (a far too complex topic to get into here)

Labels are important for a variety of reasons -- it's clear to user agents it's the description, it does not "lose context" when you focus the element like the placeholder attribute does... You know how some forms will look like this:

User Name : [                ]

Code (markup):

Whilst others will do this:

[ User Name           ]

Code (markup):

The latter is inaccessible trash and abuse of either the placeholder attribute and/or in older sites pissing all over things with scripttardery. The problem is called "loss of context" and is a major contributor to what's commonly called "false simplicity"

See this EXCELLENT article on the topic for more:
http://baymard.com/blog/false-simplicity

Loss of context is the first thing they cover, but really that's only a small part of why even the HTML 5 specification (which defines placeholder) comes right out and says it.

http://www.w3.org/TR/html5/forms.html#the-placeholder-attribute

... and I quote: "The placeholder attribute should not be used as a replacement for a label."

There are other attributes for user input tags you should learn, most of them are fairly self explanatory -- "required", "selected", "checked" -- those shouldn't take too much explaining.

So putting that all together, a properly formatted contact form might end up something like this:

<!-- assumes the page has a H1 of the site title -->

<form action="contact.php" method="post" id="contact">

	<h2>Contact us for more information</h2>

	<fieldset id="contactInfo">

		<legend>Your Contact Information</legend>

		<label for="contactName">Name:<b>*</b></label>
		<input type="text" name="name" id="contactName" required>

		<br>

		<label for="contactMail">E-Mail Address:<b>*</b></label>
		<input type="text" name="mail" id="contactMail" required>

		<br>
		<label for="contactAddress">Address:</label>
		<textarea
			name="address" id="contactAddress"
			cols="40" rows="2"
		></textarea>

		<br>

		<label for="contactState">State/Province:</label>
		<input type="text" name="state" id="contactState">

		<br>

		<label for="contactZip">Zip Code:</label>
		<input type="text" name="zip" id="contactZip">

		<br>

		<label for="contactCountry">Country:</label>
		<input type="text" name="country" id="contactCountry" value="USA">

		<br>

		<label for="contactPhone">Phone Number:</label>
		<input type="text" name="phone" id="contactPhone">

	<!-- #contactInfo --></fieldset>

	<fieldset id="contactRespond">

		<legend>Respond to this message via</legend>

		<input
			type="radio"
			name="respond"
			id="contactRespondEmail"
			value="email"
			selected
		><label for="contactRespondEmail">E-Mail</label>

		<input
			type="radio"
			name="respond"
			id="contactRespondSnail"
			value="snail"
		><label for="contactRespondSnail">Conventional Mail</label>

		<input
			type="radio"
			name="respond"
			id="contactRespondPhone"
			value="phone"
		><label for="contactRespondPhone">Phone</label>

	<!-- #contactRespond --></fieldset>

	<fieldset id="contactMessage">

		<legend>What would you like to ask about?</legend>

		<label for="contactSubject">Subject:</label>
		<input type="text" name="subject" id="contactSubject">

		<br>

		<label for="contactText">Message:</label>
		<input type="text" name="text" id="contactText">

	<!-- #contactMessage --></fieldset>

	<div class="submitsAndHiddens">

		<input type="hidden" name="hash" value="ASasdga4325XB">
		<input type="submit" value="submit">

	<!-- .submitsAndHiddens --></div>

</form>

Code (markup):

*note* I like to split things to multiple lines if it breaks 76 characters, I'm that old-school. Just makes the code clearer. Tab and Enter are your friends! I also use closing comments to make sure I know what's being closed... I put these comments before the closing tag instead of after as some older versions of IE and FF can actually trip rendering bugs if comments are between sibling-level elements... Yes, comments -- those things browsers are supposed to ignore -- tripping rendering bugs.

THAT is a properly formed form. You could substitute <h3> for those legend tags since the form starts out with a <h2> if you find the legend too hard to style from the CSS.

EVERYTHING else involved -- like creating your screen styling -- belongs in the CSS!

ALL of those tags may have default appearances like lines drawn around the fieldsets, positioning for the legends, etc, etc... but that is NOT what they mean or what they are FOR. As I'm always saying, if you choose your HTML tags based on their default apprearance you are choosing all the wrong tags for all the wrong reasons!

Styling it with CSS is a very complex topic unto itself, but as a rule of thumb if you see a form lacking fieldsets, without labels, using tables for layout, or any real variance from the above pattern, it's probably being done wrong and is screwing some users somewhere at some time!

I have something I promised someone a few days ago ahead of this on my "freebies" pile, but I'll try to revisit this later with some CSS with two or three examples of how to style this.

I've actually been meaning to write a tutorial for an as-yet unlaunched site (that's been in limbo since my partner in crime passed away) and this turned into a pretty good start.

 

Thank you both for the replies, I learned some things. I think I'm going to hire someone to recreate the forms, I think it's best to have an expert do them so I dont run into the same problem again that Im in now, using technology that is not versatile . These forms will also need digital signature capability, ideally with more than one party signing the form (patient/doctor), as well as going to a database from which simple spreadsheets can be run, some of which wufoo/jotform can't do. Thanks again for the replies.

 

hi there - i understand you were using Jotform & Wufoo. why don't you look for other form builders instead? not all form builders are the same, you know...i'm sure you'll
find one that fits your needs. hiring a programmer is expensive and limited. each time you need a fix it will cost you.
i suggest you look around a bit more (there's a new one called titan or something like that...and also stackform). good luck!