So, I changed which icons it shows and used the better, alternative ones. They are already there in the icon bar in c:\wamp\images_on.bmp and c:\wamp\images_off.bmp. We just have to change the mapping.

In c:\wamp\wampmanager.tpl change lines 10 – 12 from

TrayIconAllRunning=16
TrayIconSomeRunning=17
TrayIconNoneRunning=18

to

TrayIconAllRunning=9
TrayIconSomeRunning=10
TrayIconNoneRunning=11

The downsides: there is no difference between the icons for offline and online modes, the new icons seem meant to be used elsewhere (but I never see them, or at least not nearly as much as I see the tray icons).

I’m working on a project that loads (and hides) content meant for lightbox in the markup of the main page. We are doing this in order to have quick reactions to the users’ clicks and optimize the content for SEO. With the existing mechanism, Lightbox2 will reload the page content if the trigger points to an in-page anchor.  For instance,

<a href="#anchors-aweigh">Load existing content</a>

will cause Lightbox2 to reload the current page even thought the content is already available in-page. This kills the quick reaction time and adds ticks on the tracking calls and increases server load.

Taking a note from Erik Hedin on how to focus Lightbox on an anchor after (re)loading the page, I rewrote the the modalContainer’s load instructions to check against the current url and see if the target content is already existing on the page. So, the line

$("#modalContainer").load(src);

in lightbox.js becomes

/* HERE'S THE RUB */

/*
	if already in the page, load in the content
	test by comparing src and window.location without hashes (anchors)
	and then finding the src's hash in the DOM

	if either are false, fall back and load the old way
*/
var srcHash = src.replace(/.*(#.*)/, '$1');
if (window.location.toString().replace(/#.*/, '') == src.replace(/#.*/, '') &&
		srcHash && $(srcHash)) {

	// clone the referenced node and alter the clone's ID, then insert it into lightbox
	$("#modalContainer").html($(srcHash).clone().attr('id', srcHash.replace('#', '') + '-clone'));

} else {

	$("#modalContainer").load(src);

}

/* THE RUB STOPS HERE */

But but but but but but, we’re not done.

In Erik’s post he advises changing the lightbox.js script in the Drupal module. I don’t like changing other people’s code; I’d rather overwrite it for my application. Instead of digging inside the module, I have included another script that overwrites the offending Lightbox.showData method. This way, if the modules is updated by its devs, I don’t have to go digging again. Plus, our Drupal project is instanced over several machines and a dev and a staging and a production site, so changing the module is hard to maintain.

So, in the end, my application-specific script looks like,

Lightbox.showData = function(){
    $('#loading').hide();

    if (Lightbox.isLightframe || Lightbox.isVideo || Lightbox.isModal) {
        Lightbox.updateDetails();
        if (Lightbox.isLightframe) {
            $('#frameContainer').show();
            if ($.browser.safari) {
                $('#lightboxFrame').css({
                    'zIndex': '10500'
                }).show();
            } else {
                $('#lightboxFrame').css({
                    'zIndex': '10500'
                }).fadeIn(Lightbox.fadeInSpeed);
            }
        } else {
            if (Lightbox.isVideo) {
                $("#modalContainer").html(Lightbox.modalHTML);
                $("#modalContainer").click(function(){
                    return false;
                });
            } else {
                var src = unescape(Lightbox.imageArray[Lightbox.activeImage][0]);
                if (Lightbox.imageArray[Lightbox.activeImage][4]) {
                    $(src).appendTo("#modalContainer");
                } else {

					/* HERE'S THE RUB */

					/*
						if already in the page, load in the content
						test by comparing src and window.location without hashes (anchors)
						and then finding the src's hash in the DOM

						if either are false, fall back and load the old way
					*/
					var srcHash = src.replace(/.*(#.*)/, '$1');
					if (window.location.toString().replace(/#.*/, '') == src.replace(/#.*/, '') &&
							srcHash && $(srcHash)) {

						// clone the referenced node and alter the clone's ID, then insert it into lightbox
						$("#modalContainer").html($(srcHash).clone().attr('id', srcHash.replace('#', '') + '-clone'));

					} else {

						$("#modalContainer").load(src);

					}

					/* THE RUB STOPS HERE */
                }
                $('#modalContainer').unbind('click');
            }
            $('#modalContainer').css({
                'zIndex': '10500'
            }).show();
        }
    }    // Handle display of image content.
    else {
        $('#imageContainer').show();
        if ($.browser.safari) {
            $('#lightboxImage').css({
                'zIndex': '10500'
            }).show();
        } else {
            $('#lightboxImage').css({
                'zIndex': '10500'
            }).fadeIn(Lightbox.fadeInSpeed);
        }
        Lightbox.updateDetails();
        this.preloadNeighborImages();
    }
    Lightbox.inprogress = false;

    // Slideshow specific stuff.
    if (Lightbox.isSlideshow) {
        if (!Lightbox.loopSlides && Lightbox.activeImage == (Lightbox.total - 1)) {
            if (Lightbox.autoExit) {
                Lightbox.slideIdArray[Lightbox.slideIdCount++] = setTimeout(function(){
                    Lightbox.end('slideshow');
                }, Lightbox.slideInterval);
            }
        } else {
            if (!Lightbox.isPaused && Lightbox.total > 1) {
                Lightbox.slideIdArray[Lightbox.slideIdCount++] = setTimeout(function(){
                    Lightbox.changeData(Lightbox.activeImage + 1);
                }, Lightbox.slideInterval);
            }
        }
        if (Lightbox.showPlayPause && Lightbox.total > 1 && !Lightbox.isPaused) {
            $('#lightshowPause').show();
            $('#lightshowPlay').hide();
        } else
            if (Lightbox.showPlayPause && Lightbox.total > 1) {
                $('#lightshowPause').hide();
                $('#lightshowPlay').show();
            }
    }

    // Adjust the page overlay size.
    var arrayPageSize = Lightbox.getPageSize();
    var arrayPageScroll = Lightbox.getPageScroll();
    var pageHeight = arrayPageSize[1];
    if (Lightbox.isZoomedIn && arrayPageSize[1] > arrayPageSize[3]) {
        var lightboxTop = (Lightbox.topPosition == '' ? (arrayPageSize[3] / 10) : Lightbox.topPosition) * 1;
        pageHeight = pageHeight + arrayPageScroll[1] + lightboxTop;
    }
    $('#overlay').css({
        'height': pageHeight + 'px',
        'width': arrayPageSize[0] + 'px'
    });

    // Gecko browsers (e.g. Firefox, SeaMonkey, etc) don't handle pdfs as
    // expected.
    if ($.browser.mozilla) {
        if (Lightbox.imageArray[Lightbox.activeImage][0].indexOf(".pdf") != -1) {
            setTimeout(function(){
                document.getElementById("lightboxFrame").src = Lightbox.imageArray[Lightbox.activeImage][0];
            }, 1000);
        }
    }
};

Thankfully, the magic of video has brought my dream to some sort of life. And, we launched the new OLSON O-Terns blog in the process.

http://www.olsonoterns.com/

It’s a good thing I’ve done a bit of acting before because this is going to win an award and how embarrassing would it be for other actors if this was the first thing I was ever in.

#veryembarrassingforotheractors

Philosophical Approach

The approach can be summed up in two points:

1. Write enough markup and style definitions to make it clear to other developers what is happening.
2. Write as little markup and style definitions as possible.

Let’s talk about what these mean.

Write enough markup and style definitions to make it clear to other developers what is happening.

We follow the principles of semantic web development which involves using markup to describe the data or content of a web page. In practice, this means things like using ol and ul tags to make lists of items instead of text delineated with br tags, and giving page elements class names that describe their function (eg “article-wrapper”) instead of class names that describe their appearance (eg “blue-background”).

Write as little markup and as few style definitions as possible.

Small file size and shallow markup heirarchy make the site faster to load and easier to maintain. To that end, we write as little markup and as few style as possible to make the page appear and function as necessary. In practice, this means things like using padding and margin to create space between elements instead of using br or empty p tags, and writing reusable CSS classes that add common traits (eg background-color) and can be used in conjunction with other reusable CSS classes that provide other common traits (eg font-size).

Rules

We have a few easy-to-follow rules for HTML and CSS development that have evolved from years of experience.

Rules for writing HTML

• Block-level elements are  never be self-closing, even when empty.
  <div /> should always be written as <div></div>, but but <img /> or <span /> is proper.
• Markup always validates unless there is a very good reason (eg for cross-browser support or CMS limitations).
  There are many validators but W3C’s is preferred: http://validator.w3.org/
• Documents are written for HTML 5.
  Documents should use the the <!DOCTYPE html> declaration.
• Tables are used only for tabular data, not for layout.
• Stylesheets are included in the <head> of the page.
• Stylesheets are included using <link /> tags, not @import statements.
  It is permissable, however, to use @import statements within an external stylesheet.
• Markup should be indented using tabs, not spaces, so that the indentation matches the markup heirarchy.
• CSS and JavaScript are included in external files, not written inline in the page.
• External JavaScript files are included at the bottom of the page just before the </body>.

Rules for writing CSS

• CSS is written a compact format characterized by the selector and all definitions on one line.
  Use http://www.codebeautifier.com/ to switch between formats; the format described here is called ‘High’ compression.
  Improper:
  

  .my-class {
  	width: 300px;
  	height: 300px;
  }

  Proper:

  .my-class { width: 300px; height: 300px; }

• Selectors use hyphens to delineate words, not camel case or underscores.
  Improper: .myClass or #my_element. Proper: .better-class
• Hacks to make pages work correctly in Internet Explorer are included in a separate IE-specific stylesheet and included on the page using conditional comments.
• During development, sites use a global stylesheet for universal definitions and separate sheets for independent areas or features of the site.
• Use of style attributes in markup is avoided.
• When possible (that is, when specific instances are known), .png transparency should be fixed for specific elements using the IE-6 specific stylesheet instead of using an .htc file as a behavior.
  Improper:

  a { behavior: url(iepngfix.htc); }

  Proper:
  

  a#button { background: none; filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(enabled=true,      sizingMethod=crop, src='../images/button.png'); }

• The default font size is declared in pixels for the <body> and the declared for other elements as percentages.

  body { font-size: 13px; }
  h1 { font-size: 125%; }

Seems like the criteria are:

• Several quickly-recognizable hits
• A dedicated fan base
• A generally upbeat catalog
• Inoffensive music
• At least half the members still living

My best guess: the Dave Matthews Band

Steve said: Hootie & the Blowfish

What do you think?

The Client: Bedlam creates some of the most interesting and original theater in Minneapolis. They run their own production and, in addition, rent their space to other groups. This means they have a large number of events to keep track of and promote,  and they needed a site that could accommodate them all.

My Role: Having designed, built and maintained their version 1 site, I was keenly aware of the workflow issues and front-end pros and cons that they were experiencing. I worked with them to find the new look and feel of the site and to expand the functionality. In the end, the new site was built on WordPress, with collaborative design and unique plugins.

The Technology: One of the initial hurdles of this site was importing the existing years of data into WordPress, including media and event dates. I created a unique plugin for them called TheatreEvents and wrote a custom import script that inserted the new posts and attachments and populated the data. The plugin features direct hooking into the admin interface so that event data entry is in the same form as post entry.  On the front-end, the plugin allows for sorting by the event dates and custom week and month views. The plugin will be released publicly soon.

The Highlights: Weekly calendar in the sidebar of most pages with Ajax navigation. Monthly calendar of events.

The Client: Thomson Reuters’ clients are savvy and busy. They knew that if the site was going to reach them, it had to be fast, solid and engaging.

My Role: Developer in small, focused group to create the prototype and an on-site advisor during integration with their existing systems.

The Technology: The client needed to integrate the site into their CMS but they had asked us to create and test a prototype site before handing it over. We built the original with very limited PHP since we knew TR would be using .NET in the end but PHP allowed our team to quickly build the prototype. The site uses a custom Flash video player and also has a limited but useful mobile version. This mobile version was very important to the client as the majority of their customers regularly use BlackBerrys and other mobile devices. During integration a few technical hurdles appeared from use of their legacy systems but because I was on-site at the time, launch was not affected.

The Highlights: Multiple video players used in conjunction with jQuery UI tabs. Animated main navigation.

There were eight of us on the OLSON team and Eric and I were last.