HTML form code generator
I have developed a html form code generaor at the following address http://websolutions.comli.com/formgenerator.php . The intended final use is for allowing people to make their custom forms and send them to recipients for collection of reports and then download the reports in csv,html formats.
Kindly review the page and any valuable suggesstions will be very much appreciated.
thanking you all.
Well, before you make a tool like this, you might want to learn HTML... and some accessibility norms like legibile color contrast and dynamic font sizes wouldn't hurt either.
What do I mean by "learn HTML"? I added ONE field, and it vomited up this:
Until you have a input that returns multipart, it's a bad idea to add that encoding type... there is NO reason to be using tables for layouts in a form, and even if there were shouldn't that be a TH for the 'label' -- of course you CALL it a label -- but where are your LABEL TAGS?!? Ever heard of the for attribute? how is should be pointing at the ID on the input it's for? Where's your FIELDSET? Much less that unless you're still coding JS for forms using the old nyetscape 4 style scripting, there is rarely if ever a legitimate reason to have a name on a form.
<form name="" method="" action="" enctype="multipart/form-data">
<td> <input type='text' id='contactName' name='name' /> </td>
What that should PROBABLY look like is:
... or at least if you have any idea how HTML is supposed to work.
<form action="#" method="post">
<input type="text" id="contactName" name="name" />
Between the tables for layout, incomplete forms, inaccessible px metric fonts sending me diving for the zoom, and that to be frank it fails to automate enough of the process since you're almost typing in everything ANYWAYS...
Thank you for your valuable advice i will correct the flaws and will soon submit a more decent form generator. By the way i am not that good designer so messed up with colors. Can you suggest some reference where i can get it right.
Thank you again.
Colour contrasts is an accessibility thing, so the source you'd want for that is the WCAG -- web content accessibility guidelines.
Which is needlessly wordy -- like most W3C specifications and recommendations it's like it was written by a lawyer, not an engineer, so let me break it down simpler for you.
What they are saying is that if you convert your RGB colour to the luminance part of emissive HSL (Hue, saturation, luminance) that ideally you should have 75% difference. I usually say that with a clean large font 50% is the absolute minimum -- as per a joint UI design study done by IBM, Apple and Microsoft at the end of the '90's -- and that narrow fonts, small fonts, font smoothing, differences in rendering engines and so forth up it to that 75% or more...
Note that's EMISSIVE, not the reflective formula programs like Photoshop use since most paint programs like Photoshop, GIMP and Paint Shop Pro were originally designed for print, NOT screen. (NO matter how many people mis-use it for such).
The formula in question is:
Y = 29.9% Red + 58.7% Green + 11.4% Blue
This stems from that at 'maximum brightness' a normal healthy human eye is least sensitive to blue, and most sensitive to green; which oddly is a genetic quirk stemming from our ancestor's time in the bush. The formula is in the WCAG there somewhere, but can also be found in the IBM VGA specification, upon which all modern displays derive their functionality. On the VGA they use this formula to turn colours into greyscale. (people often forget there were some REALLY NICE "paper white" VGA CRT's back in the day, especially the one's IBM made for the PS/2)
Since we're dealing on modern displays with 8 bit wide values, thats 0..255, so our 50% minimum is 128 (rounded up), the ideal 75% is 192 and the "goofy fonts and sizes" ideal being 204 or more.
Now, let's do a simple example -- ever notice how red text on blue or vice-versa is illegible? Let's use the CGA/EGA/VGA 'bright red' (rgb 255, 85, 85) and 'bright blue' (85, 85, 255) and plug them into the formula. I like to round off all values to keep it simple when doing this by hand.
CGA Bright Red
R = 255 * 0.299 == 76~
G = 85 * 0.587 == 50~
B = 85 * 0.114 == 10~
Y = 76 + 50 + 10 == 136
CGA Bright Blue
R = 85 * 0.299 == 25~
G = 85 * 0.587 == 50~
B = 255 * 0.114 == 29~
Y = 25 + 50 + 29 == 104
Contrast = 136 - 104 == 32
32 / 255 == 0.125 == 12.5%
... and twelve and a half percent is so far away from our 50% minimum, if you put either of those colours as text atop the other, it is near impossible for half the population to read it, and those that can will have severe eye strain.
Note -- if working in greyscale it's far easier as all values are the same the Y ends up the same as any one of the colour components. CGA Dark Gray for example is #555555 == rgb(85,85,85) so Y == 85... and that's why light gray (#AAAAAA, Y = 170) is useless on dark gray as the difference is only 85, which is 33.3% contrast, aka 2:1, way short of our minimum desired level.
Right now you have a LOT of PSD Jockey's with the giant set of brass to call themselves "designers" who seem to be blissfully unaware of this... I'm seeing a LOT of sub 128 luma grays on sub 128 luma grays, or black on sub 128 grays -- and no matter how 'pretty' that is if nobody can read it, what good is it?
A nice side effect of following the math based on actual research of the human eye? It also means your page will be legible to the colour blind.
Hmm... math, based on multi-million dollar usability research by companies who actually made the hardware and established all the specifications; that might just be crazy enough to work!
Thank you for such valuable information. I will make good use of it.
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)