We’re now officially into the dog days of Summer in Sacramento, and there are way too many other fish to fry. Stay cool until the bounce back this Fall.

It was a pretty nice surprise for LSNC several months back to be asked by Google to present Advancing Knowledge Sharing with Google: The LSNC Story, with its focus on what we accomplished with The Findability Project.

Prior to but independent of that webinar, Google interviewed LSNC about The Findability Project and LSNC’s larger experience of integrating a Google Search Appliance with Google Apps and the Pika case management system. At its Google Enterprise customer solutions site, Google currently features and has posted its LSNC case study. Sure, it’s a marketing stroke but, still, it’s great to be included.

LSNC published its technoloy plan here last year when it first became an LSC grant requirement. LSNC’s latest iteration, submitted with its recent grant renewal application, is the LSNC 2011 Technology Plan, posted here as a viewable Google document.

The 2011 plan will read familiar to those who saw last year’s plan. It is essentially an updated version of that plan, and like it parallels the 12-part structure of the LSC baseline technology guidelines commonly used by Legal Services field programs to assess their overall technology needs and implementations.

Since last year’s plan, LSNC’s tech vibe focused very heavily on two major infrastructure elements: First, We cracked the code on integration of our Google Search Appliance with our Pika case management system, something we accomplished a few months back. (LSNC now targets and indexes 800,000+ Pika activity records with its GSA, and we have plans to ramp up our database targeting even further, in that regard.) Second, LSNC also evaluated and deployed a new telephone system, a process which still involves work on our end but is near completion. We never quite got around to the other five major “special attention” elements identified in last year’s plan, but you can see what those are and how they are stated in the new plan.

As the classic listserv valediction would say, HTH.

The Art Institute of Sacramento recently, and graciously, produced a pro bono, professional-quality PSA for LSNC. Kudos to Joey Gonzalez, the student assigned to the project, who provided the creative drive behind the result. And for the record, that is real-life LSNC staff attorney Steliana Schmidel of our Sacramento office who allowed herself to be royally baked under hot lights for most of a Saturday to help get the project done. Bravissimo! The video is hosted on YouTube at http://www.youtube.com/watch?v=ia5OJygzxaM.

Early last year I mentioned the Arc90 Readability bookmarklet and why I liked it. Since then the developer has released the Readability add-on for Firefox, which I find inordinately useful and practical. (There is a Chrome variation called Readability Redux, based on the Arc90 code but created by a different developer.)

The Readability extension does a simple thing I need literally every day, i.e., it makes single posts superbly more readable and printable. It is that simple. For any article on the Web I have a serious interest in reading, rather than just scanning, then I want what Readability does for me: With one click, I have the article stripped of all that is extraneous, set typographically for ease of reading with an optimal font family, font size, content width and comfortable leading, and I can also print it out should that suit me.

To see how well this works, take a raw gander at this article today by Gail Collins and David Brooks of the New York Times: Where Did All the Angry Voters Go? Sure, it’s readable enough. If you are OK with the altogether small font and old school newspaper-y column width, not to mention all the other clutter and advertisements on the page. Then install the Readability add-on and view the same page again. As my ophthalmologist always asks me, “Better one or better two?”

But wait, there are even more options! Try The Printliminator bookmarklet, available at the extraordinary CSS-Tricks. I don’t think you can beat the overall ease of use one gets from the Readability add-on, but The Printliminator gives you a further edge: You can first view the article via Readability, and then trigger The Printliminator to remove all the images or photos in the article, to strip everything down even further. Again, “Better one (using Readability) or better two (using Readability + The Printliminator)?”

You decide.

The context: Over the month of June, LSNC is evaluating whether to move from the old school version of Westlaw to the more “Google-y” WestlawNext. We’re only a few days in, so I have not even gotten to the point of soliciting feedback from the multiple testers across the different offices. But this morning I got this message from one of them: “I’m sure you intended for me to work with this new Westlaw interface longer before providing feedback, but I can tell you already that it is significantly better than ordinary Westlaw for me. Searches are much easier, it is very simple to change the viewing options for a case (hiding West Headnotes) and it seems much faster. I’ll tell you more later, but so far I think it’s great. Please tell me we’ll be able to keep it.”

Actually I can’t say that since we don’t yet know what it will cost us to make a change. But this is an early sign that Westlaw’s modernization of its search algorithms, rethinking of the user interface, and recognition that legal (re)search paradigms have shifted significantly, are paying off at some basic level. This may be just a first-date crush, but I suspect a longer engagement is in the offing.

HTML5, the emerging successor to HTML and XHTML, has in one form or another been an under-development web specification since 2004. But it wasn’t until 2009 that HTML5 began to break through as something that would really happen. Two prominent examples from last year that HTML5 would be part of our web future: The news last May from Google I/O 2009 that Google is betting big time on HTML5; and Jeffrey Zeldman’s influential pronouncement that HTML5 deserves your love. (Loyalty oath, optional; specification details to be worked out.) At this year’s Google I/O 2010 the Google crush on HTML5 was apparently on full display.

Want more proof? Last year you couldn’t drop a dime to find a book about HTML5. Now at Amazon you will find 10+ books about HTML5, most of which are still in publication pre-order status. And coming next month is the one HTML5 title I know I must have: HTML for Web Designers by Jeremy Keith, only available directly from the publisher A Book Apart. (Jeremy Keith is the author of DOM Scripting: Web Design with JavaScript and the Document Object Model, which I have read and do recommend. The guy is a really great, first-tier tech writer.)

Which leads me to what actually prompted me to write this post in the first place: Among the newest of podcasts I now consider a must-listen is Zeldman’s The Big Web Show. The second show in this weekly podcast was the hour-long HTML5 with Jeremy Keith. Call me a nerd, call me a geek, call me irresponsible, but it is the only podcast I have ever listened to twice. It was that good.

What now seems like eons ago, and well before “Google Apps” even existed, LSNC relied on Yahoo! Groups for its first foray into email discussion lists. That relationship did not last long. In early 2006, LSNC made its first institutional move toward the Google-centric work style with adoption of Google Groups. The initial cluster of LSNC Google Groups included substantive discussion groups for housing, welfare, health and education, plus two announcement-type lists, one for all advocates and the other for all employees. We started with an opt-out approach for users, with the only exception being what we still call the “LSNC All” list, which was mandatory because of the importance of getting certain types of messages to everyone in the organization. At that stage LSNC still maintained its own mail server and spam was a growing problem.

Then later in 2006 came the standard edition of Google Apps, followed by more specificly marketed premium, business and education editions, as well as the non-profit edition adopted by LSNC. All editions offered the promise of practical integration of a basic complement of web applications: Gmail, Google Calendar and Google Docs. For LSNC the biggest initial advantage we saw with the Google Apps platform was the promise of Gmail on two counts: First, we could offer all staff universally web-accessible email; and second, based on the experiences of several staff who had long relied on their personal Gmail accounts, we were confident that Gmail’s preternatural ability to deal with email spam would solve that problem for us. It did. The switch over to Gmail also relieved LSNC of the need to maintain a mail server, much less all the security and spam filtering requirements that went with it. The larger institutional transition to Gmail was all but instantaneous and overall pretty painless. Google Calendar and Google Docs were actively promoted within LSNC, yet user transition toward those apps was slower, if steady. Use of Google Calendar within its first year of adoption became the norm and then eventually became an institutional requirement for all shared calendaring, such as local office and program-wide calendaring. It is now required for all individual calendaring within the organization.

But I digress. Back to Google Groups. Eventually LSNC made membership in most organizational discussion groups mandatory. For example, all advocates are required to be part of all LSNC substantive discussion groups, all office managers must be part of the special discussion groups created for office administrative matters and the separate list on technology issues, and so on.

Google Apps marches on! Last December Google Apps added Google Groups, and LSNC is just now laying its plans to transition users from the consumer version of Google Groups we have relied on for years, to this newer Google Apps corporate version. Broadly speaking, the Google Apps version of Google Groups looks and behaves pretty much like the other version. There are no real surprises in terms of user design here. But there are several significant differences below the surface, most of which relate to how Google Groups is intended to integrate with the larger Google Apps platform, as opposed to being a free-standing web app like the consumer version.

Three biggies come to mind:

1. Google Apps Google Group makes it enormously easier to manage multiple groups than does the consumer version. How so? Let’s say you want to create a discussion group or an announcement list for everyone within your organization. With Google Apps Google Groups you don’t have to do that manually. All you have to do is check a box to add all users within your domain. OK, say you have multiple substantive advocacy groups, like the ones described above. Within your domain you can now add or nest one discussion group membership list within another. For example, LSNC is creating one “master” list for all advocates, and that is the control point for assuring the membership list is correct and current. Then for other advocate-related lists, all we need to do is add the master advocate group address to the members list of the housing group or welfare group, and so on, with no need to update those membership lists because they are just nested versions of the advocate master list.

2. We’re talking user-managed groups now. If enabled this feature not only allows your users to create their own groups for discussion but perhaps just for ease of Gmail message distribution among a self-selected group of users. But it also does another important thing: It enables the owner of the group created to permit persons from outside the domain to participate in the group. For example, within LSNC there are small clusters of staffers who for organizational reasons use an entirely different domain for their Gmail. No problema. They can be added individually and directly to any of our domain’s Google Groups using this feature.

3. Finally, there is the Google Apps integration thing. The interface for the consumer version of Google Groups has sections for group “Pages” and uploaded “Files.” But you won’t find those in the corporate version of Google Groups. What’s with that? Well, if you need to create pages or upload files, then you need to do that with Google Docs and/or Google Sites and do a share to the group. I’m not saying that’s optimal. I’m saying that is the reality.

And as of this writing, there is a long unresolved bug in the corporate version of Google Groups affecting file attachments to email messages sent to the group. Yes, you can attach a file to an email message and it will appear linked within the group site. But, inexplicably, the content of any group message that has a file attachment does not get indexed and therefore is not searchable from within the group site. (File attachments themselves have never been searchable within any version of Google Groups. In contrast, files uploaded to Google Sites are.)

Then again, maybe that problem will get resolved once Google Apps implements unified search, which would be total Aces.

Next week Google is sponsoring Advancing Knowledge Sharing with Google: The LSNC Story, a live webcast focusing on LSNC’s Google-based enterprise solution, a k a The Findability Project, an LSC TIG-funded project. This will be familiar territory for those who have followed LSNC’s adoption of the Google Apps platform and its implementation of an enterprise-level Google Search Appliance.

Hey, it’s not Pride of the Yankees, but we’re honestly flattered to get the call from the mothership.

For those who have followed The Findability Project, I am pleased to report we have surmounted the basic technical problems of targeting our Pika CMS with the Google Search Appliance.

The back story is one I have purposefully repeated whenever giving a presentation about the project, namely, that our Pika Plan A did not work. We encountered code anomalies in Pika that, among other things, cause it to auto-generate new case intakes and case records when it is crawled by the GSA. As a result, we were unable to use the GSA to crawl the Pika client case content dynamically generated as web pages. Plan A would have been the easiest, no-brainer way to go but we were not able to do so. So Plan B was to have the GSA target the Pika MySQL database directly. Status report: Mission accomplished.

There are GSA capacity issues for us, since our particular GSA’s one million “record” capacity means one million web pages or database records, inclusive, and these database records are not the same thing as the count for client case records. At any given time, we may have some 130,000 to nearly 200,000 client cases in our Pika system (and even more in archival data storage), but from a database perspective, these add up to multi-millions of “records,” e.g., various types of time records, case notes, contacts, and so on. Part of the challenge for us was to sort out which pieces of those millions of database records were the ones most needed and useful to our users.

The solution? Using a well-tailored query, we have the GSA do a selective crawl of the Pika MySQL database to return the most commonly sought and used Pika content: Case numbers, client names, office designations and case notes… tons of case notes. The basic technical explanation is the GSA performs a database query, returns it as an XML feed, indexes that feed, against which the user’s search terms are queried and ultimately returned as viewable HTML

What does the the search result look like? A Google search result. The clickable link displays the case number, client name, LSNC office and primary advocate name, e.g., “90-10-123456 ~ John Client ~ Sacramento ~ Jane Advocate.” Below that it displays in-context text with the search terms highlighted in bold, essentially like a regular Google search result. Clicking the link dynamically displays the actual Pika case note shown in context. Assuming there are multiple possible matches for a particular Pika case record, there is a link to display all the “omitted results,” akin to how regular Google searches work, so the users can see all possible, not just probable matches. Clicking through the GSA search result link also gives the user direct clickable access to the particular client case record since clicking through takes the user to the actual Pika client case record.

That’s the name of that tune.