CSSKarma

display your <style>

designing the web since 2002

Posts Tagged ‘ui’

« Older Entries |

Sliding Labels v2 – Patch

Tuesday, February 2nd, 2010

banner

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

Tags: , , ,
Posted in Web Design | 42 Comments »

Form Design with Sliding Labels

Tuesday, January 19th, 2010

Sliding Label banner

Please use version 1.1 of sliding labels with updated options and bug fixes at: http://www.csskarma.com/blog/sliding-labels-v2/

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 (version 1.1)

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

slidinglabels no css

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.

labelslider no js

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!

labelslider final

View demo (version 1.1)

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!

Tags: , , ,
Posted in Web Design | 130 Comments »

Conditional Animation Speed in jQuery

Friday, January 8th, 2010

Turtle

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)

animation collapsed

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?”

animation expanded

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

    Tags: , , ,
    Posted in Web Design | 2 Comments »

Selectable RSS with SimplePie and jQuery

Monday, August 17th, 2009

banner

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.

form with 4 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

Tags: , , , ,
Posted in Web Development | 6 Comments »

Usable Accessibility

Tuesday, April 14th, 2009

article banner

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:

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.

Tags: , , ,
Posted in Web Standards | 2 Comments »

Form Security with Autocomplete

Friday, April 10th, 2009

article banner

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.

Tags: ,
Posted in Security | 8 Comments »

Analyzing Home

Wednesday, April 8th, 2009

article banner

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?

home link images

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:

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.

Tags:
Posted in Web Development | 6 Comments »

Web Standards and the Shower Curtain

Wednesday, April 1st, 2009

article banner

Have you ever bought shower curtain rings and wondered if there were enough in the package to fit your shower curtain? Probably not.

Why is that?

Its because the shower curtain industry has standards, just like the standards we’re trying to implement on the Web. At some point in the process of creating shower curtains, an industry leader made a decision as to how many holes would be in that shower curtain. It filtered through the industry and became a standard so you, the consumer, didn’t have to worry if there were enough rings to hold up your curtain. There are. And it’s because of standards.

Barriers to Entry

Think of the millions of different industries out there that would be in a constant state of confusion if there were no standards set. Every time a new player would come into the business, they would be reinventing the wheel for their product (sound familiar?).

Unfortunately, the cost of entry to the Web is very low. It’s available to everyone, whether you’re aware of Web Standards or not, you can get in and do whatever you want, go to blogger, WordPress, Google sites, etc. There’s no real governing body saying No, you can’t put up a Web site with invalid code. Honestly, nothing happens if you use crappy code, you can still get a nice looking site that’s all decked out in tables and font elements.

The barriers to entry are so low for the Web that no one needs to be aware of the standards. This is a culture that needs to change.

Accountability

Up until, maybe a month or two ago, I was a huge pusher of education for the client, cram as much knowledge as you can into their heads. But I’m starting to lean the other way. Where does the education need to stop and where does the industry take over in enforcing standards?

User-centric design is such a big deal right now, but we’re not bringing it into our business model. We design our sites with the user in mind. What does the user want? What will they being thinking? Where do we want to guide the eye?

We all know that the user average doesn’t care about paragraph tags, blockquotes and divs. But guess what? 95% of the time, the client doesn’t care either. And you can say that caring about that is the cost of having a web site, but it’s really not. Not with barriers to entry being so low. A small company doesn’t need to know this to be successful.

I just had a very educational back-and-forth with some system administrators (server guys) where I truly felt like a client with the attitude of: I don’t care about the innards of the server, I just want it to work. And it was finally pretty clear to me about how a client, who is not Internet savvy, and just wants a Web site to work. They truly don’t care, they just want it to work.

The Ideal Client

The ideal client, wants to learn about the XHTML code we’re using to build the site. They’re curious as to why it’s best practice to separate out a presentation layer. This is great when they actually want to be educated, I love these clients; unfortunately, they’re few and far between.

Don’t get me wrong, I’m not saying the education is a bad thing, I think it’s great and I’d love it if clients cared about semantics and proper document structure. But the reality of the situation is that we need to pick our battles and move some of the burden off the client and back onto us (the developer).

The CMS

Content management system and the developers need to take on most of the burden. This is where the code is produced, this is the output, and this is where the choke point is. Most content management systems I’ve come across are still outputting multiple line breaks instead of paragraph elements (they’re elements, not tags). With how far we’ve come in Web Standards, its not acceptable anymore to just be proud that you’re not using tables for layout. The best one I’ve seen, so far, has been WordPress (my CMS of choice). But the vast majority of “easy” CMSs are still outputting awful code.

A client should not be asked to do any more coding than they have to do in a Word document, unless they want to or there’s an error in the CMS.

The Problem with Themes

The problem I have with WordPress/MovableType themes and default templates is all the extra code included to make things flexible. Code inserted completely for presentation purposes.

The first 5 lines of code in the body of a default MovableType Blog:

<div id="container">
<div id="container-inner">
<div id="header">
<div id="header-inner">
<div id="header-content">

What I cut it down to before I start coding

<div id="branding">

If we’re going to make the barriers to entry so low that anyone can use these open source CMSs, we need to build them better out of the box. The same amount of theming can be done with half the amount of code.

What clients should know

There are certain things that a client needs to be responsible for when managing a Web site. Anything having to do with the content, properly floating images left and right, bold & italics (if there’s no WYSIWYG editor), maybe some light positioning, things like that. They need to be educated on accessibility and how necessary alt text is when they’re inputting an image into content. They need to be educated on relevant topics that they’ll deal with on a day-to-day basis, not the importance of a DOCTYPE and making fewer HTTP requests (these are burdens of the developer).

The point of this

What am I ranting about? Shower curtains? The point I’m trying to make here is that there are certain standards that we, the Web team should share with the client, but they don’t need to be experts. If they were, they wouldn’t need us. Inform your clients about Web standards, let them know they exists, answer any and all questions they have, and correct any misconceptions, educate them as much as they need. The Opera Web Standards Curriculum is a great resource for any client to have, maybe giving them that should be our newest standard.

You’re the client, you don’t need to think about how many rings there are in your shower curtain, it just works (ok, maybe you’re the user, but you get the point).

P.S. There’s a big learning curve with the Internet and it’s even harder since it constantly changes; you’re clients are not stupid, they’re just confused.

Now if we can only agree on spelling it “Web site” vs. “website” we’ll be in business!

Tags: , , , , ,
Posted in Web Standards | 5 Comments »

This Week in Links 12/16

Tuesday, December 16th, 2008

article image

10 Tips to Improve Your UI

Smashing Magazine, once again, has a great article about user interface. This article gives you some quick and helpful tips on improving your user interface design. A lot of stuff we should all be doing.

Anti-RSI

This is a Mac program to help prevent RSI (which is basically carpal tunnel). I saw some pictures of people with RSI, it’s gross and looks very painful. I use Anti-RSI now, and I think you should as well. I’m not posting the pictures, but if you Google it, I’m sure they’ll turn up.

Helpful hyperlinks with JS

An article from the boys over at SitePoint. This bit of JavaScript will pop an icon on the end of your links, letting the user know what they’re about to click. This can also be done with CSS 2.1, but by using JavaScript we’re making it available for… well let’s just say it… IE6 users.

Tags: , ,
Posted in News | No Comments »

This Week in Links 11/5

Wednesday, November 5th, 2008

article banner

Good Practice in Pagination

Smashing put out a good article on a topic that I think gets overlooked a lot when dealing with user interface. A lot of times it’s taken for granted, but pagination is an important page of the UI.

Freshbooks

Freshbooks is a service for the freelancer out there. It’s a fast way to track time and invoice your clients. I currently use Harvest, but I really like how Freshbooks deals with invoicing

35 Fireworks Tutorials

I use fireworks and there are NO good tutorials out there form e. So I was THRILLED to find this link. Photoshop is great and all, but it’s a program meant for web & print design. Being a person who doesn’t do any print design, a lot of the features in Photoshop are just cruft to me, so I happily use Fireworks.

Freelancer Magazine

Freelancer Magazine in the newest edition to my feed reader. THey have all sorts of great advise for the freelancer and a lot of stuff that’s just good to know. Highly recommended.

I assure you, I’m not sponsored by any of these sites or services.

Tags: , , , ,
Posted in News, Web Development | 2 Comments »

« Older Entries |

New from the blog

Are My Sites Up? authenticjobs.com