We have posted the first 16 sections of Step-by-Step: Installation and Configuration of a Google Enterprise Search Platform. These initial sections offer a basic, practical guide to how The Findability Project, with its project specs as ground zero, proceeded with installation of the Windows server software and settings, installation and configuration of Microsoft Office SharePoint Server (MOSS), and basic configuration of the SharePoint document site.

Much more is coming. These first several steps simply set the stage for getting into deployment of the Google Search Appliance (GSA), what we think are the more interesting and challenging parts. Among other things, upcoming are documentation of how to install and configure the connector to the GSA, and walkthroughs explaining how we have configured our GSA to accomplish the goals of the project.

(Kudos to Ed Lachgar, IT extraordinaire at Legal Services of Northern California for writing up these first 16 sections.)

This is a repost of an item I added this morning to the PikaDocs wiki. And it has to do with a very unexpected problem we encountered with the recent Pika 3.06 iteration, which implements code changes that unintentionally strip out IE conditional comments from the Pika default.html template. Needless to say, IE conditional comments are a widely adopted, all-but-standardized way to apply IE-only CSS code to control the design or display of web pages. And LSNC has long relied on custom IE-specific CSS code for its Pika redesign. What were CSS hacks like us to do about this dilemma?

Well, sure enough, those PHP-code ninjas over at Pika Software (Matt, to be specific) had the answer:

Open the pl.php file located in the your Pika subdirectory at /app/lib/pl.php. Carefully comment out lines 2055 and 2056 by preceding them with double-forward slashes so that it looks like this:

// $str = str_replace("<!--[", $tpl_prefix, $str);
// $str = str_replace("]-->", $tpl_suffix, $str);

Save the changes and upload the pl.php file to replace it. Now your IE conditional comments code will play nice with Pika 3.06.

… and since I’m on the topic of web standards, and we all are now living in an IE7 world, let me refer you to Newly Supported CSS Selectors in IE7, a free article at Community MX by CSS czars John Gallant and Holly Bergevin. The article provides a very helpful refresher or re-orientation on the core CSS concepts of selectors and combinators, and how they yield specificity. The big news here is that IE7 now supports child combinators and adjacent-sibling combinators.

Does it matter? Yes it does. For example, here is the Google Analytics browser report for last week at Webdogs 2.0, with its targeted tech-niche audience: Our intrepid visitors overwhelmingly rely on one flavor or another of Firefox or Safari, but only about 13% drive by at the wheel of an IE:

But the web hoi polloi still overwhelmingly use IE. Here’s the same report for the LSNC main website, with IE getting 83%, Firefox 15%, and statistical crumbs to the remainder:

Predictably, there is no end to the carping about how the newly released versions of Firefox 2.0 and Internet Explorer 7.0 compare, a head-to-head battle that editorially Firefox always seems destined to win, and justifiably so.

I share the view that Firefox is the preferable of the two dominant web browsers, and yet as good as Firefox is, it has its quirks. One of them LSNC discovered only when it converted to large numbers of staffers using Firefox after deploying Pika. The problem we encountered was getting search results tables (e.g., a list of cases) to print out correctly. The problem had nothing to do with Pika. The problem turned out to be with our custom print style sheet. The search results tables uniformly printed out as intended in IE, but in Firefox we could only get it to print the first page of the listed results; the second and subsequent pages would print out as blank pages. Yeow! Later, we discovered the problem was not just our custom print style sheet; the printing problems with Firefox also plagued other web locations as well. For example, view this sample U.S. Code page at Cornell and then use print preview in IE and then Firefox. See how the second and third pages just vanish in Firefox?

What to do? Two possible solutions:

As discussed by CSS guru Eric Meyer in When Printing Maims, it may be that your particular page design (as did our heavily redesigned Pika templates) relies on floats for positioning of the “main content” area. In your print style sheet, adding the CSS property {float:none} to the selector that corresponds to the structural element containing the affected text may solve the problem.

In our case, it actually didn’t, but a suggestion further down that same discussion thread hit the nail on the head: Add {display:table-cell} to the CSS for the affected container. For Firefox, this totally solved the problem with printing out our search results tables. And this particular CSS property is a non-issue for IE, since it doesn’t recognize that value.