The jist of the script is that it’s a function that allows a snippet of code to be fired once an element is viewable on the screen.

We have a few longish type pages where I work and I wanted to use the Fade Anything Technique to do what it does best, and hilight a few elements on the page. Well a few of those elements were not viewable on the screen above the fold so I had to come up with something to make them fire when they were viewable. So long story short…I slapped together a few miscelaneous things I had laying around and onViewable was born.

Please find the details of the hows and why’s on the onViewable page. Any updates will be posted there, and I will mention them in the blog so you can be aware of them.

I look forward to any feedback.

I must give credit here (in addition to on the script’s page) to the great PPK (Peter-Paul Koch) of QuirksMode.org. Without his invaluable resource and a few functions I borrowed, this wouldn’t be here today. Thank you PPK for your great contribution to the community.

So, here’s a super quick and dirty bookmarklet for tracking friends while playing. This is like 30 mins of work and far from complete and perfect I’m sure. It’s also based on the current DOM of the page, so if that changes, this breaks. But since it’s centrally hosted I can compensate if that happens and the next time you use it after I fix it, it will work.

To use it, drag the following link to your toolbar, and then click that button after starting a game of Fastr. FastrFriends. After it’s loaded up, simply click a name to follow it, and click it again to stop following it (if you got the wrong one or whatever).

Potential upgrades I’m pondering:

• Option to show/hide all users that aren’t your friends
• Different colors depending on how high on the list they are
• Track their score and then show what they got on the last guess when it changes.

I know it works in FF 1.5 and IE 6. I’ve been told it doesn’t work in Safari but I don’t have easy access to that, so if anyone can tell me what to fix I will give it a try. Otherwise I will try and get a hold of one at work on Monday.

Report any bugs here… and enjoy!

VisitorMap uses the existing information that is already saved by ShortStat. It is meant to be a plug-n-play addition that doesn’t require any database or other changes. The only required change is in the file itself to set the Google API Key (free) for the folder you are installing it in to.

This is a quick and dirty release. Some of the data parsing I am doing could probably be done cleaner, but it works for being a late night “for fun” project… at least for now.

The data is provided by hostip.info which is a “Community GEO IP Project” (thanks to Randy for finding it). Basically it looks like they rely on visitors to state where IP’s are located. So to that end, it’s not a comprehensive list. When first testing the script, out of the 50 referers, only 18 had an entry in their database. But this is the only site we could find that was open and free, so if anyone has a better option (that doesn’t cost an arm and a leg… or even a toe) let me know. At the same time, because it is a free, open-source service… this may not be the best option for those with lots of traffic as they aren’t meant to be used for tons of hits.

Version 1.0 includes:

• Uses ShortStat CSS for similar look and feel
• Click on markers for more details (referer,page visited, date/time, browser/os, location)
• Text list of visitors with links to open the marker “balloons”
• Toggle between a small map with the above text links and a bigger map with no link list.

That’s about it… pretty simple as I said. But it works.

Please let me know what you think.

See it in action
Download the code

Thanks go out to Randy Hall at Code Dump for helping me test.

Thanks to the new pages function of WordPress 1.5 this will live at it’s own location, so there can be a single point of reference for any changes and such. But I will post any updates made to it here in the blog so that anyone who cares to, will know about it.

I will put the full text from the page here for the initial entry (and for searchability since pages aren’t searchable yet through WordPress), but all future changes will be found on the page itself.

Comments, feedback and suggestions are greatly appreciated.

Information

Script Name: onDOMload
Current version: 1.1
Last Updated: 03.31.2005
Download: onDOMload

Purpose

To allow JavaScript to run on a page after the head, but before onload and before an “at the end of the page” (in-content) JS script fires.

What is it?

This script starts looping trying to run it’s code until the page is done loading. The code is continually checking for certain DOM elements to load from when the functions are called, until an onload call stops it. Using this method, the code you want to run will happen as soon as the loop runs again after a given DOM element with a certain tag/id/class is loaded, not onload or when another in-content JS call is made at the bottom of the page.

How does it work?

You provide two things.

1 – What you want the code to be run on – You can pass an ID (#theID), a class name (div.class), an element name (td) or several, but not all, combinations of the above (div#theID h4).

2 – What code you want to be run – You can pass it any code that you want, as it does an eval on it when it’s time to run it. I know that’s not super efficient, but if anyone can think of something better, please let me know. Since the code can be run multiple times, it provides a keyword of “theTarget” that references the current element being manipulated.

Every X milliseconds the script tries to run your code again, looking for the DOM elements you provided. When it finds one it runs the code on it, and then keeps track of how many it’s done. When the loop happens again it compares how many it did last time, with how many there are now. If there are more then last time, it starts with the next newest one and runs through the rest of them. If it doesn’t find anything new, it keeps looping and checking for new ones each time.

An onload is run that says the page is done loading. It then stops the loops so that they do not continue to run as you are just looking at the page, and does one last run just to make sure nothing showed up between the last loop and the onload.

Why use it?

As mentioned above, until now there have been 2 ways to fire code later on down the page. 1 – onload, which waits until every element (img,script,css,etc) has loaded on a page. If an advertisement, or stat tracking pixel, or whatever hangs for a while… your script can’t fire yet. 2 – “in-content” reference. This is a tad better in that you can call it at the bottom of the page, and it runs as soon as it is read by the browser. This again can potentially be slow if the page is very long, or if something server side hangs the page before it gets to it, but is definitely faster then the onload.

onDOMload allows code to run much sooner during the pageload. If the code you run makes changes to the looks of the page, then this will allow it to happen much faster then the other versions will. It also allows you to keep all your code in one location… at the top. Instead of needing part of your code at the bottom.

History

I had thought of this concept dozens of times, but finally started playing with it after the Man in blue posted about it and gave an example. The need for this became pressing for me when working with a version of IFR which had to wait till the end of the page to do the replacement. We would always see the headlines loading after the page was mostly rendered, and it didn’t look all that great.

I have improved on The Man in Blue’s version (I hope) by adding the ability to run code on elements with a specific class, ID or just on all instances of a given element. An earlier version of the script just had ID and tags available (the unreleased 1.0 version), but I leveraged the code from Alessandro Fulciniti’s Nifty Corners (which are pretty dang nifty, btw) to improve the ability to direct the code. You can also reference the current element by using “theTarg” in the passed code… kind of like a “this” call.

See it in action

Example 1 – Several different types of schedulers on the same page.
Example 2 – Example of how an in-content or onload call can delay your intended actions.

Compatibility

Works fine in FireFox 1.0.1, Win IE 6.0 SP2, Safari 1.0.3 (if anyone has a newer version they can confirm in, please let me know)

Partially works in Mac IE 5.22. I may get this working in the future, but for now it’s not a priority.

Changelog

03.31.2005 – 1.1 – First public release. Fairly decent overhaul from the unreleased 1.0 version. Added ability to go off of classes and IDs. Added final check after onload fires.

1.0 – Never actually released

His one lament about this fix:

The one sort-of drawback to using this approach is that it seems to require that the call to pngbehavior.htc sits in an embedded style sheet, or else nothing happens. This may very well have to do with the way the JavaScript monkeys around with external style sheets during startup. If any of you IE/Win JS gurus can figure out a way to get the behavior to fire without having to embed it into the presentation, that would be stellar. If not, it’ll just be documented as a “leave this in if you’re using alpha PNGs; otherwise you can take it out” thing.

Now I don’t pretend to be an “IE/Win JS guru” but decided to play around anyway. Using the simpler example at the top of Erik’s page I saw what the “bare necessities” were. Now that I go back and look at his .htc behavior closer, I see that I am doing some of what he was doing there… but just in the JS.

What I came up with is a quick little JS script that cycles through all the images on the page, if an image is a png (detected by the extension) then it applies the appropriate filter and replaces the image with a clear .gif file. This eliminates the need to have any image specific references in the CSS or JS, and the need for the HTC file altogether.

See a demo of the script in action.

I’d get all fancy and separate out the script and stuff for you to easily peruse, but I probably need to get back to work. So just view source and poke around.

Hopefully it is found useful, and will be a help to Eric’s issue. Thanks to Erik for the initial script and research. Feedback is welcomed as I’m always willing to learn.

We are big fans of his Favelet Suite over at Sprint, and use it daily. One of the favelets is the Mouseover DOM Inspector (MODI) that we used more then the rest to get a nice quick look at how our CSS based pages are laying out by using the background color that MODI provides.

A favelet (or Bookmarklet as we usually call them here… same thing) that I had always wanted to make was one that showed the parent structure of the element you moused over. When I finally got some time, I thought that tweaking Steve’s MODI favelet would be a natural fit. So I snagged the parent structure parsing code from our Sprint IFR implementation and slapped it into a copy of MODI. After a little tweaking to actually spit out the parent structure, instead of just walk up it, it was working pretty good. Added the Height/Width while I was at it and called it good.

A few weeks later I was working on another project and was regularly trying to find the X,Y of a given element (X,Y finding thanks to PPK over at quirksmode.org). Eventually the lightbulb went off and I just added it to the MODI script that was fast becoming the one stop shop for everything we needed.

After using that for a while I finally decided to offer it up to Steve to add to his own script, so that others could use the new features as well. The update that I sent him was added today and now I can go back to just needing his Suite, and can remove a bookmark from my toolbar.

Many thanks to Steve for the great resource that he provides in the Favelet Suite (and naturally each individual Favelet). I know it has saved us a lot of time in various circumstances, and it’s an honor to be able to contribute to it.

The “One Line”:

if(!foo.nodeName) foo = document.getElementById(foo);

Imagine you make, borrow or steal a function that does “something” to a given element. The function is setup to require the ID of the element in question, so that you can do ye ole “getElementById” (gEBI from now on) on it to then do whatever spiffy thing you want to do to it.

But what if you already had already done a gEBI on this element, and the result of that is sitting in a variable just waiting to be used… why should you waste resources doing it all over again, and have a second variable with all the same information.

Or… reverse it. Your function is expecting a gEBI’d var but you pass just the ID. It won’t have the information it needs.

Enter the “One Line.” What the code does is check to see if the variable that was passed has an attribute (nodeName) of a gEBI’d variable (if(!foo.nodeName)). If it does then it goes merrily on it’s way. If it doesn’t, then it must have just been an ID so the line does a gEBI on it so we can do what we want to do to it (foo = document.getElementById(foo);). It sets the results of the gEBI to the same variable the ID was, so the code below it is none the wiser. Whichever thing you send to it, after this line you will have the same thing to work with.

Now granted… in a perfect world all your functions will be written ever so neatly and you will always remember what to send to them or it would always be one or the other. But since we are such a generous community, and are always sharing new ideas, I’m sure your .js files are a hodge podge of functions from various people, and even various scripts that you have written previously and pulled into a new one. The One Line levels the playing field.

So to sum up… this one line of code makes it so you don’t have to worry about what you send to your function. Either an ID or a gEBI’d var will work.

A really lame example of a function that changes your text to red:

function redText(theText){
   theText.style.color = "#f00";
}

In the above, it is looking for a gEBI’d variable to apply the style to. So it won’t work if you just pass the ID.

function redText(theText){
   if(!theText.nodeName) theText= document.getElementById(theText);
   theText.style.color = "#f00";
}

Using the One Line, it can now accept either an ID or a gEBI’d variable. Everyone is happy

One line to rule them all,
one line to find them.
One line to bring them all,
and in the function bind them.

After France (who is always in the know) pointed me to the overhaul, I (naturally) went poking through their code and they are doing some sweet stuff. Much of it required by the strict standard not allowing things like “onclick” attributes in the code, they use the DOM to parse through all anchor tags on a page to create popup code, status bar messages, and more.

One thing I found weird is that they do the following at the top of each page:

if (!document.getElementById || !document.createTextNode) { window.location.replace('/upgrade/'); }

This is presumably to redirect older browsers to their upgrade page. While I can understand doing this from a standpoint of locking down your audience to your selected/supported browsers, part of the advantage of an XHTML design is that older browsers can view the site in is “degraded” form and still be able to get the information they are looking for just without the bells and whistles. This snippet of code basically eleminates that “feature” of an XHTML design, and locks those users out.

That minor confusion aside, this is a great looking rewrite of the site and whoever did the job (inside employees or vendor) are to be commended for their great job. They have been able to implement many things that we have pondered at Sprint (parsing in popup code onload, etc) and it will be intersting to see how things shake out for them over time and what others have to say about their implementation.

Edit:
After posting this I went poking around my own site and saw that Chris Moritz made a comment on my Sprint IFR article. Wonder if they were pondering using IFR for the Chevy redesign?? Oh, and got Chris’ name from a Digital Web mention of the redesign.

Edit 2:
From another mention (in portuguese) we meet antother developer (search for “thew”) who mentions yet another developer, Dave, who has a site. Hopefully Dave will put up some kind of a write-up on the launch.

ActionScript is fairly similar to JavaScript, and if you know any programming language you will be able to appreciate the majority of what is going on, just maybe not the fine details. But If you know the poem well enough you may be able to get a good enough kick out of it if you are even slightly techy/geeky.

Found via /.

Jabberwocky text to compare to

This lengthy article is here to describe the process of how Shaun Inman’s IFR technique came to be used on Sprint.com and SprintPCS.com. This is my first write-up of the process involved in implementing a major new standard, and I didn’t take the notes I should have along the way… so please bear with me.

While the majority of Shaun’s IFR script (revised) has been re-written for our own use, the basic concepts are already described in his articles above about how it works. Not all of our pages are updated to use the flash headings yet, and may not be for some time (CMS integration and the like). On Sprint.com, the business section is using it, and on SprintPCS.com most of the shop side is using it (ex: 1, 2, 3, 4, 5), but not Manage (yet).

This all started when Shaun first launched IFR on his site, not his official documented launch linked above, but when he first started using it on his site. A co-worker, France, noticed it and sent me the link. We were quite impressed and discussed how cool it would be to use on our sites here at work. At that time we used one of the first FIR techniques for all H1’s and H2’s across the site which ended up being hundreds of titles and the maintenance was insane.

We discussed it kind of as a cool concept and left it at that, thinking that the “powers that be” wouldn’t go for such a prominant Flash element being used across the site. But when I went home that night, I couldn’t enjoy my TV shows, I couldn’t game (*sigh*) and I couldn’t sleep because I couldn’t get the concept out of my head. It was ruining my life. I came back in the next morning and spent every extra second I had on figuring out how I could make it work for us. I went through every line of his script and picked it apart to see what made it tick. In the end, I thought that it was something that was doable.

Difficulties abound

After making an initial draft of the script and discovering that I actually had a clue about what was going on in it, we started coming up with issues that we would need to overcome for it to work on our site. Several of them we thought were insurmountable, and would make it so that we couldn’t complete the project. But thanks to many great discussions where we just talked things out, and bounced ideas off of each other, we were able to overcome each problem that was presented. This was a great testament to working as a team and not being afraid to ask for help. I will go through each of the problems that I can remember, and what we did to overcome them.

• Special Characters – The most troubling issue we saw at the outset was the need to compensate for was our extensive use of special characters in our copyrighted, registered, trademarked, and service marked product names. This is where I first went to our resident Flash guru Lars Hacking to see what he thought. This one gave us the biggest hang up. He had some great ideas, and started tinkering in his free time at how to make it happen. To compensate for characters that are not easily passed into flash, I check for those characters and replace them with characters we are fairly certain that we won’t need as themselves (ie: ~`{}[]). Then on the Flash side, Lars takes them and puts in what it is supposed to be there.
• Our grid – Our site is based on a grid that we must follow. We have 3 columns for the content, and a given module can span 1, 2 or 3 of those columns. So the swf files had to vary in width to fit in the size of module they were currently in. To do this I walk up the DOM structure (many thanks to PPK and his invaluable site) checking the className’s of each parent until I find one with one of our specific class names that designate width. Once that is found (and I know which one it is), I can set the width that I have to work with and go from there.
• Underlined H2’s – We have two different kinds of titles, plain text, and underlined. To compensate for this I did the same DOM walking above to see if we were inside of a container that had the className that would dictate an underlined version.
• Two-line H2’s – We have some instances where we allow our graphical h2’s to wrap to two-lines. Using the same technique that Lars uses for counting in the flash, I find the actual width of the text in question (by character, specific to our font) and if it is greater then the width found in “Our grid” above I know to switch to the 2-line .swf version. We do not allow 2-line underlined headings, so luckily we didn’t have to compensate for that mixture. As an FYI, H1’s are not allowed more then one line either.
• Error headings – Our error module has different font and background colors. I again walk the DOM to find the container we are in, and then pass along the hex of the colors to be used for this given module. The flash then applies the passed colors to the output.
• FOUC – We noticed (as did Shaun’s readers) that there was a breif Flash Of Unstyled Content before the flash headings kicked in. To compensate for this, immediately after the flash version check is done, we load a .css file that updates the headings to be white text so that they are not seen. So we aren’t really eliminating the FOUC, but changing it to something that you can’t really see. We also add a second script (could be a few lines really, but using a remote script gives us better future control) to the end of the page that tells the Flash functions to fire. This saves us a little more time by firing before the “onload” goes, just in case a single graphic is holding things up or something. We set a variable to make sure that we don’t run it again “onload”. This way the second file is optional, and can only help if it is used.
• Content behind the flash – Our H1’s sometimes sit on top of graphics. To be more pleasing to the eye, the graphics will some times come up into the H1 row, when there is room for it to do so. With Flash transparency not being completely sound, we couldn’t just allow the H1 swf to go the full width of the module overlapping the parts of the image that came up into the H1 space. We had to use the text width determination mentioned above to determine the width of the text and then call an associated swf file that was sized close to that width (rounded up to the nearest 10px). So we had 20 some odd templates for each width between 170-360.

Selling it to the people in authority

After getting the majority of the above squared away so that we could be confident in saying that this is a solution that we could accomplish, we set up a meeting with our Web Standards comittee to show them this crazy idea. Some of the points we were sure to make are as follows:

• Stats for our site say that more then 90% of our visitors had the Flash version we were targeting
• This would save tons in labor costs
• This would make our turn around time much faster
• There would be graceful degredation for those without flash, using our accepted “non-image” standards
• There would be very limited code impact, as all we have to do is add the call to the .js file on any page we want it to work on. No need to go back to each heading and edit anything (as long as the page was built following our established structure)
• Did we mention the large reduction in cost??? =)

We must have put just enough “stuff” in their coffee cause they said “ok… go ahead and test it”. So we put up a few test pages in production to see if anyone would notice, or complain. We asked some visitors if anyone saw any issues on the pages in question. A few noticed the FOUC, but after the fixes were put in place mentions of that problem went away. Only one user (at sprintusers.com) noticed that we were using Flash, and that was because he had an extension on Mozilla that put an icon on any Flash elements on the page (asked him in a PM about it for those who can’t find mention in the thread).

After a few weeks of the above, we met again to discuss the results. We had received no complaints, were able to show the results from the above informal forum polls, and had a few improvements to show over our first meeting. They continued to like it (nothing in the coffee this time) and said they would take it to the people who paid the bills. Since bill payers like numbers, below are some of the numbers we provided to give to them. These numbers are just educated guesses, and I am not sure how far off from reality they are.

Bandwidth
26 K Savings in shop.css code (when we finally remove all reference to graphic titles)
8 k Savings in heads.css code (when we finally remove all reference to graphic titles)
20 K Savings in the actual graphics (average of .5k each X 40 titles per session [total guess])

54 K Total savings per visitor

With an average of 8 Million visitors per month, if on the low end we figure that they each download things only once, and then it’s cached for the rest of the month… we save 432 Gig a month of traffic. With a conservative estimate of $1.00 per Gig, that is $5,000 in annual savings. If we go to the other extreme and say there is NO caching, and every file is downloaded every time, we are looking at 7,000 Gig savings a month, for an annual savings of $84,000. The true amount lies somewhere in between.

Server Load
We will be switching from 3-5 unique titles per page, to 6 total files that will cache for all pages. Doing some math off the top of my head, that should save us 472 Million file loads per month (130 Million page views per month X 4 titles per page = 520 Million vs 8 Million visitors X 6 files = 48 Million files loaded). This doesn’t even consider the Safari bug that loads all 300-500 graphics each time they view a page that won’t be an issue any more. I can’t venture to guess how this will effect server performance, and how that transfers into a dollar amount.

While we were in beta testing with this project, Shaun released his articles on how to implement his IFR solution. We were able to gleen a few tidbits from the article to reduce our flash file count from 40+ to 6 or so which helped alot.

The above are based off our current standing. It does not consider additional titles and size associated with them that could be added throughout the year.

Work load
Guesses that are probably on the low side:

• VizD’s save 30-40 hrs a year
• Code save 60-80 hrs a year

If you did a conservative estimate of the time to create, cutout, save, add to code, add to stylesheet, test, check in, etc… for each title, we figure around a total of 5 minutes per image.

An example: A recent business site re-launch, which consolidated and simplified 7,000 pages, started with the flash titles from the get-go. In the end they had 1,253 H1’s and 3,841 H2’s. At the above average of 5 minutes per image… that is over 400 hours of time saved. If you figure a professionals time at $50/hr that is a $20,000 savings for this project alone. (wish I could say the check was in the mail Shaun… but you know how it goes;)

After all of the above, we got approval to move forward with using it on the site and it has become a standard to be used across the comapny. Naturally something like this doesn’t happen over night, so we have been updating what we can, when we can. The above business site launch was a huge proof for the technique in both ease of use, and cost savings. More pages will come online as they are edited, and as we find ways to get it put into existing Content Management Systems.

Bring it on home

To sum up… our old process for adding a new title was along the lines of the following:

1. Put text inside of h1 or h2 tag
2. Try and find the title we wanted in our current list of titles in the .css file (an occasionally alphabetized list, that had a few different naming conventions introduced to it as we went along)
3. If we didn’t find it in the list, request the title from our Visual Designers
4. Get the image from VizD, rename as appropriate and place in the correct folder
5. Add a line to the .css file with a unique ID for this title.
6. Add the above ID to the .html file
7. Check the .html, .css and .gif file into cvs
8. Since the above are in different directories… go back and check in the ones you missed or forgot to flag correctly.
9. “Enjoy” the fruits of our labor

The new process

1. Put text inside of h1 or h2 tag
2. Check .html into cvs
3. Enjoy the fruits of our labor

Gotta love the simplicity.

Thanks and praise go to Shaun and his innovative thinking and willingness to share with the community (even though I was trying to steal it before he offered it up *gulp*). While our script is 99% re-written, it is still IFR at it’s heart. Many thanks also go to all those involved with this project at Sprint for making it happen. In no particular order… France, Lars, Candice, Jenney and Kirk.

If anyone actually reads this, maybe I’ll do a future article breaking down the actual code and why I did things the way I did… then the REAL guru’s can come in and tell me how to do it better =)