October 29, 2006
Analytics Guesses Connection Speed?
Discovered something interesting tonight as I turned on and tested a new site -- Google Analytics appears to classify traffic coming in via AOL as dialup traffic. In this case, the AOL traffic was identifiable as my test surfing, which I was doing across a broadband connection using the Mac and Windows AOL clients.
This supports speculation in the Analytics group that the stats service does not use any sort of empirical testing, but instead looks at the ISP or IP range and attempts to make an educated guess based on what an IP database returns.
Unconfirmed speculation is all the group has had to go on; Google's Help Center states that the Analytics measurement is of "The visitor's connection speed, as determined by the visitor's internet connection as determined by the browser". This is a bit ambiguous, and afaict no one from Google has appeared on group to clarify the questioning posts.
I had always assumed an IP database existed, because out of the Analytics connection speed categories: 'Cable/DSL', 'Corporate', Dialup' and 'Unknown', the Cable/DSL and Corporate segmentation could only come from an IP owners database, still, it's a bit disappointing to learn that the Connection Speed reports are apparently inferred and not actually measured.
If I had a rich media site with a significant amount of AOL traffic, I'd want to know just how much of that traffic is broadband vs. dialup; looks like in such a case Analytics wouldn't be able to help me.
October 18, 2006
IE7 Leaked!
The word on the street was that IE7 is to be released today, and it looks like Yahoo pushed a customized IE7 live before the mothership. Yahoo's version (build 7.0.5730.11IC) predictably comes with the Yahoo Toolbar, search set to use Yahoo's index and a couple Yahoo home pages. Softpedia also has a version available from their download servers with the same build number.
I imagine the official version is due very shortly. Requires a valid WinXP SP2 or XP 64-bit SP1 OS
October 7, 2006
IE7 Imminent: Plug-in detection woes
According to Microsoft's IEBlog, IE7 is coming this month...Are you Ready?, with auto-update kicking in a few weeks after the download is made available.
Most of the expected compatibility issues are in CSS filter hacks that will no longer work in IE7. However, in working with the IE 7 Release Candidate browser this week, I've found a couple non-CSS-related issues that need to be dealt with before our clients start running across these themselves.
One standing issue is with AWStats installations that report on WMP plug-in penetration, and the other is a brand new but very similar issue that now affects both QuickTime and Windows Media-using clients and detection/degradation strategies.
The core problem is a security change to IE 7 that deprecate formerly recognized ActiveX controls as "safe" to use. When affected plug-in detection scripts are run, IE 7 will complain with somewhat scary-looking security alert and information bar pop-ups:
Clearly, long-used plug-in detection scripts for QuickTime and Windows Media Player is no longer a transparent-to-the-user process.
I’m still looking for a solution for transparent QuickTime detection, but we can fix the Windows Media detection triggers in both AWStats and our plug-in detection code by swapping out:
“MediaPlayer.MediaPlayer.1”
-- with --
“wmplayer.ocx”
The above changes the detected baseline from the now-considered "unsafe" WMP 6.4 to a "safe" WMP 7.
We can also pacify AWStats so that it no longer causes IE7 to throw a fit over QuickTime detection, but at the cost of giving up gathering QT metrics, by opening awstats_misc_tracker.js and commenting out the line:
var TRKmov = awstats_detectIE("QuickTimeCheckObject.QuickTimeCheck.1")
As for QT detection and degradation code, until a suitably compatible, new transparent detection scheme is found, we might want to change our code to test for QT only on non-IE7 browsers.
Questions? Bring ‘em!
October 2, 2006
AOL vs. Flash
AOL has long presented challenges to web developers. Many of us are aware of munged graphics, designable space and caching issues. We've learned to speak authoritatively to client concerns about same; after all, AOL still commands a user base of 20+ Million dial-up users and a lesser number of broadband subscribers. As marketers or activists, we just can't afford to ignore that many potential visitors.
One AOL issue I keep running across is with Flash content that rely on external images. Developers commonly use external assets for Flash because of the flexibility such an approach allows in managing presentation, be it jpeg imagery, copy, audio/video or other swfs. External jpegs will fail to render for AOL dial-up users unless special precautions are made on your web server.
To explain this, a little background is necessary:
AOL has to manage a massive amount of bandwidth in order to provide their subscribers with a reasonably fast internet experience. One way they do this is via caching servers. These caching servers capture page and image requests and deliver these cached items to AOL users within the AOL network instead of always going back to the source. As AOL's webmaster site states, "If AOL did not use cache technology, a large part of the Internet backbone would need to double or triple in size."
AOL's caching solution is the reason why your client might complain that recent updates to their site do not appear; the client is seeing the older, cached version instead of the new.
Another bandwidth management technique AOL uses is to recompress cached images -- this is where we run into problems with Flash content that use external jpegs. These re-compressed images are not actually jpgs anymore, and as Flash Player is expecting a .jpg file type, presentation will fail.
Luckily, we can fix both caching and re-compression issues with a cache-defeating strategy and a server configuration.
For caching:
If your external content changes frequently or is time-sensitive, you can ensure that the latest version is always retrieved by appending a random number to the url, for instance: myContent.xml?<random_string_here>. Make sure the string is long enough to lessen the likelihood of your users encountering a cached version.
For re-compression:
We can prevent re-compression by forcing the webserver to send .jpg files as a generic binary mime type. AOL's cache will no longer recognize the jpgs as "compressible" and will pass them along unaltered. If you don't have access/control over your server, Adobe has a technote on the re-compresssion issue you can forward to your isp. If you do have access/control, then use the following for your particular server type:
-Apache
You can create a .htaccess file, which is just a text file that Apache recognizes as a kind of configuration command, in your images folder with the following line:
"AddType application/octet-stream .jpg"
Make sure you name the file correctly, that's ".htaccess" ; the preceding period is important and will make the file invisible to Unix-based OSen.
-MS IIS
For IIS you'll need control rather than simple access to the web server.
Open IIS and under Headers/Mime Types set .jpg files to have the mime type "application/octet-stream".
Now that AOL is free to users who bring their own access, there's no reason not to get an AOL account for testing. I also find the AOL client convenient for when I want to test sites outside our network, as you are tunneling through your firewall in order to reach AOL services.
Testers Note:
Unlike the Windows dial-up clients, image recompression is turned off in AOL for Broadband. Testers using that version will need to manually enable image compression in order to test their fixes. AOL for OS X comes with recompression enabled.
