This concept applies to web forms, navigation, software options, and more. The faster the users get things done, the more satisfied they will feel, they'll use your solution even more and refer others to it. This post will be best suited in a thoughts / tumblr blog, but I figured it may get in here as well.

Inspiration

This post was inspired from the recent Windows encounters I've had. Remember the post on web forms usability published just a while ago? Well, while installing the Microsoft Office Suite downloaded after using that faulty web form, I got a new installation wizard out of the blue, which I didn't ask for.

For some reason, I was asked to install Business contact Manager for Outlook Express 2007. I have no idea what that is, but I assume what it's used for. Bottom line is I don't need it. On top of that is the really bad installer.

Let's assume someone wants to actually install it. The installer starts and shows one component that can be installed. The one I want. Why would you not simply let me get through with the process and require me to select the component to be installed. After all, moments ago I double clicked to install it? Why confirm that again?

What's even worse is that I cannot click the Next button until I select the unique component. Moreover, there isn't a "finish" installation button. It's a "Next" step button. I don't want to waste any more steps with this issue. Just let me get on with it.

To conclude, whatever you're doing, try to keep it simple and straightforward for your users. Don't frustrate them with never ending jibberish chat.

Two of the most popular articles published here deal with web forms. The first one is around the theoretical aspects of web forms while the second one resides along the practical issues, coding and validating web forms. This article blends some concepts from both articles and showcases a key error that mustn't be in your web forms.

The issues with required fields

The issue with required fields is that there shouldn't be any required fields on a web form. Don't place asterisks to label required fields. Nobody follows that pattern, though most users expect a field to be required if it has one asterisk appended to its label. If you have a web form that requires user's email, password, first and last names, don't put asterisks or any other messages. Just put the inputs in the form and the user will fill them.

Moreover, if you have those fields, don't place an asterisk only next to email and password and expect users to input their names as well. That will never happen! Following this pattern, after the user hits the submit button, don't display an error message telling them that the name fields are required as well, if you didn't point that out in the first place. This is usually something that will make visitors leave your website and never use your form, which was the primary goal for them upon arriving at that page.

That is total failure! Your mistake, not your user's!

Time to guess who has web forms with such flaws. It's Microsoft! The same company that has .exe executable download managers which users need to run to download any of their software. Mac users need to run them as well to download their operating system, for example, if they wish to switch to Windows, or use it virtually. But that's another story.

The moral

From time to time, I unfortunately need to use Microsoft Office and other Windows native software. Not my option though. While trying to download a trial version of the Office suite, I was asked to sign up on Microsoft's website. The form asked for my email, my desired password, first and last names, and my country. The first two we're marked as mandatory fields, while the rest weren't. The country field was a preselected select field, which I had nothing else to do but update.

After pressing the submit button, I wasn't taken to a download page. Instead, I was shown a couple of errors I've done. I haven't inputted any information in my name fields. But I didn't know I needed to. Thank god for Microsoft that the bid I was working on required specific documents (.docs) and I really needed to proceed, otherwise that would have been the end of my journey on their website.

Conclusion

Try to strip down the fields of your web forms. Not the required ones, but all fields. Don't ask for unnecessary information. Ask only mandatory information, and don't label it as mandatory. If your form is simple and short, users would be delighted to input what you're asking for.

There were no time penalties, a nice progress bar indicated where you were throughout the entire testing. Overall it was a nice experience, which seemed close to perfection. Oh but was I wrong! I don't know exactly how many questions were in there, but I think they were more than 50.

After roughly 30 minutes, I completed the task. I was asked to input my name and email and hit submit to have my results emailed to me. I knew ads on such a high traffic television site couldn't be cheap, and this wouldn't be a scam, so I went on and put in my details and clicked the submit button.

The next page was a disaster, completely ruining my experience, making me bounce off the website and write this article. Why? The thank you page didn't contain my test result. Instead it contained 2 phone numbers to which I could send a 5 Euro SMS to pay for the results they just said would be emailed to me. This was the first point in the entire process when I saw it is a paid service. After spending 30 minutes! And no, I won't pay and I didn't pay.

Let your users know your service isn't free right from the get go!

But would I've paid if I knew from the start it's not a free test? Probably! They lost a happy customer in added time, and they probably lost and will lose many more with this stupid system.

Tips to improve your paid service sign up process

1. Always let your users know it's a paid service from the moment they arrive to your page
2. Payment page should never be the last one of the signup process, unless users know from start how much the product or service costs
3. If the signup process is lengthy provide visual progress bars
4. Never cheat with these progress bars to fool users into thinking they're close to finish line when they're not

Conclusion

Always let your users know if they can use your paid service, and let them no before they start using it. Doing so afterward will probably make you loose almost every client. Always be honest about your offered service and price because at the slightest misinformation your customers will go straight to your competitors.

If you have any similar experiences or any other tips please share them in the comments. Please share the link with your friends. You can stay updated to new content via our RSS feed or by email.

Preview of the tutorial

Quite some time ago I have published the first part of this series. Today I'll tackle coding a good webform, styling it, client-side and server-side validating. The first part of the tutorial was extremely popular, and that's why I chose to merge parts two and three, which anyway are closely related.

PS: You'll need some patience digesting this tutorial as it turned out to be really complex.

The code I am about to present here is the one that has been used in our contact and request quote forms from our newly released web development website, just as the jQuery slider tutorial published a few weeks ago was used in our portfolio section.

Getting dirty with xhtml

I am not going to code all different label positioning options presented in the first article (inline, left-aligned, right-aligned, top-aligned). The one I chose for our website and will be showcased over here is the one with top-aligned labels.

I chose top-aligned labels because the page layout where the form is implemented doesn't allow a lot of horizontal space. The bonus was that potential clients could process it fast. Being a form with just a couple of fields, the vertical space required by the form is decent.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

<form action="contact-us-process.php" method="post" accept-charset="utf-8" id="contactform">
	<fieldset>
		<label for="name">Full name : </label>
		<div class="field">
			<input type="text" name="name" value="<?=$name?>" id="name" class="v-required" />
		</div>
		<label for="email">Email : </label>
		<div class="field">
			<input type="test" name="email" value="<?=$email?>" id="email" class="v-required v-email" />
		</div>
		<label for="phone">Phone : </label>
		<div class="field">
			<input type="text" name="phone" value="<?=$phone?>" id="phone" class="v-required v-digits" />
		</div>
		<label for="message">Message : </label>
		<div class="field">
			<textarea name="message" class="v-required"><?=$message?></textarea>
		</div>
		<label for="security">One plus two: </label>
		<div class="field last">
			<input type="text" name="security" value="" id="security" class="v-required v-security"/>
			<small>Sorry, we asked as we do not like spam</small>
		</div>
		<span class="clear">&nsbp;</span>
		<input type="submit" name="submit" value="Send the message" id="submit" class="button all-rounded" />
	</fieldset>
</form>

As you can see, all elements are wrapped inside a singular fieldset, and each input field is wrapped inside a div.field block element. The reason why all input areas are wrapped inside a div is because I wanted to add that nice border to each input element, border which needed to be consistent through input fields, textareas, select elements and more. As you'll see in a couple of minutes, the styling is achieved with just a few bits of CSS.

You may also ask what's up with the bits of php coding that are embedded in the input elements — the code that's emphasized above. You'll find out soon enough when we reach the final point of this tutorial: server-side validation.

The CSS

Without any CSS the form described above would look terrible, so let's see what we can do to make it shine!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#contactform { display:block; padding:0 0 1em 0; }
#contactform label,
#contactform input,
#contactform select,
#contactform textarea,
#contactform .field	{ display:block; float:left; clear:left; }
#contactform .field	{ padding:0.5em; border-radius:0.4em; -moz-border-radius:0.4em; -webkit-border-radius: 0.4em; 
					 background:rgb(228,228,228); background:rgba(51,51,51,0.1); }
#contactform .field span.error{ display:block; float:right; color:#FF0000; text-indent:0.5em; }
#contactform .field span.ok	{ display:block; float:right; color:#339933; text-indent:0.5em; }
#contactform label { margin-top:2em; }
#contactform input { width:20em; height:2em; line-height:2em; }
#contactform select { width:20.5em; }
#contactform textarea { width:30em; height:8em; line-height:2em; }
#contactform input,
#contactform textarea { color:#333333; line-height:2em; padding-left:0.5em; 
						font-family: "Lucida Grande", "Lucida Sans Unicode", "Lucida Sans", "DejaVu Sans", "Bitstream Vera Sans", "Liberation Sans", Verdana, "Verdana Ref", sans-serif; }
#contactform small { float:left; clear:left; }
#contactform .last { margin-bottom:2em; }

As we have a top-aligned form, all elements should flow beneath the one before it. We do this by floating all of them to the left and clearing the left side (lines 2-6). The field class is applied to divs that wrap all input elements. The one I said will be used to add a nice consistent border to input elements throughout the webform.

On line 7 we add padding to the field element, round the corners (if browsers support it), then set a transparent background, with fallback for browsers which do not support RGBA. I have used background instead of background-color because the later won't make the fallback RGB work.

The two span elements styled on lines 9 and 10 will be used for inline validation. Error messages will have the error class while confirmation messages will have the ok class. We need some space between different label & input groups in the form, that's why there's a top margin for each label.

On lines 12 to 14 we set the widths and heights of the input elements, while on lines 15 and 16 we style the appearance of basic input fields and textareas. The font-family is inserted here because textareas seem to have a mind of their own, and using em sizing will trigger unexpected results because of the font used. Choose a font that's different than your body's font and the textarea, though having the same specified size as a regular input field, will not have the same width as an input field.

Done styling. Let's validate data!

There's two ways we can validate data on a webform. One is by using client-side technologies, mainly JavaScript, and the other by using server-side technologies, be it PHP, ASP, Ruby or anything else you're using for your project. If you were thinking not to validate on the server-side if you have client-side validation, think again, because people could have javascript turned off and send malicious data to your server and databases.

This is why server-side validation is mandatory and client-side validation is optional, but can be used to really enhance the experience of your website's visitors.

Client side validation

In order to know how to validate each field in our form, we need to add specific classes to each one. v-required stands for a required field, v-digits is used for fields that should accept only digits while v-email is used for fields that expect and email address.

1
2
3

<input type="text" name="name" value="<?=$name?>" id="name" class="v-required" />
<input type="test" name="email" value="<?=$email?>" id="email" class="v-required v-email" />
<input type="text" name="phone" value="<?=$phone?>" id="phone" class="v-required v-digits" />

As you can see, our input fields have different classes assigned for our javascript to know how to validate. We've also assigned a unique ID to our form to be able to use it within our javascript. The validation script will have two main functionalities, one which will validate data on the fly (while the user is typing it and moving from a field to the next one), and one that will validate data when the submit button is pressed.

I am also using a dirty little trick. The validation will look inside the form for error classes. That's why on page load I am going to add an error class to each field that's required. When the user will type inside the field, the error class will be removed. When there's no error classes, data is valid and we can send it to our server for processing.

1

$('#contactform input.v-required,#contactform textarea.v-required').attr('rel','error');

Select elements have a value assigned by default, so they don't need specific validation.

On the fly client-side validation

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

$('#contactform input:not(.button), #contactform textarea, #contactform select').focusout(function(){
error = 0;
inputText = '';
inputText = $(this).val(); // this works for inputs
if(inputText.length==0) inputText = $(this).text(); // this works for textareas
 
classes = $(this).attr('class');
classesArray = classes.split(' ');
$.each(classesArray, function(index, value){
	if((value=='v-required')&&(inputText.length==0)&&(error==0))
	{// required field empty
		error = 1;
	}
	if((value=='v-digits')&&(testDigits(inputText)==false)&&(error==0))
	{ // field needs to be digits only
		error = 2;
	}
	if((value=='v-email')&&(testEmail(inputText)==false)&&(error==0))
	{ // field needs to be email format
		error = 3;
	}
	if((value=='v-url')&&(testURL(inputText)==false)&&(error==0))
	{ // field needs to be URL format
		error = 4;
	}
	if((value=='v-security')&&(testSecurity(inputText)==false)&&(error==0))
	{ // field needs to be URL format
		error = 5;
	}
});
 
if(error>0)
{// there's some errors
	if(error==1) 
	{ 
		$(this).next('span.error').remove();?$(this).next('span.ok').remove();
		$('<span class="error">This is a required field</span>').insertAfter($(this));
		$(this).attr('rel','error');
	}
	else if(error==2) 
	{ 
		$(this).next('span.error').remove();?$(this).next('span.ok').remove();
		$('<span class="error">Digits only please</span>').insertAfter($(this));
		$(this).attr('rel','error');
	}
	else if(error==3) 
	{ 
		$(this).next('span.error').remove();?$(this).next('span.ok').remove();
		$('<span class="error">Invalid email</span>').insertAfter($(this));
		$(this).attr('rel','error');
	}
	else if(error==4) 
	{ 
		$(this).next('span.error').remove();?$(this).next('span.ok').remove();
		$('<span class="error">Invalid URL</span>').insertAfter($(this));
		$(this).attr('rel','error');
	}
	else if(error==5) 
	{ 
		$(this).next('span.error').remove();?$(this).next('span.ok').remove();
		$('<span class="error">Incorrect answer</span>').insertAfter($(this));
		$(this).attr('rel','error');
	}
	else
	{ 
		$(this).next('span.error').remove();?$(this).next('span.ok').remove();
		$('<span class="error">Unknown error</span>').insertAfter($(this));
		$(this).attr('rel','error');
	}
}
else
{
	$(this).next('span.error').remove();
	$(this).next('span.ok').remove();
	$('<span class="ok">Ok</span>').insertAfter($(this));
	$(this).removeAttr('rel');
}
});

On the first line of the above code we identify all input elements in the form. The form has an submit button and we need to exclude it. Also, we're going to apply a certain behavior to the selected elements when the user focuses out of them.

On the second line we initialize a variable which we're going to use to track errors. 1 for required, 2 for digits and so on. On lines 3 to 5 we get the contents the user typed inside the element. As we won't know at runtime which type of element we are dealing with, we need to make sure we get the content properly. Hence the differentiation of textfields and textareas.

The next step (lines 7 and 8 ) is to get the classes of the element we're currently checking. Classes can be v-required, v-digits, v-email, v-url and alike. We split the classes and put them into an array. Then, we loop through each class and test accordingly (lines 9 to 30). Based on test results, we modify the error variable.

We then check if there's any errors reported. If there's no errors the code from lines 72 to 76 will make necessary adjustments to our html for the user to see the field was correctly filled. On the other hand, if there were errors reported, the code between lines 34 and 69 will check the actual error type and modify html accordingly. The user will know they've done wrong, and how they've done wrong.

Functions to extend the validation process

If you payed attention to the above code you've seen that there are some function calls, functions which are not defined. Therefor, we must declare a few functions before we try using this plugin. These functions are coming up next:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

function testEmail(value)
{
	return /^((([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?$/i.test(value);
}
 
function testURL(value)
{
	return /^(https?|ftp):\/\/(((([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(%[\da-f]{2})|[!\$&'\(\)\*\+,;=]|:)*@)?(((\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])\.(\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])\.(\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])\.(\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5]))|((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?)(:\d*)?)(\/((([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(%[\da-f]{2})|[!\$&'\(\)\*\+,;=]|:|@)+(\/(([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(%[\da-f]{2})|[!\$&'\(\)\*\+,;=]|:|@)*)*)?)?(\?((([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(%[\da-f]{2})|[!\$&'\(\)\*\+,;=]|:|@)|[\uE000-\uF8FF]|\/|\?)*)?(\#((([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(%[\da-f]{2})|[!\$&'\(\)\*\+,;=]|:|@)|\/|\?)*)?$/i.test(value);
}
 
function testDigits(value)
{
	return /^\d+$/.test(value);
}
 
function testSecurity(value)
{
	return ((value==3)||(value=='three')||(value=='THREE'));
}

As their name suggest these functions test emails and URLs for validity, if a string contains only digits or if the security question was correctly answered.

Validation upon submit

We've seen how we validate data on the fly. Let's see how we validate data when the user clicks the submit button or presses enter.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93

$('#contactform').live('submit',function(){
		$('#contactform input.button').attr('disabled','disabled');
		$('#contactform input.button').val('Processing request');
		errors = 0;
		$('#contactform span.error').remove();
		$.each($('input[rel=error],textarea[rel=error],select[rel=error]'), function(){
			errors++; // count if there are errors
				error = 0; 
				inputText = '';
				inputText = $(this).val(); // this works for inputs
				if(inputText.length==0) inputText = $(this).text(); // this works for textareas
 
				classes = $(this).attr('class');
				classesArray = classes.split(' ');
				$.each(classesArray, function(index, value){
					if((value=='v-required')&&(inputText.length==0)&&(error==0))
					{// required field empty
						error = 1;
					}
					if((value=='v-digits')&&(testDigits(inputText)==false)&&(error==0))
					{ // field needs to be digits only
						error = 2;
					}
					if((value=='v-email')&&(testEmail(inputText)==false)&&(error==0))
					{ // field needs to be email format
						error = 3;
					}
					if((value=='v-url')&&(testURL(inputText)==false)&&(error==0))
					{ // field needs to be URL format
						error = 4;
					}
					if((value=='v-security')&&(testSecurity(inputText)==false)&&(error==0))
					{ // field needs to be URL format
						error = 5;
					}
				});
 
				if(error>0)
				{// there's some errors
					if(error==1) 
					{ 
						$(this).next('span.error').remove();?$(this).next('span.ok').remove();
						$('<span class="error">This is a required field</span>').insertAfter($(this));
						$(this).attr('rel','error');
					}
					else if(error==2) 
					{ 
						$(this).next('span.error').remove();?$(this).next('span.ok').remove();
						$('<span class="error">Digits only please</span>').insertAfter($(this));
						$(this).attr('rel','error');
					}
					else if(error==3) 
					{ 
						$(this).next('span.error').remove();?$(this).next('span.ok').remove();
						$('<span class="error">Invalid email</span>').insertAfter($(this));
						$(this).attr('rel','error');
					}
					else if(error==4) 
					{ 
						$(this).next('span.error').remove();?$(this).next('span.ok').remove();
						$('<span class="error">Invalid URL</span>').insertAfter($(this));
						$(this).attr('rel','error');
					}
					else if(error==5) 
					{ 
						$(this).next('span.error').remove();?$(this).next('span.ok').remove();
						$('<span class="error">Incorrect answer</span>').insertAfter($(this));
						$(this).attr('rel','error');
					}
					else
					{ 
						$(this).next('span.error').remove();?$(this).next('span.ok').remove();
						$('<span class="error">Unknown error</span>').insertAfter($(this));
						$(this).attr('rel','error');
					}
				}
				else
				{
					$(this).next('span.error').remove();
					$(this).next('span.ok').remove();
					$('<span class="ok">Ok</span>').insertAfter($(this));
					$(this).removeAttr('rel');
				}
		});
 
		if(errors==0) return true;
		else 
		{
			$('#contactform input.button').removeAttr('disabled');
			$('#contactform input.button').val('Correct errors and resend');
			return false; 
		}
	});

First line binds the submit event to the function to be executed. The following two lines disable the submit button and change the text on it. This way users won't be able to submit again the form if their connection is slow or the server is on heavy load. Changing the text will also alert users that their action was successful and their request is being processed.

We remove all error span elements that may have been added by on the fly validation because the code that's about to be executed will make the final checkups all over again. The code between the 8th line and the 82nd will check all fields that have an error class assigned to them, check out what is required for the field to validate and display messages just as the inline validation does (on the fly validation).

If no errors are reported, the function returns true and allows the form to submit itself (the return true on line 86 does the trick ). If there were any errors reported, the submit button's text is set such that the user sees there were processing errors. During this stage (lines 89 to 91) the button is re-enabled and default behavior of the form is prevented. The return false won't allow the form to be submitted towards the server's processing script.

That's all folks. We're done with client-side validation, but as mentioned above, we need to move to the mandatory part of the validation process, which is done on the server, were nobody can ruin things.

Server side validation

I'm going to cover a server side validation process written in php. PHP is very popular and other languages or frameworks such as RubyOnRails are straightforward when it comes to validating data in forms. As you've seen in the beginning of the tutorial, we have a couple of input fields and textareas we need to process. Therefor, we start our PHP by getting and storing the data filled in by the users.

1
2
3
4
5
6

		$name=$_POST['name'];                                    
		$email=$_POST['email'];
		$phone=$_POST['phone'];
		$company=$_POST['company'];
		$message=$_POST['message'];
		$security=$_POST['security'];

We then check if there's any required field that has not been filled. If javascript is on, these validation lines of code are pretty useless, but they need to be here because they are the last ones preventing malicious data entering your webserver.

1
2

	if(($name=='')||($email=='')||($phone=='')||($message=='')||($security==''))
        { //some error message }

If there were no errors at the previous check, we move forward and check if the email is valid, if the phone number contains only digits and if the security question has been answered correctly.

1
2
3
4
5
6
7
8
9

else if ( !preg_match( "/^[-\w.]+@([A-z0-9][-A-z0-9]+\.)+[A-z]{2,4}$/", $email) )
		{ //error message
                }
else if(!is_numeric($phone))
		{ //error message
                }
else if(($security!="three")&&($security!="3")&&($security!="THREE"))
		{ //error message 
                }

If we got up to this point, our data is valid, there were no errors and we can process it. If you care to send an email, you can do that. If you want to add information to the database, you might do that as well.

1
2

else { // no errors, process data in here                                
       }

Server side enhancements

In the beginning of this tutorial I've pointed out that our form contains bits of php coding. The reason those variable printing are present is the following: The webform can be stored inside an external php file, which is included in our contact page. The processing page also includes this file if there were error messages. The result? The data users entered in the first stage, which is unfortunately invalid, is preserved. This enhances user experience as they don't have to type everything all over again but to correct their mistakes. Awesome right?

Conclusion

We've finally reached our ending point. We've learned in the first part of the tutorial the structures web forms can adopt, were to use them and why to use one over another. During this second part we've learned how to code a top-aligned form, style it using modern technologies such as CSS3, how to validate its data using javascript (client-side), and how to validate data server side using php.

I hope you all enjoyed the tutorial. Please share the link to your friends. You can stay updated to new content via our RSS feed or by email.

Must read

• 1. Forms. Can’t live with them. Can’t live without them. (First part of this series)
• 2. Make your own jQuery slider using XML
• 3. The Smashing Book is indeed… Smashing!
• 4. Enhance your clients list page with jQuery goodness
• 5. The change is here. Hover events come to mobile devices
• 6. Consistency. Key element in extraordinary UX
• 7. Buttons and usability

Scrolling wheels are usually used to navigate up and down or left to right on a page that is larger than the default viewport of the browser. However, by using JavaScript one can enhance the user interface of a site or webapp and reprogram, if I may say it like this, the default behavior of the scrolling wheel.

Good scenarios

If a web document contains textareas or block elements with overflow set to auto and the content inside these elements extends the area of the element itself a scrolling bar will appear, be it horizontal or vertical. By default, users will be able to scroll inside these elements by pointing the mouse inside the element's borders and use the scrolling wheel. If positioned outside the element when using the scrolling wheel the entire page will scroll. This is a good feature. Moreover, it is what users expect to achieve given these circumstances. And this works without developers doing anything.

Bad scenarios

Many modern websites use inline slideshows or sliders to showcase more content in less space, from photo galleries to product features and more. However some sites enhance these sliders in such a bad way that they completely screw up user experience. Check out João Andrade's website and try to scroll down to the bottom of the page where a contact form is located — contact form which is the selling point of his website. Unfortunately you get stuck in the header of the site because there's an enhanced "awesome" slider which moves to next or previous slides based on how you use the scrolling wheel.

This feature is bad because it redirects the default behavior of the scrolling wheel away from the page scrolling bar, and if you're not quick in reactions you'd think that the site is buggy. This feature would probably be ok if the slider would be properly delimited from the rest of the page and the slider's numeric controls would stand out, just as a textarea or block element that overflow delimit themselves nicely due to the scrolling bar that pops out near the right border of the element. Currently, the slider on João Andrade's website blends in beautifully inside the page.

If you enjoyed this article you can stay updated to new content via our RSS feed or by email.

Further reading

• 1. Make your own jQuery slider using XML
• 2. The Smashing Book is indeed… Smashing!
• 3. Enhance your clients list page with jQuery goodness
• 4. The change is here. Hover events come to mobile devices
• 5. Consistency. Key element in extraordinary UX
• 6. Buttons and usability

Just in case you didn't realize, a couple of days ago I have removed the unused header here on Web International Awards. When the blog got redesigned last year in March, that header was planned to hold huge thumbnails — if huge thumbnails is correct. However, things took off and I didn't have time to finish the header and really implement post thumbnails for the most popular articles that we've published.

Finally, I got some spare minutes, and I completely removed that ugly header and awful message it contained. The reason why I am giving this advice is that soon after the unused header was removed, the number of pages/visit improved with around 20%, and that can't be just a simple coincidence.

Therefor, be careful to keep the main content of your sites as high as possible. Perhaps if I fully developed the features of the header it would have resulted in better traffic towards older articles, but I think it is more important to keep new visitors as long as possible on current articles.

If you enjoyed this article you can stay updated to new content via our RSS feed or by email.

Further reading

• 1. The change is here. Hover events come to mobile devices
• 2. Should I use on hover behavior?
• 3. Javascript DOs and DONTs. Complete with 17 examples from real web
• 4. Consistency. Key element in extraordinary UX

Delete links and buttons

You're responsible for each user who's frustrated because they accidentally clicked your delete button, and there's no way to restore their deleted work. This problem usually resides around web apps because only a few web apps offer undo / redo behaviors.

Mailchimp asks for delete confirmation, as you can see in the above screenshot. To make things worse, the popup takes ages to load, so the interface doesn't go as smooth as you'd want. Moreover, the confirm and cancel buttons are in close proximity. What if I accidentally click delete, than accidentally click confirm?

Cancel buttons in forms

The same goes with forms and their cancel buttons. Many forms have cancel buttons although I don't see their point. If you wish to cancel what you've done in a form, you simply go to another page or hit the X button.

However, some insist and put a cancel button in the form. Moreover, they don't just put it in a remote area of the form, they put it right next to the submit button. This inevitably leads to users accidentally clicking it instead of the submit button, which means even more frustrated users.

As you can see in the screen above, Five Cent Stand exaggerated with their creativity. Of course, their form is lovely, but can you see how close and similar are the send and clear buttons? You can barely see there's two distinct buttons. Really, really bad solution.

X or close buttons

Then there's the X (close) button which a few years ago was used only in desktop apps. Since the new rich user interfaces available on the web, a large number of web apps have lots of windows, and you guessed it, X buttons. The problem is nobody asks or tests if the clicks on these buttons are accidental or not. Making such check ups would be hard. And if you can't, you should check with the user if they meant it, which leads to our next problem.

What if we asked users if they really like to perform that destructive action (X, delete, cancel) or not? This sounds so Windows right? Moreover, this would frustrate and irritate even more users than before.

The percentage of users actually wanting to click those buttons is way higher than those who do it by accident. This means they'll get pissed of with you for asking them for confirmation all the time.

Is there a solution ?

It has to be, and here are some suggestions I thought might work. Let's start with the X button. One click may be unintended. How about a double click? I don't think that one could double click by accident. Even if that happened it would be just one user not plenty of them! The overall experience of almost everybody would definitely improve.

One solution for the forms canceling button would be placing it somewhere remote, far from the submit button, and styling it differently. What about delete buttons? A solution I think could work great is inspired from the Apple iPhone/iPod collection.

What if we developed delete and cancel buttons in a "slide to delete" fashion? Clicking them won't do any harm, but clicking and sliding for 30 pixels or so would trigger the event? Now wouldn't that please anyone?

Feedback

Please share your thoughts on this topic in the comments section. If you enjoyed this article you can stay updated to new content via our RSS feed or by email.

Further reading

• 1. The change is here. Hover events come to mobile devices
• 2. Should I use on hover behavior?
• 3. Javascript DOs and DONTs. Complete with 17 examples from real web
• 4. Consistency. Key element in extraordinary UX

I think that everyone knows that awesome YouTube movie about technology and how things that we learn today will become obsolete in 6 months or maximum 1 year. Well, when I published the hover behavior article just a few days ago, I certainly didn't think what I advised there will become obsolete so fast. I mean, I didn't see hover behavior coming to mobile devices this soon. Having this said, before going on with this article you should read the first article on hover events.

Apple has been granted a patent which has a mind blowing description, because it tackles proximity based systems and methods. What are those you may ask? Proximity methods are methods that a device can use to detect if there's an object placed in close proximity to its surface. Like a finger pointing above the iPhone's touch screen. Such method would also include performing an action if such an object is sensed.

Basically, this describes hovering events triggered by fingers, not just one finger. Apple has multitouch interfaces so why shouldn't they have a similar multihover event? At first hand, having such a feature in an iPhone, iPad or iPod would be great, because all the issues I described in the first article on this topic would disappear!

But would they?

No they don't! In fact, such a feature in mobile devices would only complicate the situation, because users could easily trigger lots of hover events simultaneously on a web page or web app. This has never been thought of and web developers have never taken this into consideration as PCs don't have multiple mouse pointers. This means there's no protection in websites against such worst case scenarios. Imagine a user viewing a drop down navigation menu that displays multiple menus in the same time. Imagine what their reaction would be, especially if the scenario happened by accidental hovering and the user would be taken by surprise. I also don't think that such a menu would be easy to use.

Such a new technology would technically fix the hovering issues of mobile devices, but would also trigger new ones, like the scenario described above, and would also give us power to create even greater interfaces by using multihover events. How cool would it be to point your finger to a product or pinch without touching the device to pop out details, and then click to buy it?

Here's a link to the patent (Granted Patent 7,653,883, originally filed in Q3 2005 by Steve Hotelling, Duncan Robert Kerr, Bas Ording, Jonathan Ive, Peter Kennedy, Anthony Fadell and Jeffrey Robbin).

Feedback

Please share your thoughts on this topic in the comments section. If you enjoyed this article you can stay updated to new content via our RSS feed or by email.

Further reading

• 1. Should I use on hover behavior?
• 2. Javascript DOs and DONTs. Complete with 17 examples from real web
• 3. Consistency. Key element in extraordinary UX
• 4. Enhance your clients list page with jQuery goodness

Yes, you should! Why not? After all, you could really enhance your user interface. However, using such a behavior could also tear apart user experiences, especially if your visitors are using mobile devices like the HTC Touch, the iPhone or the newly released iPad. Such devices unfortunately cannot "feel" your finger above the screen so there's no hovering triggered in their browsers.

Before choosing hover events in your websites or webapps you should probably check how much of your site's visitors are represented by mobile users. If the percentage is decent, I wouldn't use hovering and switch instead to the traditional click. Envato's marketplaces have been featured on Webia before for their awesome consistency across all websites, which was a good thing.

I am about to talk about a slightly bad thing on Envato's marketplace sites. Each of them has a categories button just below the logo, which if hovered with a mouse expands and shows popular categories. Clicking on such a category will redirect you to that category's dedicated page, while clicking the categories top button will trigger nothing.

Now that's ok if you're using a computer, notebook or anything that comes with a mouse. If you're using a mobile device you simply cannot jump to a category you love. This means you have to go for a work around, which is nowhere to be found if you're not a regular user.

Who does this right?

If you think we're going to jump light years away to find another site that does this well, you're wrong. Remember that we talked about the logo, located just above the categories button? Well, next to the logo are two small arrows pointing out that something happens over there. If you click that small button you get a dropdown menu similar to the one you get when checking out categories. This menu is used to rapidly switch between Envato's marketplaces. My question is why did Envato implement click on their marketplace switch and hover on their categories menu?

If you enjoyed this article you can stay updated to new content via our RSS feed or by email.

Further reading

• 1. Javascript DOs and DONTs. Complete with 17 examples from real web
• 2. Consistency. Key element in extraordinary UX
• 3. Enhance your clients list page with jQuery goodness

Demo preview?

Just in case you can't wait till the end of the article, here's a demo of what we're doing today in this tutorial.

Concept

Each time you get to a site to check out who works at a certain company you end up on a page that looks dull and familiar. Sometimes you have all the management team or if the company is kinda small all the people employed. You have for each one a picture, a name and perhaps some contact information. Sometimes there's even a short bio.

All this information is usually boxed in the same way. Picture to the left, name beneath the picture, bio to the right and contact information underneath the bio. If there's no bio, you simply have contact information to the right.

I am sick and tired of this "inside the box" thinking. In fact, I recently stumbled on the site of a company that could have been my client today - I paid them a visit about three years ago. Found the office closed with no information provided. There was no secretary. I had nobody to pitch to, so no new client. They now have a nice page to round up the management of the company. Unfortunately, the implementation lacks my minimum moral standard.

If I recall correctly those functions that start with function MM_swapImgRestore() are generated via Dreamweaver, which in my opinion is for, uhm, well, kids. The rollovers are created using Flash. I borrowed the concept and did a XHTML / CSS / jQuery implementation. Moreover, I am sharing the full source code and the development process as a tutorial, and you can use it for free as long as you credit the author.

Original design

The site where I got this idea from is the site of a local constructions company called Edil Concept. Sorry it is available only in Romanian. Check out how their team page looks like. It has those nice image rollovers and the right box next to them for displaying information. It does have a small downside though. If you want to email that dude in the middle of the team - which is actually the company's manager - you have to write down his email on paper, because content changes when you hover any of the images, and his stuck in the middle.

Improved design

Here's what we want to achieve. First of all, the above described layout should be achieved using only XHTML and CSS. No tables as they are so old and ugly. We also want to change from hovering behavior to clicking behavior. Doing so will ensure that you can actually use the information displayed for the middle guy. In order to achieve this we will use jQuery. The hovering effect will be kept, so that people look around as you go through them. As it turns out, doing this on hover, really, really doesn't work. Do not try this at home! No really, don't!

Don't believe me, just see here what happens if hovering behavior is preserved.

The layout

We will have three major boxes in this layout. We will have a wrapper, a photos and a text box. The wrapper will hold the content in place, in the middle of the page. The photos will hold the 9 pictures we will have - our demo company has 9 employees. I don't think I need to say what the text box will contain. Check out the layout page.

The XHTML

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<h1>Team page demo</h1> <!-- title so demo looks nice -->
 
	<div id="wrapper"> <!-- hold content in place -->
 
		<div id="photos"> <!-- hold all pictures together -->
			<a class="member" id="img1"><img id="image1" src="images/default.jpg" width="140" height="140" alt="Default" /></a>
			<a class="member" id="img2"><img id="image2" src="images/default.jpg" width="140" height="140" alt="Default" /></a>
			<a class="member" id="img3"><img id="image3" src="images/default.jpg" width="140" height="140" alt="Default" /></a>
			<a class="member" id="img4"><img id="image4" src="images/default.jpg" width="140" height="140" alt="Default" /></a>
			<a class="member" id="img5"><img id="image5" src="images/default.jpg" width="140" height="140" alt="Default" /></a>
			<a class="member" id="img6"><img id="image6" src="images/default.jpg" width="140" height="140" alt="Default" /></a>
			<a class="member" id="img7"><img id="image7" src="images/default.jpg" width="140" height="140" alt="Default" /></a>
			<a class="member" id="img8"><img id="image8" src="images/default.jpg" width="140" height="140" alt="Default" /></a>
			<a class="member" id="img9"><img id="image9" src="images/default.jpg" width="140" height="140" alt="Default" /></a>
		</div>
 
		<div id="moretext"> <!-- hold content that will show up once photos on the left are clicked -->
			<span>Click the images on the left to view detailed information about us.</span>
			<h2></h2>
			<h3></h3>
			<h4></h4>
			<h5></h5>
			<h6></h6>
		</div>
 
	</div>

XHTML explained

I won't explain all the small details behind the XHTML code above. However, I feel I need to explain why images are wrapped in anchor tags. I did this so that I could easily style the hover event of images with a nice border, and to cleanly add spacing between images. I also added an ID attribute to each anchor tag because I am going to use those combined with jQuery. Each image has an ID attribute too because we will need to change the SRC attribute of each image when one of them is pressed. We do that with jQuery and use the IDs to identify the elements, that's why make sure your IDs will have unique names if you use this in a production environment.

The #photos div will be floated to the left, while the #moretext div will be floated to the right. The heading tags will be populated with content once an image is clicked, while the span tag will be removed when that happens. We don't need IDs for these heading tags as they're all different and share the same parent. We can identify them by their parent and type.

CSS code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

/* RESET - we don't want anything to interfere with our styles */
*										{ margin:0; padding:0; border:0; outline:0; font-weight:inherit; font-size:inherit; }
/* END RESET */
 
/* GLOBAL LAYOUT CONFIG */
body									{ margin:50px 0px 0px 0px;
										  font-family: "Lucida Grande", Verdana, sans-serif; } /* don't let content start right from the top */
h1										{ display:block; text-align:center; width:800px; margin:0px auto; height:30px; font-size:1.3em; }
#wrapper								{ display:block; margin:0px auto; width:800px; height:450px; } /* set width and height, positioning */
#photos									{ display:block; height:450px; width:450px; float:left; } /* set width, height and floating */
#moretext								{ display:block; height:430px; width:330px; float:right; padding:10px; background-color:#EEE; } /* set width, height, floating and background color of text area */
 
/* END GLOBAL LAYOUT CONFIG */
 
/* PHOTOS STYLING */
#photos .member							{ display:block; padding:0px; border:5px solid #CCC; width:140px; height:140px; float:left; }
#photos .member:hover					{ border:5px solid #333; }
/* the most important attributes are the floating, and the border used to space the elements */
/* END PHOTOS STYLING */
 
/* simple text styling */
#moretext span							{ font-size:0.8em;}
#moretext 								{ color:#333; }
#moretext h2							{ font-size:1.2em; }
#moretext h3							{ font-size:0.7em; }
#moretext h4, #moretext h5				{ font-size:0.8em; }
#moretext h6							{ font-size:0.7em; padding-top:25px; }

CSS explained

We set document limits, then set the wrapper's dimensions. Somewhat important is the width and height of the photos box, which is 450 pixels because we have 3 images on a row, and 3 different rows. This means each image should be 150 by 150 pixels. That is not true however due to the fact that we added the anchor tag which has a 5 pixels border. Therefor images should be 140 pixels in height and width. You can check how the layout looks with CSS applied to it over here.

As you have seen so far, neither the XHTML nor the CSS are complicated, and hopefully the jQuery will not look complicated at all. With this said, let's jump into the interesting part of the article.

Scripting with jQuery

Clicking on images doesn't trigger anything yet. That's why we need to spice things up with a little jQuery. We will be using jQuery's .click(), .remove(), .attr() and .text() functionalities. It is obvious what .click() will be used for. The .remove() function will be used to remove the welcome text - which is contained in the span tag - out from the text box after the first click on an image.

.text() will be used to change the contents of the heading tags once images are clicked, while the .attr() will be used to change the SRC attribute of images as we click through them. Take a look at the jQuery code to see what you're up against.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

$(document).ready(function(){
 
	// the following code will remove the info on top of the right box
	$("#photos a").click(function ()
		{
		$("#moretext span").remove();
		});
	// the following 9 functions will edit information about each employee
 
	$("#img1").click(function ()
		{
		// change the text in the right box
		$("#moretext h2").text("Bogdan Pop");
		$("#moretext h3").text("General Manager");
		$("#moretext h4").text("+40 (954) 037 910");
		$("#moretext h5").text("mailhere@domain.com");
		$("#moretext h6").text("Bogdan Pop is a young Romanian entrepreneur who runs WebRaptor. He loves web programming and design and has a passion for standards and SEO. He relaxes by taking photos every once in a while and by mixing french electronic music.");
		// change the pictures on the left
		$("#image1").attr("src","images/hey.jpg");
		$("#image2").attr("src","images/l.jpg"); 
		$("#image3").attr("src","images/l.jpg"); 
		$("#image4").attr("src","images/t.jpg"); 
		$("#image5").attr("src","images/lt.jpg"); 
		$("#image6").attr("src","images/lt.jpg"); 
		$("#image7").attr("src","images/t.jpg"); 
		$("#image8").attr("src","images/lt.jpg"); 
		$("#image9").attr("src","images/lt.jpg");
		});
	// 8 more .click functions will be here
});

jQuery explained

The first thing that happens when we click an image is the removal of the span tag together with its content. We do that with the .remove() function that we call upon the tag we're looking for. That is identified using #moretext span identifier, and we call it once an image is clicked. We do that with the .click() trigger applied to the anchor tags that wrap the images: #photos a. Here's the code that does that.

1
2
3
4

$("#photos a").click(function () // function called when image anchor is clicked
	{
	$("#moretext span").remove(); // remove the span tag inside the #moretext div
	});

Next, whenever a specific image is clicked, like the one above identified as img1 using its ID, we need to change the text of the heading tags in the text area of the demo (#moretext div) and also update the sources of all images. As you've seen in the original site or in the live demo, we change the image of each employee to appear as if they were all looking to whom you've just clicked upon. Here's the code we use to change a heading tag as I've just described.

1

	$("#moretext h2").text("Bogdan Pop");

In the above code I've identified the level two heading and changed its contents using jQuery's .text() function. By using the .attr() function with two arguments, we change the SRC attribute of an image. We identify images using their IDs that we uniquely named them with in the XHTML such as image6. Here's the code used to change the source of an image.

1

	$("#image6").attr("src","images/lt.jpg");

The result

This is pretty much everything you need to know to achieve what I've done in this demo. Because the entire jQuery code used is almost 200 lines of code, I haven't posted it entirely over here, but it is basically the same scenario as applied above to img1, and it is fully available in the source code of this tutorial. Sprinkle.js file is the one used to achieve the demo in this tutorial, while sprinkle_hover_crazyness.js is used to achieve a page that works similarly to the original site, which I don't recommend.

Download

You can download and use the code above from here. If you enjoyed this article you can stay updated to new content via our RSS feed or by email.