Archive for the Work Category

jQuery Ratings – A Progressive Enhancement Approach

There are some site behaviors that are primed for progressive enhancement in this example we’ll look at a ratings system and how easy it is to transform a simple form to make it more visually appealing and also improve usability. For a simple rating system we want a radio button list (1-10) and a ‘vote’ button to submit our rating. The html would look something like this:

<form id="rate_this" action="/process/rating/" method="post">
    <div id="rating_scores">
        <label><input type="radio" value="1" name="rating" />1</label>
        <label><input type="radio" value="2" name="rating" />2</label>
        <label><input type="radio" value="3" name="rating" />3</label>
        <label><input type="radio" value="4" name="rating" />4</label>
        <label><input type="radio" value="5" name="rating" />5</label>
        <label><input type="radio" value="6" name="rating" />6</label>
        <label><input type="radio" value="7" name="rating" />7</label>
        <label><input type="radio" value="8" name="rating" />8</label>
        <label><input type="radio" value="9" name="rating" />9</label>
        <label><input type="radio" value="10" name="rating" />10</label>
        <input type="submit" value="Vote" />
    </div>
</form>

Which gives us this:

A simple radio list and a simple button to submit the form.

How can we make this 100x’s better? Simply clicking on a number to submit the form automagically would be the easiest and most friendly user interaction. So we lean on jQuery to provide progressive enhancement. Using these methods we can create a rating behavior infinitely better and more appealing like this:

rating_enhanced.png

jQuery

// hides the vote button
  $("form#ratethis input#votebutton").hide();

// hides all radio buttons $("form#rate_this input[@type=radio]").hide();

// format the labels to look clickable $("form#ratethis label").addClass("contestselector");

// change the formatting of the label when it is hovered over // by assigning a different class $("label.selector, #ratingscores a").hover(function(){ $(this).addClass("selectorh"); }, function() { $(this).removeClass("selector_h");
});

// submit the form when a label is clicked $("form#ratethis label").click(function() { $(this).find("input").attr("checked","checked"); $("input#votebutton").trigger('click'); }); }

CSS

#ratingscores {
margin: 20px 0 10px;
border: 1px solid #cacaca;
background-image: url("/images/ratingscoresbck.gif");
background-position: 0% 45%;
background-repeat: no-repeat;
background-color: #efefef;
padding: 5px 0;
padding-left: 130px;
}
.contestselector {
color: #000;
text-transform: uppercase;
cursor: pointer;
font-size: 167%;
font-weight:bold;
padding: 10px 13px 9px;
margin: 1px;
}
.contestselectorh {
background: #c00;
border: 1px solid #a00;
background: #00c705;
border: 1px solid #008004;
color: #fff !important;
text-decoration: none !important;
margin: 0px;
}

Why hide all the radio buttons? Aside from the fact that they’re ugly we don’t need to worry about them because we’re using <label&rt;s effectively.

The labels are surrounding the buttons with so they will still get focus

<label><input type="radio" value="1" name="rating" />1</label>

We let the user know that the numbered hot spots are indeed buttons by applying a mouseover behavior.

We submit the form when a label is clicked – not when the Vote Now button is pressed.

If Javascript was not available or the jQuery rules were not applied then the html would perfectly degrade and would be entirely usable otherwise.

For an example of this method in action venture over to the Costumzee Costume Contest.

Debugging Internet Explorer CSS – My Methods

How I Debug

I recently spent the day debugging Internet Explorer. I save it for the absolute last step in front end development before pushing a site live. I want to avoid Explorer as much as possible.

I figured my process would be worth sharing. This is my setup.

  1. MacBook running Firefox with the Web Developer Plugin and Firebug plugins installed.
  2. Old Toshiba Laptop 1.8ghz barebones Windows XP installation with IE6
  3. Parallels installed on the MacBook with IE7 on Windows XP SP2

With this setup I can test for any modern browser with any kind of significant market share.

  • Firefox Mac
  • Firefox Win
  • IE 6 + 7 (soon to be 8 as well)
  • Camino
  • Safari

Debugging IE issues is probably the most painful thing about my job, but one that’s made a little bit easier because of my approach so I thought it’d be useful to share.

I develop 9-5 in Firefox so any rendering bugs usually come to my attention right away and I’ll fix them immediately. Camino is based on the same Gecko rendering engine so I don’t have to worry about anomalies there. Safari does a good job rendering everything and my colleagues use it as their day to day browser so we usually catch any rendering bugs that way.

Then it comes down to IE debugging. I only concern myself with IE6 and above, I can handle well for modern browsers, besides the market share of browsers that fall outside this range is really insignificant statistically. For small development teams it’s hardly worth the extra effort to pay attention to the long tail of browsers.

Looking at Google Analytics for a heavy traffic site that I work on:

5.6m Visitors from 8/1/07 – 3/20/08

6+mo-browsers.png<br/> IE is still dominant – so testing for these browsers is essential.

ie-last-6+-mo.png<br/> If we look at the last 6 months, IE7.0 and IE6.0 are neck and neck ~50/50, however:

ie-last-3mo.png<br/> In the first 3+ months of 2008 you can see that IE7 has taken a significant leap above IE6 in the market 61/39 and IE 5.5 has gone to a 0.12% market share to a meager 0.07% market share.

That leaves us only concerned with IE6 and IE7 (and hopefully upcoming IE8 will be a non factor). The best way to deal with CSS and IE is by leveraging something called conditional comments

Before conditional comments I relied on browser hacks to differentiate between browsers, but conditional comments are a lot easier and so much more effective. Currently I use these declarations:

<!--[if IE 6]>
<link rel="stylesheet" href="/stylesheets/ie6.css" type="text/css" />
<![endif]-->
<!--[if IE 7]>
<link rel="stylesheet" href="/stylesheets/ie7.css" type="text/css" />
<![endif]-->

I start with IE6 and clean up any rendering issues – then I move on to IE7, which invariably has fewer issues to deal with. Because IE does not have a handy dandy tool like Firebug to help me diagnose the problem this process usually involves a lot of trial and error. It’s a very iterative process and one that my Agile Development Workflow is well suited for.

One technique I’ve found to be indispensable is assigning various background colors to the markup that I’m trying to debug. Often this is all I need to target CSS rules run amok. Over time you can avoid generating certain CSS + HTML that will break IE altogether – and that’s what separates the experts from novices.

Was this helpful? How do you approach debugging CSS in IE? Share!