It’s simple.  People are still using it. Even though the market share is declining, at last look IE6 still makes up about 20% of the market.  Buy why?  To compare a modern browser to IE6 would be like comparing a Corvette to a horse and buggy.  It lacks the bells and whistles of the newer browsers, it’s less secure, it doesn’t support png transparancy and it doesn’t support today’s web standards – which causes developers everywhere hours of frustration.

Ultimately, having to support IE6 is hindering the advancement of websites both in design and functionality.  With the release of HTML5 on the horizon, the web is about to take on a whole new direction and will leave those that don’t support it in the dust.  IE6 users will start to notice sites that look broken or simply do not work.  They will get messages asking them to upgrade (if they haven’t already.)  Even bigger sites like Facebook, YouTube and Digg are starting to limit their support of the browser.

So, my question to you is do you use IE6?  If so, why?  Is it a choice? Are you restricted by your IT department?  Did you just not know there was a difference between browsers, or that there are better ones out there?  Have you noticed sites are prompting you to upgrade, look broken or just don’t work?  Please, leave your answers in the comments.  I’d love to hear from you!

If you are looking for an upgrade try one of these:

• Firefox 3.5
• Google Chrome
• Internet Explorer 8

In the support & maintenance division, edits are often purely functional and extremely urgent.  One thing I try to do with my clients is suggest small improvements above and beyond the standard maintenance requests, and emphasize how easy it is to keep the request affordable.  Almost everyone wants to “do it right,” but clients often have a boss ready to veto 30 hours to redesign and rebuild the entire products section.  However, customers may not realize that significant improvements can be made despite limited time and budget:

• 1-2 hours for an information architect look at a problematic page that frequently elicit customer complaints
• ½ hour for a copywriter to punch up the language on a flat homepage promotion
• 2-3 hours for a designer to restyle a confusing chart so that users can get critical product information “at a glance”
• 3-4 hours for a developer to automate a task that normally takes the client 1-2 hours to accomplish using a content management system (CMS) several times weekly
• 15 minutes to create a Google Analytics account and add the code to a landing page to make sure a search engine optimization (SEO) campaign is effective

Affordable suggestions like these introduce clients to expertise that normally only get tapped during large-scale projects. They also remind them that we really do have their best interest in mind and that we are as frustrated by the “bubble gum and duct tape” add-ons to their website as they are. It’s important for everyone to remember that while a full-scale website redesign might not be possible during tough times, these “small victories” in key places (i.e., where customers often identify difficulty) can happen on a regular basis, and often have a big impact. The focus and frequency of these changes can draw attention to improvements that might have otherwise gotten lost during an overwhelming, large-scale redesign, and show users that your company strives to be responsive.  Innovation, intelligence, and creativity in small doses can still be enough to inspire customer involvement and loyalty.

The client, however, found this a bit confusing—once they had expanded the hidden list, it wasn’t obvious to them how to close it. They wanted to be able to click somewhere else on the page and have the list close so they could continue browsing. No problem, I figured, a few JavaScript tweaks and we’d be all set. Simply putting a click event on the body element to close the list would be pretty straightforward.

Lets take a look at the code we used:

function initFauxSelect() {
  $('a.showSelect').click( function(e) {
      e.preventDefault();
      var $theList = $(this).parent('.fauxSelect').next('.selectList');
      hideShow($theList);
  });
}
 
function hideShow(obj) {
  $theList = obj;
  if ($theList.is(':visible') ) {
    $theList.hide();
  } else {
    $theList.show();
  }
}

It’s a simple click event on a.showSelect that calls the hideShow() function. If the list is visible, hide it, otherwise show it.

I figured it would be as simple as binding a new click event to the body tag whenever we show the list. The new event would hide the list when someone clicked elsewhere on the page. Let’s look at the updated hideShow() code:

function hideShow(obj) {
  $theList = obj;
  if ($theList.is(':visible') ) {
    $theList.hide();
    $('body').unbind('click.fauxselect');
  } else {
    $theList.show();
    $('body').bind('click.fauxselect', function(e) {
      $theList.hide();
      $('body').unbind('click.fauxselect');
    });
  }
}

Now, whenever we’re showing the list, we’re creating a new click event on the body that hides the list. It also unbinds itself once its job is done. If someone closes the list by clicking a.showSelect again, we also unbind the event just to keep things clean.

However, I ran into a problem. The event I was binding to the body was being called right away, which stopped the list from ever appearing! It seemed a bit strange, as my assumption was that you’d never want your new event to fire as the same time as the current event.

Thankfully, there’s an easy way prevent this from happening. In our original click event on the .showSelect element, we need to stop that event from bubbling up the DOM.

function initShortcutsSelect() {
  $('a.showSelect').click( function(e) {
    e.preventDefault();
    e.stopPropagation();  // ----- ADDED THIS LINE
    var $theList = $(this).parent('.fauxSelect').next('.selectList');
    hideShow($theList);
  });
}

By telling the event to stopPropagation, it never bubbles up the DOM, never reaches the body and never calls the new click event you bound there until the user actually clicks the body.

Unfortunately, the height of the page being pulled in would vary wildly. This led to a fairly disappointing experience where the page was either far too long, or content in the iframe was cut off and the user had to scroll within the iframe to see everything.

We came up with what we thought might be an interesting solution. If the page loading inside of the iframe (the child page) could calculate its height, and somehow let the parent page know, the parent page should be able to reset the height of the iframe.

With a little inspiration, we came up with a pretty neat solution that we’d like to share. Our solution requires that you have the ability to edit the code of both the parent and child pages.

The child page being loaded into the iframe will simply reset the location of the parent page, and include a hash with the height of itself.

1
2
3
4
5
6
7

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.js"></script>
<script>
var parentUrl = "http://example/iframe-outside.html";
setHash = function() {
    parent.location = parentUrl + "#" + $('body').height();
}();
</script>

We’re using jQuery here to easily get the height of the <body> tag.

On the parent page that includes the iframe, we’ll again use jQuery and write a small function that gets the height from the hash in the URL, and uses that to reset the height of the iframe.

8
9
10
11

function setHeight() {
    var newHeight = parseInt(location.hash.substring(1)) + 50;
    $('#hashFrame').attr('height', newHeight);
}

We ran into a bit of an issue: the page we were loading was taking a few seconds to load, and we didn’t want to set our height on the iframe until the content within the iframe had finished loading (and it had a chance to set the proper height to the url hash).

More jQuery to the rescue! The jQuery .load() method allowed us to call our setHeight() function after the iframe had finished loading.

12
13
14

$('#hashFrame').load( function() {
    setHeight();
});

Putting it all together gave us a great way to use our new application inside our legacy application, and make it faily seamless to the end user.