So, don't ask if I am human and expect an answer other than yes or no. SDUIHA or jgV54D is not a valid answer if you asked me if I were human. Imagine you asked a Japanese what was their name and they replied Sushi. Now that wouldn't be a great start, would it? So to wrap things up, never ask anyone if they're human and expect gibberish in return. One bad example from Hongkiat is just below.

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

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

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.

What language does your local store clerk speak? Your own language you say. What language do the web forms you build speak? Do they speak the same language as your site's visitors? Your clerk greets you with a smile. Do your forms smile to your clients?

It is fascinating how bad web forms look and work on most sites that are out there. The problem is that they are usually on the last place on the to-do or check-up list, which is totally wrong. Let me explain why this approach is wrong. A web form is practically the clerk of a site, whether it is a simple site or a huge e-commerce website. As you have the clerk in the supermarket to handle check out, you have web forms on the web to handle all sorts of things, from contacts, to payment processing, to newsletters signups and so on. All these features inside your site are powerful tools for your business.

Not caring for your web forms is not caring for your clients! Not caring for your clients is not caring for your business!

Put yourself into your customer's shoes. From now on, you will have to build web forms accordingly, because better web forms will attract more prospects, which will end up in more sales, and better business. This sounds great given the financial crysis that has got many businesses bankrupt.

This article will cover all you will need in order to create useful, beautiful forms. The first part will handle the theoretical part, describing different scenarios and structures web forms could have. The second part will cover the XHTML / CSS implementation of all forms, and the last part will cover the validation and processing of the forms.

PART I

If you got here, you know that web forms suck. I don't like them, you don't like them, our customers don't like them. Nobody likes web forms. That usually happens because we don't design them the right way. Most of us make forms to get information about everything, then do something with it when our goal should be getting everybody through the form as quickly and easily as possible. We want a lot of information from our customers, but they are facing a stranger. They are facing a stranger who wants their information. Why should they give it to us.

When someone comes to a form, they want to get passed it and do whatever they were promised to be able to do before completing the form. That's why the number one priority when building a form should be keeping it simple. And now comes the hard part. Forms can be designed in many ways, but which one is the simplest? Well, to tell you the truth, I haven't found the answer yet. But hey, at least I tested some options.

First thing's first. Make sure you strip out content that you don't really need! Don't think about sending an email to your client? Don't ask them their email. Don't want to fax them? Don't ask for fax numbers. Once you have the few questions you really need to ask, you can outline them in different ways inside an online form.

The 4-ways of forms

If you look around all forms on the internet, they all share something. A bunch of them have right-aligned labels, some other have left-aligned labels, some have top-aligned labels, and lately, there's some forms out there that have labels inside the input fields. But which one is best? That depends on the purpose of each form. So lets check out each and every one of them.

Inline labels

Inline labels are great, because they can reduce the amount of space your form spans across. However, these forms are usually handled with a relatively big amount of coding. We have two scenarios for these kind of forms.

Static text within input fields

What happens here when a user clicks inside a label is, well, nothing. Given the "username" field, clicking it means that the user has to first delete the text, and then input his actual username. This is ok for small forms, but doing this on a huge form will definitely scare you off.

Dynamic text within input fields

These input fields work like magic, because when the user clicks the input field, the "username" label text just disappears, and they can input their username quickly. Great.

The downside of both solutions is that we practically cannot use this kind of design on long forms. Short forms like searching or logging could really use this design technique, but long forms no. That is simply because when you're finished and want to check the form before submitting, there's a big chance you don't remember what the questions were.

Pros for inline labels

1. Reduce the space required by the form

Cons for inline labels

1. Not knowing what you answered for
2. Label text doesn't go away, and distracts the user while typing
3. Label text goes away on click, and doesn't come back if the user didn't type anything

Left-aligned labels

These forms are best if you request god knows what information, and the users need to check out personal documents in order to know how to answer your questions. Left aligned labels help because all questions are one below each other, and input fields do not interfere. This way, users can scan to see what they are asked for, and get prepared before setting on the quest of completing your form.

The next thing these forms are good at is reducing vertical space. However, if you have long questions, this may be an issue as the width of the form will extend, and sometimes the overall layout of a form could be completely messed up. Nowadays however, browser screen resolution is pretty big, so this issue probably isn't a big problem. But make sure that the percent of mobile visitors is low if you're willing to adopt such a form.

Pros for left-aligned labels

1. Reduce vertical span of the form
2. Easy scan the questions before doing anything else

Cons for left-aligned labels

1. Harder to connect the labels with their adjacent input field
2. Increased horizontal space the forms spans on

Right-aligned labels

Right-aligned labels have the same disadvantage as left-forms do, so if the horizontal space is not generous, they are not an option. On the other side, if the left-aligned forms are bad in terms of connecting each label with its corresponding input field, right aligned labels don't suffer from that, as they are inches away from the input fields. However, these forms cannot be easily scanned. Basically, these one are the exact opposite of left-aligned labels. Well, not exactly, but you'll see why further along.

Pros for right-aligned labels

1. Reduce vertical span of the form
2. Easy to connect the labels with their adjacent input field

Cons for right-aligned labels

1. Hard to scan the questions before doing anything else
2. Increased horizontal space the forms spans on

Left/Right or Right/Left

Now, in the western world, we read text from left to right. Therefore, we can scan left-aligned labels very fast. However, have in mind that Arabic and Hebrew are read from right to left, so right-aligned labels are scanned easier in such a case. Make sure you make the right choice based on what language your visitors speak.

Top-aligned labels

Top aligned labels are great. They are somewhat easy to scan through. They can have long questions, without worries of destroying the overall layout. Some questions, like city and zip code or phone and ext. could be grouped together on the same line. Having the labels on top of input fields means faster and easier processing. So, you should probably use these kind of forms whenever you want to get the thing done fast, and vertical space is not an issue, because yes, they do take up quite some vertical space.

Pros for top-aligned labels

1. Can have long questions.
2. Can group together similar information
3. Fast processing
1. They need a lot of vertical space
2. They can't be long just for the above reason

Completion times of all 4 types

Left aligned labels could have quite some span between them and their adjacent input field, so users are forced to take more time when interacting with the form. The right aligned labels reduce the eye fixations imposed by the left aligned labels to almost a half, and reduce the cognitive load users need to complete the form. Top aligned labels allow users to capture the label and input field at once, with only one eye movement. Inline fields are a better than top aligned labels, but remember when you must not use them. For further info on completion times, you can check out Matteo Penzo's article Label Placement in Forms.

Must read

I totally recommend you read Luke Wrobleski's book Web Form Design: Filling in the Blanks. The amount of valuable information it contains is priceless.

Conclusion

We are now done with the theoretical part of web forms design. Well, we know the basics of web forms design. In the next part of this tutorial we will discuss how to implement using XHTML and CSS all the 4 types of forms described above. Stay toned.

PART II and PART III

Part two and part three of this series will contain the XHTML & CSS for the forms and form validation. If you liked this article you can stay updated and get new content via our RSS feed.

Comments

Now if you reached this far, I really recommend reading forward the comments section two, because there's plenty of useful information shared there as well.

]]> http://www.webia.info/articles/usability/forms-cant-live-with-them-cant-live-without-them/feed/ 8 http://www.webia.info/articles/graceful-flash-degradation-reloaded/ http://www.webia.info/articles/graceful-flash-degradation-reloaded/#comments Mon, 21 Sep 2009 11:07:25 +0000 Bogdan Pop http://www.webia.info/?p=582

A couple of weeks ago I talked about graceful flash degradation: what it means, issues that arise while developing in flash, and how to fix them properly. This is the second article on the topic. Before we continue, make sure you're familiar with the first article on flash degradation, because this article contains examples to emphasize what the previous article described.

Good flash degradation from New York Times

We previously stumbled upon UEFA's site and a wine company's website. Today we are looking upon a newspaper's website. The name is self explanatory, New York Times being the largest metropolitan newspaper published in the United States. Having that weight attached to their necks, they knew their online presence must be perfect. And it is.

New York Times has an online photojournalism section which is built in flash. It is consisted of a series of posts, each around an image. Each post has apart from the image, a brief paragraph describing the picture, where it was taken and so on. A nice feature is the small sneak peak to the next and previous articles, which are visible in the left and right sidebars of the article you are currently viewing. However, I don't think this was a feature they specifically developed, as the full screen mode lacks it.

What really matters here is that they also have a non flash version of the site which kicks in if you do not have the necessary plugins. They also let you know that if you want to fully enjoy the features of the site, you should install flash player. Flawless solution. Great job for New York Times, but perhaps more congrats should go to the site developers, whoever they are.



If you have any other examples or pointers please leave them in the comments section bellow. If you liked this article you can subscribe to the full content rss feed and stay updated as we post new information.

]]> http://www.webia.info/articles/graceful-flash-degradation-reloaded/feed/ 1 http://www.webia.info/articles/site-redesign-how-to-lose-50-of-your-business/ http://www.webia.info/articles/site-redesign-how-to-lose-50-of-your-business/#comments Mon, 14 Sep 2009 12:52:47 +0000 Bogdan Pop http://www.webia.info/?p=512

A couple of months ago I wrote an article about service marketplaces, and one such marketplace I gave as example was guru.com. This article is again about the same site, which was recently poorly redesigned.

How to kick out 50% of your potential clients

There are two categories of companies, or for that matter could be people too, that need a website. First are the ones that do not currently have a website, and then are the ones that have a website but want their website improved. Improving is the sole purpose of a website redesign. However, Guru missed that completely in their redesign process. They did many changes, some are actually good, but you need to sign up and log in into your account to see the improvements.

The big issue is that their new homepage misses half of their potential clients. A service marketplace is a portal where companies that have projects sign up and post them, while others (service provides) check out the posted projects, bid on them, and then develop them. A service marketplace requires employers with projects and employees (freelancers or companies) with skills and resources to develop solutions.

Guru's homepage contains a lot of information for employers. It has a big chunky menu with links to "hiring, posting a project, finding freelancers". It provides means to manage your projects, pay freelancers, check your messages. But did I say you are logged in? NO. You're not logged in. They didn't adapt their site for first time visitors. Then, after a big header with guru's greatest features (a slideshow about safe payments, their million freelancers etc) you get three big tabs. Guess what? They are practically the same menu, only now in big chunky tabs. Find freelancers, post projects, discover Guru.

I must say that posting a project is really nice. Without having an account, you can add all your project details, then sign up et voilà, your project is posted. That's ok, but I have just finished reviewing the homepage. So, did you catch the glitch? I have been talking here only about Employers! No Employees!

No freelancer information on homepage



Guru misses half of their clients because they didn't put any information for freelancers on their homepage. First time freelancers probably get lost in the site and don't ever get the chance to register, bid, work and make money. Awful strategy from Guru.

But they do care about 50% of their business

There is information for freelancers on their newly designed homepage. I am going to give you 10 seconds to discover it in the above picture. Should you not find any information for freelancers, check out the next image.



All you have to do now is to always remember this issue and never do it in your own sites and wonder why things don't work smoothly. If you have any other examples or pointers please leave them in the comments section bellow. If you liked this article you can subscribe to the full content rss feed and stay updated as we post new information.

]]> http://www.webia.info/articles/site-redesign-how-to-lose-50-of-your-business/feed/ 0 http://www.webia.info/articles/creating-motion-blur-without-special-software/ http://www.webia.info/articles/creating-motion-blur-without-special-software/#comments Thu, 10 Sep 2009 15:21:23 +0000 Bogdan Pop http://www.webia.info/?p=544 Should you be on holiday, and run out of Photoshop, Fireworks, Illustrator or your favorite image editing software, you need not panic if you need to apply a motion blur effect to an image. You could use your camera if it is convenient (IE: you need to apply motion blur to something located next to you). For the purposes of this tutorial I have chosen a random landscape image. The original size of the image was 2500 by 1667 pixels, but I need it at 540 pixels by 360 pixels.

Original file



Final outcome



To apply motion blur to a graphic element without any dedicated software, here's a few simple steps that will have decent results.

1: Duplicate your graphic element



We will duplicate our graphic element because I want to apply the blur effect to only a portion of the landscape. To be exact, I want a horizontal line that blurs the center of the image.

2: Resize copy A of the element to desired size



Copy A will have to be located underneath copy B because it will be the part that will not be blurred.

3: Resize the height of copy B to same height of A



4: Resize the width of copy B to something smaller than A's width



By resizing the image to a smaller width, information will be lost. Why? The original file was 2500 pixels in width. I am resizing the image to something as low as 150 pixels. More than 10 pixels will be combined to form a new one, and preserve part of the original aspect of the image.

5: Resize the width of copy B to the width of A



During this resizing process, the exact opposite of step four will happen. Out of one sole pixel, many more have to be created, resulting in quality loss of the image, and the blurry effect.

6: Trim excess material, while blurred image on top



In the final step, we trim off the header and footer of the blurred copy of the image, leaving the desired horizontal bar, on top of the original image. If you liked this article you can subscribe to the full content rss feed and stay updated as we post new information.

]]> http://www.webia.info/articles/creating-motion-blur-without-special-software/feed/ 3 http://www.webia.info/articles/consistency-key-element-in-extraordinary-ux/ http://www.webia.info/articles/consistency-key-element-in-extraordinary-ux/#comments Tue, 08 Sep 2009 07:25:05 +0000 Bogdan Pop http://www.webia.info/?p=513 Throughout their life people develop different patterns. These patterns are visible in how people interact with each other, actions they usually take for similar scenarios. Some develop tics. A tic is a spasmodic contraction of muscles that usually occurs in the face. People love patterns because patterns make them feel comfortable. Some sales people could develop a pattern in opening a discussion with someone else, a stranger, and could feel awkward if a chat with a new prospect doesn't go according to the usual plan.

Some love drinking coffee while reading the newspaper in the morning, and each morning they do the same thing. Programmers love having coke or energy drinks while they code while cops love their donuts. The list of habits and patterns is very long, and is not the goal of this article.

But if we love patterns, why almost every software out there is different than the one next to it? Why related sections on a site are different when they should have similar structure? Not having a consistent layout across a site, across a network of sites will damage user experience, because it will be harder for your visitors to go around the site developing habits.

Consistency matters. Here's why



Take for example Apple's operating system OS X. Leopard is consistent across different areas and software installed on the platform uses the same visual elements, positioning of elements. Users therefor learn their habits faster and the user experience improves drastically because people know their way around the operating system.



Further more, Snow Leopard, the new OS from Apple, didn't produce huge changes in user interface since original Leopard. The new version only improved the first one, while adding some new features. Slight changes do appear in the user interface, but they were placed in the right place, exactly where users expected them to be. Another good example is the iPhone's user interface, which contains a set of basic elements that are given to developers, and they use only those elements to build the structure of their apps. The direct result is whatever app you are using, be it a weather app or sending a text message, interacting with the phone is done in the same way.



As I do not want to put Apple on a pedestal, Microsoft is consistent throughout their Office suite. Similar functions are placed in the same spots whether you're using Word, PowerPoint or Excel for example. Another good example is out of the IT world, into cars. All cars have the brakes, clutch and throttle in the same place, and all cars are to be driven on the right side of the road, with minor exceptions.

Google, doesn't do a really great job when it comes down to consistency. They do have consistency across different services they offer, but what I will talk about is Google's search engine and their translation service. While searching on Google you may misspell a few words. Should that happen, Google searches for your phrase but also makes suggestions for search phrases with proper grammar. What I don't understand is why such suggestions and corrections of my bad grammar don't happen while trying to translate something. You could hear a word on radio or on TV and you have no clue what it means. Moreover, you don't know exactly how to spell it, but you give your best. Then you hit translate, and the word appears in another language exactly the same. This is totally wrong especially because there's nothing that says that the word was not found. It is your own guess that the word you typed is badly written or doesn't really exist. Google does provide a tiny search link. But it is tiny and takes you away from the translation page. Poor user experience from Google.

Consistency across the web: Envato

We will first look upon Envato's websites network. They all share the same structure, all links are in the same place across all sites. Articles have same structure. The only difference between them is given by different color schemes.









Consistency across the web: Nike

The next stop will be another network having consistency across many sites: Nike. Same structure, different colors, awesome branding.









If you have any other examples or pointers please leave them in the comments section bellow. If you liked this article you can subscribe to the full content rss feed and stay updated as we post new information.

]]> http://www.webia.info/articles/consistency-key-element-in-extraordinary-ux/feed/ 4 http://www.webia.info/articles/usability/graceful-flash-degradation/ http://www.webia.info/articles/usability/graceful-flash-degradation/#comments Tue, 01 Sep 2009 14:18:00 +0000 Bogdan Pop http://www.webia.info/?p=487

It has been quite some time since I last wrote an article here, and I hope you all enjoyed the summer and summer holiday. I read a lot of blogs each day and I must say that there's a decent amount of articles about javascript, content, and how to properly code a site when using javascript. You have to be careful because of those people who disable javascript or use old browsers that don't have such features. However, I haven't seen any articles describing some short guidelines as to what you should do when developing a site in flash.

Issues with flash developing

The first issue that has to be taken into consideration here is that while many people have flash player installed, its version may be an older one, and the site or web app you are building with flash 10 may not work correctly, or at all on some people's computers. Moreover, there are individuals that don't have flash player installed, just like the ones without javascript.

How to handle flash generated problems

The easiest option would be to develop a html version of the site. Though this is ok, the costs of such a solution grow as the site grows. This is ok for small sites or sites that are not updated frequently. What happens when you have a big site, with content updated on a daily basis?



One interesting solution, which I definitely like is the one adopted by UEFA (Union of European Football Associations). Their website is not entirely flash, but has many flash sections. One of them is a content slider, which could have been built using javascript. They used flash and that is ok too, but how they fix search engine issue that come by using flash. How can people using mobile devices like the iPhone - which doesn't have flash - browse their website and read valuable content?

The solution is quite simple. UEFA's website displays all content headlines as plain text. Those headlines were previously bundled with images in the flash content slider. Moreover, the headlines appear in the same area of the site, leaving the layout uncrippled. Another important feature is that they also display a small button telling their visitors that if they want to fully enjoy the site they should install flash player. They also link to Adobe's download page.



UEFA does a great job making a well developed website, but they have their own pitfalls. During the UEFA Champions League and UEFA Europa League draws, which took place last week, their live coverage of the event had only flash versions, rendering blank pages for users without flash player. Mobile users had to make phone calls in order to find out the group of their favorite team.

A website that does a bad job about non flash user experience is vinuldenunta.ro . Such users do see something other than a blank page. They are presented with a small paragraph which unfortunately isn't formatted in any way, leaving the impression the site is under construction. No information is provided regarding the cool flash version of the site that is hidden to them.



Pointers for better flash developing

• 1. If possible, provide a non flash version of the site
• 2. If important content is displayed within flash, make sure it is available for users that do not have flash player
• 3. Don't use flash for navigation, and if you do, provide a secondary navigation menu using html
• 4. If you only have flash version, make sure you let non flash users know about that

The above are just some basic pointers, but sticking to them will insure a high quality website. If you have any other examples or pointers please leave them in the comments section bellow. If you liked this article you can subscribe to the full content rss feed and stay updated as we post new information.

]]> http://www.webia.info/articles/usability/graceful-flash-degradation/feed/ 3