Arguably the most common, if not first, Google Search Appliance (GSA) OneBox module that organizations implement is a module that returns personnel information or listings of some kind. It is one of the most obviously useful OneBox results one can come up with. As we ramped up to implement our version of it, we were surprised to discover that most publicly available examples or models for creation of OneBox modules rely on technologies (ASP and Java being among the most prevalent) that we do not use. We could not find an example of such a OneBox using simple PHP/MySQL.

Our goal was to build an easily replicable OneBox module that does work with PHP, which we do use. A lot. PHP is at the heart of the Pika CMS as well as our public websites built on WordPress.

Here’s an example of what our OneBox special query result looks like, with the first keyword “staff” being the trigger and the second keyword “ukiah”, the name of one of our local office locations. The query returns a OneBox result listing all the active staff in that office:

Clicking on the link for each person’s name triggers a new display with a photo of the person and his or her vitals. This module also works using the same initial trigger with a staff person’s particular name.

Most simply put, this OneBox module works by querying the MySQL database “users” table in the Pika CMS, the application used by all our active employees, across all positions, to record their time and work activity. More specifically, the module breaks down into five basic steps:

• the OneBox module sends a query to a targeted PHP file
• the PHP code runs a query against the targeted MySQL database
• the PHP code then outputs the returned data as XML
• the GSA reads that XML output
• the GSA then formats that output for display as a search result

Within the GSA console, one creates a module by selecting OneBox Modules > Create Module Definition, selecting the Trigger (in our case, “staff’), and then identifying the Provider, which in this example is the PHP file we created and attached to the module as an External Provider, by inserting the URL to the PHP file.

You can download as a ZIP file the PHP code and related GSA stylesheet template used in this example.

The PHP file is annotated, but has select information edited or removed (host, passwords, etc.), for obvious reasons. Looking at the PHP code, in sequence the PHP submits the query, connects to the database, joins data from a combination of data tables in our case management system, then takes the results from the MySQL query and outputs it as XML, i.e., the “OneBoxResults” in the code.

Once the GSA outputs the query results as XML, it can then publish the results to a OneBox Stylesheet Template, which one can edit by clicking on the Edit XSL link at the bottom of the console page for the particular module.

Since we’re on the subject of revisions and updates today, here’s another about how we finalized our Google Sites content.

As noted earlier, The Findability Project planned integration of select Google Sites content as a GSA target. How we created LSNC’s “official” intranet site with Google Sites was covered (briefly) as part of a recent NTAP presentation.

Since that presentation, we have pretty much completed the migration of all our intranet content over to what LSNC calls its “Secured Private Network” (SPN). For those curious, here is a screenshot of the current site’s home page; and here’s a screenshot of the top levels of the sitemap. As you can see, we have worked to keep the hierarchy simple which means manageable, especially given the number of different folks who have responsibility to maintain its content. Also, we have created a large number of Google Sites file cabinet “upload” pages to make management of those file easier, for the same reasons. So far, so good.

What is great about all this is that the GSA easily targets this selected Google Site, and returns great results from the site. Users can have it both ways, by searching from the GSA frontend but with equal ease from the native search function within the Google Site itself. It’s all good.

We’ve made minor revisions to the project’s structural taxonomy described earlier. With only slight changes in wording, we’ve retained the same basic 29 top-level project directories but we have more significantly, although not dramatically, revised the second-level subdirectories so that they conform a bit better to how most of our advocates organize and think of substantive categories in our line of work. Here they are:

• Download: 29 Top-level Project Directories (revised May 11, 2009)
• Download: Simplified Structural Taxonomy (revised May 11, 2009)

To recap, our original thinking was to keep the structural taxonomy sufficiently broad (horizontal), to be reasonably inclusive of the content categorizations in common use by a legal services program, and purposefully shallow in depth (vertical), to offer modest granulation so as to keep the structural organization and navigation simple and practical.

We struck a balance between using all ten of the very familiar LSC legal problem categories as top-level directory names, and adding additional categories to address obvious gaps. The ten LSC legal categorizations are definitely part of the shared, commonly understood “vocabulary” of the organization. But we added another 19 top-level directories that are consistent with the broader range of topics and tasks at play in our work environment. For example, we have “Housing,” yes, but LSNC does a huge amount of work in “Land Use” and related issues (e.g., housing element, inclusionary zoning, etc.), so we added that category and related sub-categories to the structure. (The existing LSC “Other Housing” subcategory just doesn’t cut it. Land use is not a catch-all category for us, if you get the drift.)

There are several categories in this revised structural taxonomy that reflect this shift in our thinking. A good example is under the LSC “Income Maintenance” category, where we retained the basic LSC sub-categories but added new ones for “Child Care,” “General Assistance” and “Refugee Cash Assistance.” We also tweaked the wording of many of the sub-categories to correspond more accurately to how users here refer to things, for example, by changing “Unemployment Compensation” to “Unemployment Insurance.” Another example is where we retained the LSC category for “Individual Rights,” but concluded that the LSC sub-categories are somewhat muddled, so we created a different if still simple subset. We also dropped some of the LSC sub-categories that have little or no anticipated use. (Really, you do a lot of “name changes” in your program?) We then simplified the directory and subdirectory names by eliminating the redundant references to “LSC Code,” eliminated the LSC problem code numbers, and dropped the cumbersome “Not_*” labeling also used with some LSC problem code names.

Basic housecleaning stuff.

At the outset, let it be acknowledged that SharePoint is a great product. For good reason, many in the legal services community have either adopted or are at least seriously looking at SharePoint as a core component of their network infrastructure. A notable example of this trend from earlier this year is Tom Winter’s video collection of SharePoint Resources for Legal Aid. Impressive.

That said, observant followers of this project may have noticed our chronic inattention, and now outright de-emphasis of SharePoint. There’s a reason. Actually, several reasons.

When we submitted our TIG proposal in 2007, we proposed SharePoint as a key component of the technical specifications for this project. Once we received the grant in 2008, that is exactly how we proceeded as we put together our so-called blunt-instrument build. At the time, we put in place an open-source Google SharePoint connector that plays nicely with the Google Search Appliance (GSA). (We have documented how we configured the SharePoint side of things; we will eventually document how the Google connector configurations work.)

From the get-go we recognized the basic promise of SharePoint, i.e., it offers an array of enterprise platform options for creating and maintaining organizational portals and managing content. All stuff we wanted as we built out our project, moved toward positioning our content in very purposeful ways, and worked out optimal ways for our organization to communicate, share and find content. True, we were less sanguine about SharePoint’s enterprise search features. Not because it is not effective. It is. But we had greater confidence in the algorithms and effectiveness of Google enterprise search, which natively works with most everything Google, and SharePoint does not. But we will put that tribal view aside, for the moment. We give SharePoint its due: Impressive.

That was late 2007, early 2008. This is now, a little more than a year later. What happened in the interim? Google Apps happened … way more, way better Google Apps including an increasingly impressive array of collaboration features … including domain Google Sites … integration of Google Analytics into Google Apps … and then at the end of 2008 some serious happy with the version 5.2 update for the Google Search Appliance, which now integrates with Google Apps, including Google Sites.

Way impressive.

Even though we had SharePoint in place and could have built out our intranet using it, we all but immediately and instinctively moved on to Google Sites once it became available to us in 2008 and, in short order, built things out that way. (See Google Apps Redux for more about how LSNC currently uses Google Apps, including Google Sites.) It is not that SharePoint is not useful to accomplish many of the same things. It is. But at what cost and at what loss in usability?

For a modestly sized non-profit like ours (about 170 employees and two actual IT staff, not wannabees), the Google Apps platform has proven to be a phenomenal, secure, essentially zero-cost, zero-maintenance way to have access to pretty much all the basic collaborative and communication technologies now deemed baselines for the legal services community. (Oh, yeah, the baselines happened in 2008, also.)

And all this stuff works very nicely with the Google Search Appliance. SharePoint, not so much.

We’ve created a Jing video illustrating what a live search looks like at our project test portal. The video includes a demo of how file type and special collection filters work, as well a Google OneBox we’ve added to search for program staff by name or office.

In an earlier post a few weeks back we updated our list of class and id selectors generated in GSA search results markup when using the Google Code open source GSA XHTML stylesheet. What we hadn’t noticed before at that Google Code site was a subpage with the nine different corresponding stylesheets used to style the display examples at the project site. You can download them for use as examples of how to do CSS coding of screen, print and handheld media. These optional CSS files include some for targeting style presentation of GSA search results in IE and IE7.

Hidden in plain sight, and akin to what we did with our list, the Google Code site also provides an annotated list all the Classes and IDs generated by the open source GSA XHTML stylesheet. It is organized differently than ours, which is organized by the three principal vertical areas of a search result page, while the Google Code annotated list is organized by “XSL template/description.” The Google Code annotated list also would need curly brackets added to each selector before use as an actual CSS file, but it is exhaustively comprehensive, which ours is not.