The editors of Ajaxian shared their New Year’s party chatter and it wasn’t all about using up the evening’s champagne for mimosas the next morning.  It was about possible final death of IE6 support in 2009.

Web development industry talk seems to be skewed in the direction of “IE6 use won’t end until IE6 support ends - and that should happen now”.  While I think that support of IE6 for GS is slightly premature, serious consideration will be necessary in 2009.
With IE6 usage to dip beneath 10% later this year, the extra cost to try to support it is going to increase site development costs unnecessarily.

There has been some discussion around here for how best to sunset the support for IE6.  One idea kicked around is a popup/popover/dropdown notification that “…This site is best experienced in a modern browser…” and links to multiple vendors.  Let the visitor choose, don’t deny access, just bring up the helpful warning.  And no longer kill ourselves on IE6 hacking.  Any client that has concerns for IE6 support will have to be made aware that there will be extra hours/costs to do so.

Comments?

I’ve passed around my copy of The Adventures of Johnny Bunko to a number of you around here.  The blog for the book has a contest going on that petitions fans to submit another “career lesson that no one ever tells us”.  And there are some awesome entries that I urge all of you to read through.

Personal favorites:

• Avoid drama.
• Listen to your gut.
• Resist the quicksands of negativity.
• When things don’t go your way, get over it!
• Collect collaborators.
• Even the Lone Ranger had help.
  (I think there is the germ of a www.gsdesign.com/staff.html site redesign idea somewhere in here…)
• Use every vacation day.
• Work as if your company name is on the sign.
• Responsibility trumps ability.
• Leave things in better shape than you found them in.
• Don’t be an asshole.
• Don’t let perfect get in the way of better.
  (personal corollary: Never let helpful technology get in the way of actually getting work done.)
• It pays to tell the boring truth.

This is an interesting listen from User Experience Week 2007:
>>>>>>>>>>>>>
In this session, you will:

• Discover the steps of the process required to bring such a huge project to market, including some tips and tricks on how to get stakeholders and participants fully invested
• Find out how the user was involved in shaping the requirements and end product
• Learn why CNN.com plans to never “relaunch” again

Summary
Supporting Documents
Session Slides 2mb PDF
Session Audio 22.7mb MP3
>>>>>>>>>>>>>

Good tidbits:

• They threw away the process document. They needed to speed up he process. They had to scale back to get to a meaningful prototype that they could test.
• Implementation was tricky - development needed requirements to start working, but they needed to know what was technically feasible in order to refine the requirements.
• They say they will never do a redesign again because they have set up an agile process. Future updates will be in phased batches, so they are in a constant state of relaunch.

Jeffrey Zeldman says,
“I advise every web designer who cares about typography and web standards—that’s all of you, right?—to read the minutes of this remarkable first gathering, and to keep watching the skies.”

It happens. The client changes their mind to have a feature removed from their to-be-launched-minutes-from-now web site. And of course this same client has shown in the past to have a habit of changing their changed mind. Coding that silly content block that just HAD to be where it is (never mind visual balance that was thrown off by having it there) took some time. It would be a shame to waste the effort only to have to re-code it again in the near future. So what do you do? You comment it out.

Don’t do it. At least not with HTML comments.

Page code always comes at a cost. A network transfer cost. What looks like a trivial bit of code that “It doesn’t seem to slow down the page load to me…” adds up over time.

Example: One of our client sites had a weekly page request rate of 60,890 pages a week. The page in question was an 8,487 byte PHP file (remember that PHP bit for later…). It contained 1,348 bytes of commented out code of a “ah, that’s not ready yet, launch without it” feature. 1.3KB doesn’t really sound that bad, does it? But that’s actually ~15% of the file size and that’s multiplied by over 60K+ pages a week… Over the course of a month that’s 313MB of unnecessary data transfer slowing down site visitors viewing experience. And that’s just one client.  Because most of our clients are in a shared hosting environment, one must remember that every CPU cycle, every byte of RAM and every packet of bandwidth that is unnecessarily used up by one site is no longer available for another site to use; a well coded high-performing site can be slowed down by a less efficiently coded site that is running on the same server.
Page load time has an effect on site visitors.  We know it from our own experience. If a site is too slow, we’ll will say “forget it, I’ll go elsewhere”. If a site is fast, then we’ll say “OK… let’s see what’s here”.
Speed encourages “site stickiness”. Visitors lingering on a site enhance brand awareness. And that’s what we really do at GS Design, right?  But that doesn’t mean that one should delete one’s code, do away with comments or have an endless number of confusing index.bak, index.tmp, index.bak2, index.bak.bak.bak.spam.bakedbeans.spam.bak.tmp.bak files.

The tip here, at last is, use server side comments.

Most of our sites are coded in PHP. A few others are in ASP or JSP. Very few pages we code are actually straight .HTML files. By using server side comments…

< ? /* Awesome news */ ?>

…the code is still usefully available to be added back into the site at a later date, yet is not being presented as part of the PHP processed page. So, no network transfer, a faster loading page. ASP has similar commenting features but isn’t nearly so nice - multi-line comments aren’t possible. So one has to do something like.

< %
'
'Awesome news!
'
%>

Not as convenient but still useful. JSP? Yep, that works more like PHP.

< % /* Awesome news!*/ % >
Server side comments. So YouTube videos will start quicker. Making for a faster Internet for all of us.

I stumbled across this useful list of 100 social media blogs. This could be helpful as our clients continue to ask us for guidance in this area. Enjoy.

http://www.virtualhosting.com/blog/2007/top-100-social-media-and-social-networking-blogs/

It comes up more and more that dynamic web page features should offer visual hints to site visitors that “this process may take a moment, please wait”.  Enter the spinning, bouncing, hypnotizing animated GIF commonly called “a throbber”.  There have been multiple sites in the past that have served as libraries for commonly used throbbers on the web.  But this one is different.  The nice thing about this one is that it can alter the background colors of the animated GIF you choose to suit the need at hand.

Bookmark this one FED’s!  Designers too - designers should be providing FED’s visually fitting “themes” for dynamic behavor, like throbbers.  This web tool should help.

Amazon is having LOTS of problems today - their S3 service (and store) have been nothing but errors for over an hour now.
http://blog.linkdiagnosis.com/?p=16

Check out this resource for examining the story behind major corporate logo redesign projects (including a few local companies Manpower and Johnson Controls). It’s an impressive amount of content:

http://www.identityworks.com/reviews/index.htm

You ever notice subtle differences between Photoshop files and the JPGs and GIFs that “Save for Web” produce? Maybe colors look a little washed out or less vibrant? It was a lot to do with the color profile that “Save for Web” attaches to the image, sRGB or Standard RGB. sRGB is a generic monitor-type profile that tells “average” 2.2 gamma monitors how to display color. The solution may be to design your sites with your monitors to calibrated a bit more like a PC. Here’s a great article about how to go about solving these problems:

http://www.gballard.net/psd/saveforwebshift.html

To re-calibrate your Mac’s monitor, open your System Preferences. Go to Displays and choose the Color tab. Hit the Calibrate button and walk through the steps. Chose 2.2 Television Gamma and D65 for your white point. It’ll look a little different, but you quickly adjust to it. Plus, there will be less surprises when you use the “Save for Web” export. Even if you don’t use “Save for Web,” all the Front End Developers use it. So your site design will be filtered through it at some point.