Upgrading to BlogCFC 5

Lately several of us in my office have been trying to blog more at work. I realized that I’d pretty much let this blog go feral over the last few months, and thought I’d give it a little attention.

When I set this blog up, I decided to use BlogCFC. In the intervening months a new version had been released (BlogCFC 5), so I thought I’d take a whack at upgrading from the previous version I had installed.

All in all, the upgrade went okay. It was a little bumpy making sure I made the necessary mods to the database and tracking down a bug in the Captcha CFC that may be related to my environment.

Of course, if I’d actually *read* the README file, things would have gone a lot smoother!

Lorem Ipsum at your (middle) fingertips!

In testing out various CMS packages (including our own), I keep needing to get my hands on a block of text for some dummy page or other…. usually this text winds up being the body of the last email I happened to read in Thunderbird. :)

In setting up a new Firefox install with my usual kit of extensions, I found another neat one — a one-click Lorem Ipsum inserter: Dummy Lipsum. This extension adds an option to “Insert Dummy Lipsum” under your right-click context menu. It apparently pulls measured amounts of the classic text from the now-even-more-handy Lipsum.com.

Right-clicking on the MacBook Pro

Apple brought two-finger-tap right clicking to the MacBook line with the 17″ MBP and new MacBooks, but the first gen was left out, or so I thought. It turns out the *hardware* is there in the 15″ MBP, but the driver didn’t include the functionality. The driver shipping with the newer MacBooks merely accesses capabilities what was already there in the hardware.

Stumbled on this yesterday… Someone has brought two-finger right clicking to the first-gen MacBook Pros:

Right Clicking on a MBP

Seems they managed to repackage the newer drivers and get them working on the older MBP!

Eolas JavaScript Fix for Flash Navigation

I think I finally have a workable solution to the Eolas IE issue with the Flash navigation on our college Web site. My hope is that we’ll be able to hit the largest audience possible with at least some measure of functionality, while simultaneously maintaining a semblance of Web Standard-itude. How’s that for ambitious?!?!

My solution is basically a three-tiered approach:

  1. Object tag-based embedding (a la the Flash Satay method) of the primary navigation bar .swf file
  2. Alternative content — an ordered list of images/links mimicking the links in the Flash swf with javascript mouseover effects. These two tiers are embedded in the page using a static JavaScript file that document.write()s the content into the page.
  3. A second set of images/links as an all-else-fails backup for users with no scripting support, served by <noscript> tags.

Some downsides:

  • Users who have no scripting, or have it turned off, will never see the Flash version, whether they have the plugin or not
  • Non-IE users will always have their navigation built with JavaScript. Seems inefficient, but without walking down the path of browser detection, I don’t see a way around this.
  • Our current set of non-Flash alternative images are PNGs, which look really awful in IE6. Hopefully we can remedy this soon.
  • With potentially two copies of the alternative content in the page (one in the JavaScript-generated object tag, the other in the <noscript> block), there may be difficulties that I’m not seeing.

I’m working on a more thorough writeup of this process to post somewhere, but that’s a summary. Feel free to poke around the code — if anyone has suggestions for improvements to the method, I’m all ears. I’m in the process of working up a solution for our QuickTime movies following a similar path, with some ideas pulled from unobtrusive JavaScript.