One of my favorite features of the HTML 5 forms is the “required” attribute. But unfortunately, support isn’t totally there yet. So we need to create fallbacks.

It works in the modern browsers you’d expect it to (FF4, Safari, Opera, etc) but in older browsers, form validation isn’t something you can really ignore (like border-radius) or you’ll get flooded with all sorts of nastiness and spam. Sure we should be doing it at the server level anyway, but you still want that client side layer to add a bit of UX charm to your form.

We can still use the new required attribute effectively by creating a JavaScript fallback for unsupported browsers.

In this demo, I’m using:

• jQuery
• jQuery Validation
• Modernizr

The HTML

The HTML is very basic, just an HTML5 form, with 2 inputs: text (name), and email (email). I’m using 2 form types to show how we add classes to support the jQuery Validation. You can, of course, use whatever validation method you’d like.

<form action="" method="post">
<label for="name">Name</label>
<input type="text" name="name" id="name" required>

<label for="email">Email</label>
<input type="email" name="email" id="email" required>

<button type="submit">Submit</button>
</form>

The JavaScript

With the JavaScript, we first make the check for “required” support. I’m using Modernizr for this.

I left an open block in the if statement in case you want to do something else in there, but you could remove the else and replace the first line with it’s inverse if (!Modernizr.input.required) { if you don’t plan on using it for anything.

If “required” isn’t supported I’m running through all the form inputs on the page with a “required” attribute, adding a class of “required”, and the type of input (email, text, etc.). Setting the input type helps you use the validation plugin a little better and can also aid in styling for IE6.

NOTE: I’m using JavaScript’s native getAttribute() method to grab the input type because jQuery’s attr('type') returns “text” on the “email” input for some reason.

After all the appropriate classes are added, we can call the plugin. I’m doing it on each form, but targeting one specific form by it’s ID value is more traditional.

(function ($) {

	// check for "required" input support with modernizr
	if (Modernizr.input.required) {

		// do something else

	} else {

		// parse through each required input
		$('form').find('input[required]').each(function () {

			// add a class to each required field with "required" & the input type
			// using the normal "getAttribute" method because jQuery's attr always returns "text"
			$(this).attr('class', 'required ' + this.getAttribute('type')).removeAttr('required');

		});

		// call jQuery validate plugin on each form
		$('form').each(function () {
			$(this).validate();
		});

	} // if required supported

}(jQuery));

Older (unsupported) browsers will use the Validation plugin, and modern browsers will use the built-in HTML 5 validation.

• View Demo
• Plugin
• Minified Plugin

Version: 3.2 – Added a “className” option so you don’t have to use “.slider” as the wrapper

Version 3.1: Changed “children” to “find” so it will work with a UL. Thanks to Oro for the feedback

Version 3 of Sliding Labels brought some big changes, the largest being that I finally converted it into a working jQuery plugin.

Maybe it was the 200 e-mails requesting an official plugin, maybe it was my curiosity. Whatever it was, I heard everyone and I wanted to let you know that I’m listening to all the feature requests and bug reports; and I really do appreciate them.

Additions to version 3

Plugin status: Obviously creating an official plugin was the biggest change

Position: relative: It seemed like a lot of the questions I was getting had to do with adding position:relative to the .slider element in the CSS, so I just moved that into the script.

Animation speed: I added an option to easily control the animation speed. It can take strings like “fast” and “slow” or any numeric value.

Axis option: I got a lot of requests to add in some functionality to have the label slide up rather than only to the left. I added this in with an “axis” variable which can take either “x” or “y” for sliding direction

Subtractions to version 3

Label Color: Originally I had this in the script so it looked nicer inline to the field, but I got to thinking that this really should be defined in the CSS, and it’s just color; so I took it out.

Using the plugin

Just like the previous version, you need an element wrapping the <label> and <input> elements. I use a <div> in the demo, but you can use whatever you’d like. The only requirement is that it have the class name “slider”. I can change that if anyone finds it to be annoying, but let me know and I’ll update the script

HTML

<div class="form-slider">
<label for="user">User name</label>
<input type="text" id="user" name="user">
</div>

JavaScript

$(function(){ $('#contactform').slidinglabels({
/* these are all optional */
className : 'form-slider', // the class you're wrapping the label & input with -> default = slider
topPosition : '5px', // how far down you want each label to start
leftPosition : '5px', // how far left you want each label to start
axis : 'x', // can take 'x' or 'y' for slide direction
speed : 'fast' // can take 'fast', 'slow', or a numeric value
});
});

That’s all there is to it. Let me know what you think, any extra features you’d like and any bugs. I should be submitting this to jQuery.com in the next few days.

Obviously, I highly recommend all those these books, as they’ve had a pretty large impact on me as a designer & a developer. The best part about them is that they’re all pretty easy reads, they’re not the kind of books you have to spend a week or 2 reading.

Does anyone else have books like this? Or do we all just read blogs now?

Last week I wrote an article about sliding form labels that got quite a bit of attention. Many of the commenters brought up a couple good points/bug in the Sliding Label code that I wanted to address and provide a patch for:

• The sliding label was barfing out in Safari when auto-fill was active
• The default scripting didn’t work on textareas

I sat down yesterday and wrote a patch/new version of sliding labels which I think addresses these two problems.

View the Demo

The new jQuery

$(function(){
$('form#info .slider label').each(function(){
	var labelColor = '#999';
	var restingPosition = '5px';

	// style the label with JS for progressive enhancement
	$(this).css({
		'color' : labelColor,
		 	'position' : 'absolute',
	 		'top' : '6px',
			'left' : restingPosition,
			'display' : 'inline',
    		        'z-index' : '99'
	});

	var inputval = $(this).next().val();

	// grab the label width, then add 5 pixels to it
	var labelwidth = $(this).width();
	var labelmove = labelwidth + 5 +'px';

	// onload, check if a field is filled out, if so, move the label out of the way
	if(inputval !== ''){
		$(this).stop().animate({ 'left':'-'+labelmove }, 1);
	}    	

	// if the input is empty on focus move the label to the left
	// if it's empty on blur, move it back
	$('input, textarea').focus(function(){
		var label = $(this).prev('label');
		var width = $(label).width();
		var adjust = width + 5 + 'px';
		var value = $(this).val();

		if(value == ''){
			label.stop().animate({ 'left':'-'+adjust }, 'fast');
		} else {
			label.css({ 'left':'-'+adjust });
		}
	}).blur(function(){
		var label = $(this).prev('label');
		var value = $(this).val();

		if(value == ''){
			label.stop().animate({ 'left':restingPosition }, 'fast');
		}	

	});
}); // End "each" statement
}); // End loaded jQuery

Textarea HTML

The HTML for the textarea follows the same convention as the rest of the inputs, in only needing a wrapping element.

<div id="comment-wrap"  class="slider">
    <label for="comment">Comment</label>
    <textarea cols="53" rows="10" id="comment"></textarea>
</div><!--/#comment-wrap-->

There are no major changes to the plugin, just a few tweaks. If you find anymore bug, please let me know.

View the Demo

A few weeks ago I was reading an article on form UI by Luke Wroblewski of Yahoo!. For those who aren’t familiar with Luke, he (quite literally) wrote the book on good form design.

In the article, one certain section about placing labels inside of form fields stood out to me:

Because labels within fields need to go away when people are entering their answer into an input field, the context for the answer is gone. So if you suddenly forget what question you’re answering, tough luck—the label is nowhere to be found. As such, labels within inputs aren’t a good solution for long or even medium-length forms. When you’re done filling in the form, all the labels are gone! That makes it a bit hard to go back and check your answers.Luke Wroblewski

He brings up a good point. Generally speaking, you can look at a field that says “Tim Wright” and know that it was a field for your (my) name. But for long forms, yea, I do agree that you can forget some of the questions you answered.

For best practice, Luke talks about leaving your labels outside the form field so it’s always available to the user. I do think it’s a pretty good solution, but I think we can get a little more creative than that.

Enter: Sliding Labels

After reading that article it occurred to me that there’s no reason we can’t have the best of both worlds. I like how inline labels look, and I see Luke’s point about them disappearing as you fill out the form. But, we have jQuery, we know about progressive enhancement, and we have creative minds, so let’s build something that allows us to keep the label inline, but slide it off to the left (or up, whichever you prefer) rather than going away on click.

View demo

The HTML

<form action="" method="post" id="info"> <h2>Contact Information</h2> <div id="name-wrap" class="slider"> <label for="name">Name</label> <input type="text" id="name" name="name"> </div><!--/#name-wrap--> <div id="email-wrap" class="slider"> <label for="email">E&ndash;mail</label> <input type="text" id="email" name="email"> </div><!--/#email-wrap--> <div id="street-wrap" class="slider"> <label for="st">Street</label> <input type="text" id="st" name="st"> </div><!--/#street-wrap--> <div id="city-wrap" class="slider"> <label for="city">City &amp; State</label> <input type="text" id="city" name="city"> </div><!--/#city-wrap--> <div id="zip-wrap" class="slider"> <label for="zip">Zip code</label> <input type="text" id="zip" name="zip"> </div><!--/#zip-wrap--> <input type="submit" id="btn" name="btn" value="submit"> </form>

The only necessary items to make sliding labels (as I built it) work are the wrapper element (DIV in my case) and applying a class of “slider” to it (you can change this easily in the JavaScript).

At this point we have a pretty basic, and ugly form

The CSS

body { font:12px/1.3 Arial, Sans-serif; } form { width:380px;padding:0 90px 20px;margin:auto;background:#f7f7f7;border:1px solid #ddd; } div { clear:both;position:relative;margin:0 0 10px; } label { cursor:pointer;display:block; } input[type="text"] { width:300px;border:1px solid #999;padding:5px;-moz-border-radius:4px; } input[type="text"]:focus { border-color:#777; } input[name="zip"] { width:150px; } /* submit button */ input[type="submit"] { cursor:pointer;border:1px solid #999;padding:5px;-moz-border-radius:4px;background:#eee; } input[type="submit"]:hover, input[type="submit"]:focus { border-color:#333;background:#ddd; } input[type="submit"]:active{ margin-top:1px; } 

The only 100% necessary CSS in there is the position:relative on the wrapper element (DIV). The rest is basically cosmetic and you can mess with it as you see fit.

At this point you should have a pretty normal looking form with labels on top of their respective inputs.

The jQuery

Now for the section everyone skipped to, provided you didn’t go straight to the demo (which I usually do).

$(function(){ $('form#info .slider label').each(function(){ var labelColor = '#999'; var restingPosition = '5px'; // style the label with JS for progressive enhancement $(this).css({ 'color' : labelColor, 'position' : 'absolute', 'top' : '6px', 'left' : restingPosition, 'display' : 'inline', 'z-index' : '99' }); // grab the input value var inputval = $(this).next('input').val(); // grab the label width, then add 5 pixels to it var labelwidth = $(this).width(); var labelmove = labelwidth + 5; //onload, check if a field is filled out, if so, move the label out of the way if(inputval !== ''){ $(this).stop().animate({ 'left':'-'+labelmove }, 1); } // if the input is empty on focus move the label to the left // if it's empty on blur, move it back $('input').focus(function(){ var label = $(this).prev('label'); var width = $(label).width(); var adjust = width + 5; var value = $(this).val(); if(value == ''){ label.stop().animate({ 'left':'-'+adjust }, 'fast'); } else { label.css({ 'left':'-'+adjust }); } }).blur(function(){ var label = $(this).prev('label'); var value = $(this).val(); if(value == ''){ label.stop().animate({ 'left':restingPosition }, 'fast'); } }); }) });

At this point, you should have a fully working sliding label form!

View demo

Making sure everything is still usable without JavaScript is important (no matter what people say), it’s just a basic principle of progressive enhancement. Believe it or not, there are still people browsing without JavaScript (blackberry users – turned off by default). So creating the interaction in layers, as we did, will help it be past-proof.

Try it out and let me know what you think. So far I’ve used it on a password change form, so definitely let me know if you find a place to use it!

For years (and by “years”, I most likely mean “the years since I started using jQuery… maybe 2″), there’s been one aspect of jQuery that’s bugged the crap out of me, the animation speed.

View demo

We’ve all probably seen the problem that happens in many drop down menus of varying height. We set slideDown(300) (or whatever you set it to) on all the submenus and leave like that. Inevitably, menus grow and shrink based on the content and we get this weird and mildly annoying behavior of really fast moving tall menus vs. shorter menus that move painfully slow just because there’s not much content in there.

This problem stems from where we set the speed of the animation; the value isn’t actually a speed, it’s how long it takes (in milliseconds, I think) for the animation to finish. So you can see why you get varying behaviors based on the element height.

It’s true, that you can use the built-in speed values like “fast” and “slow”, but if you want more fine-grained control over your animation, you’ll have to use a value.

Problem Child ∞

This is what our problem menu looks like all collapsed, just 2 clickable headings (h2) that will slide open to expose content (p)

Normally our jQuery would look something like this:

$(function(){

$('h2').toggle(function(){
    /* get the next element */
    var next_element = $(this).next();

    /* open it  if it's closed */
    next_element.slideDown(500);
},function(){
    /* get the next element again */
    var next_element = $(this).next();

    /* close it if it's open */
    next_element.slideUp(500);
});

});

Note: just example code, I didn’t check to see if it actually works

This is our menu fully expanded. As you can see, the first item has a lot more content then the second. Using the code above will make menu #1 move noticeably faster than menu #2; which, to me, creates an odd user experience. Because you’re like “Why’s is moving so slow?”

So let’s see if we can’t fix that.

Ben Healy (Solution) ∞

What we’re looking to do here is get the height of each collapsed item, do some JS math, and set a speed (animation time) value based on the height.

jQuery functions we’ll need

• next()
• height()
• slideDown() / slideUp()

The Code

$(function(){

	/* Variables to set */
	var id = '#heightCheck';
	var click_element = 'h2';
	var height_value = '100';
	var tall_menu_speed = 400;
	var short_menu_speed = 250;

	/* System variables, probably don't change */
	var target = id +' '+ click_element;
	var menu_content = $(target).next();

	/* Hide the element after the click_element, whether it's a
	div, p, ul, whatever you choose to wrap the items in */
	menu_content.hide();

	$(target).toggle(function(){
		/* save the menu items in a variable */
		var this_menu = $(this).next();

		/* get the menu height and save it */
		var menu_height = this_menu.height();

		/* Calculate the animation speed based on the element height */
		/* if the height is greater than the height set above use the
		tall menu height */
		if(menu_height > height_value){
			var speed = tall_menu_speed;

		/* If it's smaller, use the short menu height */
		} else if(menu_height < height_value) {
			var speed = short_menu_speed;
		}

		/* slide the menu down */
		this_menu.slideDown(speed);

	},function(){
		/* this is the same but reversed to close the menu */
		var this_menu = $(this).next();
		var menu_height = $(this).next().height();

		/* Calculate the animation speed based on the element height */
		if(menu_height > height_value){
			var speed = tall_menu_speed;
		} else if(menu_height < height_value) {
			var speed = short_menu_speed;
		}
		this_menu.slideUp(speed);

	});

});

That should give you a little more control over the menu speed. I'm sure it needs to be tweaked based on the menu you're using, but the general concept is there, and it should work pretty well. I hope it was helpful. Let me know if you have any additions to the code or suggestions to improve it.

View demo

]]> http://www.csskarma.com/blog/conditional-animation-speed/feed/ 2 http://www.csskarma.com/blog/selectable-rss/ http://www.csskarma.com/blog/selectable-rss/#comments Mon, 17 Aug 2009 05:45:45 +0000 Tim http://www.csskarma.com/blog/?p=632

I was building an RSS reader for a project last week and it turned out to be a cool little app. So I thought I’d share some of the code.

View demo

Download demo files

Let’s start off with the HTML we need to get some user interaction with the form. It’s a pretty basic, just some of checkboxes.



HTML

<form action="" method="post" id="selection">
  <h2>Choose your news sources</h2>
 <!--
  Setting all the checkbox names to "source[] helps us build the array on submit"
  We're also adding the RSS feed url to the checkbox value so we can save it in the array values
  -->
  <ul>
  <li><input type="checkbox" id="csskarma" name="source[]" value="http://www.csskarma.com/blog/feed/"/><label for="csskarma">CSSKarma</label></li>
  <li><input type="checkbox" id="cnn" name="source[]" value="http://rss.cnn.com/rss/cnn_topstories.rss"/><label for="cnn">CNN</label></li>
  <li><input type="checkbox" id="espn" name="source[]" value="http://sports-ak.espn.go.com/espn/rss/news"/><label for="espn">ESPN</label></li>
  <li><input type="checkbox" id="vitamin" name="source[]" value="http://feeds.feedburner.com/vitaminmasterfeed"/><label for="vitamin">Think Vitamin</label></li>
  </ul>

  <!-- Setting the submit name to "btn" -->
  <input type="submit" value="submit" name="btn" id="btn-submit"/>
  </form>
  </div><!--/#selectnews-->

The only real thing worth noting in the form code are the names of the checkboxes. We use all the same name to group them together and the [ ] helps create the array on submit. I just chose to use source[] because it made sense to me, but you can use anything as long as the names are consistent and the brackets are there. Just adjust your PHP accordingly.

SimplePie PHP

<?php
/* Get the SimplePie library */
require_once ('inc/simplepie.inc');

/* Create a new instance of SimplePie */
$feed = new SimplePie();

/* Get array */
// If the form has been submitted and the user selected news sources
if (isset ($_POST['btn']) && isset($_POST['source'])) {

    // Save the array of news sources to a variable $checked
    $checked = $_POST['source'];

    // Pass the array of news sources through the SimplePie set_feed_url() function
    $feed->set_feed_url($checked);

    // Also, save this data to a cookie called "feedurls" that will expire when the browser closes
    setcookie('feedurls', serialize($checked));

// If the form wasn't submitted look for the "feedurls" cookie
} else if (isset ($_COOKIE['feedurls'])) {

	// If the cookie was found, pass the data through set_feed_urls()
	$feed->set_feed_url(unserialize($_COOKIE['feedurls']));
}

/* Set item limit */
$feed->set_item_limit(3);

/* Enable caching */
$feed->enable_cache(true);

/* Provide the caching folder */
$feed->set_cache_location('cache');

/* Set the amount of seconds you want to cache the feed */
$feed->set_cache_duration(1800);

/* I don't know what "init" means */
$feed->init();

/* Handle the content type (atom, RSS...) */
$feed->handle_content_type();
?>

This is nothing that can’t be read in the comments, but the guts of the PHP comes in right under the “Get Array” comment. We’re checking to see if the form was submitted and the user selected news sources; if so, dump the values into SimplePie and save them to a cookie we can refer to later. The initial idea was for this to live at a pretty open place (a computer lab or something), that’s why the cookie expires on browser close.

I limited the per-feed output to 3 to keep it a little clean, but you can set that to whatever you want. It’d be pretty easy to let the user choose this as well with a select menu:

<select name="displayNumber">
<option value="1">1</option>
<option value="2">2</option>
<option value="3">3</option>
</select>

And replace $feed->set_item_limit(3); with $feed->set_item_limit($_POST['displayNumber']);. There may be some extra tweaking beyond that, but the general idea is to pass the submitted value into SimplePie.

jQuery

Now that we have the form fully functional we can layer some JavaScript on top of it to make it a little more nifty. This is using the jQuery Form Plugin. It’s the first time I’ve really used this plugin, but it’s actually pretty nice and easy to use. I had some little quirks with it, but nothing too major.

$(function() {

/* If JavaScript is active create a link to slide the form out */
$('#getform a').click(function(){
	$('#selection').slideToggle('slow');
	return false;
});//

/* make it look like something happened */
$('#selection, #reader').hide(); //
$('#reader').fadeIn('slow'); //

 /* bind form using 'ajaxForm' */
$('#selection').ajaxForm(options); 

/* Submit form via Ajax */
var options = {
    target:       '#rssloader',
}; //

});// End jQuery

View demo

Download demo files

Anyway, that’s all I have for today. It’s a pretty unpolished demo so let me know what you think, where I screwed up and if you can build on it and make it better. I’ll try to write some more soon.

Ingredient list

• SimplePie
• Starter files from CSS-Tricks
• jQuery
• jQuery Form Plugin
• Hill’s Brain
• Coffee
]]> http://www.csskarma.com/blog/selectable-rss/feed/ 8 http://www.csskarma.com/blog/usable-accessibility/ http://www.csskarma.com/blog/usable-accessibility/#comments Tue, 14 Apr 2009 15:38:57 +0000 Tim http://www.csskarma.com/blog/?p=488

Many times focusing on standards and guidelines puts the focus on the technical aspects of accessibility, and the human interaction aspect is lost. This problem can be avoided by adopting the broader definition of accessibility as a guiding principle. Instead of focusing only on the technical aspects of accessibility, it is important to recognize that usability is also an important aspect of accessibility. Consciously addressing ‘usable accessibility’ helps clarify the difference between what meets minimum accessibility standards and what is usable by people with disabilities.Shawn Henry

Following my trail of articles I read through this morning to find this quote:

• Accessibility is more than "possible to access"
• Usable Accessibility: Making Web Sites Work Well for People with Disabilities
• Accessibility Primer for Usability Specialists

There were all pretty good reads, if I had to pick 1, I’d say definitely read through the second one, it covers all the bases for you.

I think when building a site or application with accessibility in mind my thoughts are usually something like” "I’ll do the best I can to make this easy for the blind to access, but essentially there’s only so much I can do, it’s gonna be tough". I understand the need to get out of that mind set, maybe investing in a screenreader is the answer?

I’m not entirely sure quite yet how to create a better user experience for a disable user. Especially since I still can’t get the damn mac voice thing to function in a useful way. Hopefully that answer will come sooner rather than later.

]]> http://www.csskarma.com/blog/usable-accessibility/feed/ 2 http://www.csskarma.com/blog/autocomplete-off/ http://www.csskarma.com/blog/autocomplete-off/#comments Fri, 10 Apr 2009 15:57:04 +0000 Tim http://www.csskarma.com/blog/?p=480

I was looking through my blog this morning because I could have sworn I already wrote this post. I know I’ve had this conversation with Phil Nash of Unintentionally Blank. But I guess I never wrote it down? Oh well…

One of my pet peeves when filling out a form is when I click in the payment field and my credit crard / bank account number drops down because it was saved in the browser from last time I made a payment on that site. How is it that developers on these sites overlook that huge security issue?

There’s a very simple fix for it, and it’s called “autocomplete off”:

The XHTML

<input id="pmt" name="payment" type="text" autocomplete="off"/>

The autocomplete="off" makes sure the text field doesn’t expose any saved data. Of course, it would be too easy if this was valid XHTML so it’s not. If you’re concerned with writing 100% valid XHTML, there are valid ways to do this.

Writing valid code

To make this valid, we need to do it with JavaScript. Since I’m pretty sure most people who read this are jQuery freaks (like me), I’ll show the jQuery version of this:

The XHTML

<input id="pmt" name="payment" type="text" />

The jQuery

$(function() {
$("input#pmt").attr("autocomplete","off");
});

The problem with added security with JavaScript

I don’t really recommend using javaScript for this, only because it’s easily disabled. And then you’re back at square one with the payment info dropping down in the text field

Ideally, I’d like to use PHP to do this, but I can’t find it anywhere so I’m using <noscript>:

The jQuery

$(function() {
$("form#paymentform").html("<input id="pmt" name="payment" type="text" autocomplete="off"/>);
});

The XHTML (placed inside the form)

<label for="pmt">Credit Card Number</label>
<noscript><input id="pmt" name="payment" type="text" autocomplete="off"/></noscript>

That way, if javascript is enabled you’ll use the jQuery to write the textfield, and if it’s not, you’ll just write it out normally, which will be invalid, but more secure.

Let me know if anyone knows the PHP way to check for JS.

]]> http://www.csskarma.com/blog/autocomplete-off/feed/ 8 http://www.csskarma.com/blog/analyzing-home/ http://www.csskarma.com/blog/analyzing-home/#comments Wed, 08 Apr 2009 05:03:09 +0000 Tim http://www.csskarma.com/blog/?p=417

The “Home” link has been a staple on almost all of the Web sites I’ve made in the past 5 years, but lately I’ve been wondering how important it is.

I heard Steve Krug at An Event Apart Boston 2007 talk about how the “home” link should always be list first in your navigation, but do we really even need it at all?

All the way back in 2000 Jakob Nielsen challenged the notion that we need main navigation on a site. While I do think navigation is important (for most sites), I’m not so sure about the link labeled “Home”. Most of the major sites we all visit have them, but how often are they used?



Let’s face it, the home page is even starting to die off. With the influx of RSS and sites like digg, stumbleupon, delicious, and countless others, it’s very likely that a user will never even see your home page. They’ll just jump from article to article through their RSS reader or the latest and greatest from Digg (if you can be so lucky).

UI and user-centric design is so important right now, it has us re-thinking everything about Web development and how we design a site. As I build a site now, I actually stop and analyze every piece of a site from time to time. Everything from the search function to the contents of the footer.

I hear a lot of complaints from users of sites that don’t have their logo linked up to the home page, but I’ve never heard a complaint from someone navigating a site without a home link.

There are some popular sites that have already adopted this style of navigation:

• ESPN
• BBC
• A List Apart
• Amazon

Only the logo will get you to the home page… but i’m sure someone out there will scour those sites for an exception

I think, at this point in the Web, it’s perfectly acceptable to drop the “Home” link and use your logo as the only means to get back to your home page. But next time you’re putting together a site, really ask yourself: is a “Home” link is adding anything to the user experience, or is it just taking up space?

I’m pretty sure mine’s just taking up space.

]]> http://www.csskarma.com/blog/analyzing-home/feed/ 6