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.

After the first of the year, we’ll be cranking up as we complete porting of our existing target documents into our new taxonomic organization, resolve some filtering and usability touches we want to integrate into our default GSA front end, primp and polish the layout and presentation of the front end, implement a few basic OneBox modules, and set in motion what we’re now referring to as the “Rolling Thunder Roadshow” to all our eight office locations.

The RTR will be our way to recognize and promote among all our staff the changes in how documents and other files are made easily and intuitively findable, and given a new level of access and usability throughout our non-profit organization. After all, that is the core purpose of enterprise search. And a key element of all this is changing deeply rooted individual notions or assumptions about what can or should be “shareable.”

In working on this project within a non-profit environment, we have learned that most employees have an inclination to undershare, not overshare. Not because they are selfish or secretive; rather, because the type of transparent sharing that enterprise search makes possible is foreign to most of them. It is familiar to them to be asked to provide a document to others on request in person, by phone or by email. It is foreign to them to decide in advance that a document they created or have received from someone else should be transparent to the rest of the entire organization. The concepts of creation and possession are severed from the concept of findability.

To be sure, the increasing use of collaborative web-based document tools within our organization — principally our adoption two years ago of Google Apps — has helped us on this journey. Most staff at this point are familiar with the concept, if not the practice in their individual work, of creating or editing or uploading documents that can be “shared” from a common web location. They get that, even if they don’t do it themselves, because increasingly others demand they do so… when they get a “share” message email from Google Docs about a document someone created or edited there; when they get an email with a link to something someone else posted in our domain’s Google Sites; or when they get a message to fill out a Google Docs form for, well, whatever.

As we prepare for the RTR, the team working on this project have brainstormed about what we can say or demonstrate to the staff in each office, to prompt them to rethink (OK, in some cases just think) what types of documents should be shared with others by adding them to the new document repositories.

We now refer to this as “presumptive shareability.” In particular situations, it may not be appropriate to make the document or file transparent through enterprise search, but in most cases it will be because all are situations where the document or file has served a shareable purpose, i.e, use by more than one person or re-use by one or more persons.

Among the situations we think should trigger staff to think to add the document or file in question to the shared repository are the following:

• An attachment to an email message you send or forward to someone else.
• You request or receive a file as an email attachment from someone within the organization.
• You receive a non-confidential file attachment from someone outside the organization.
• Every time you re-use a document or form as part of your work.
• You learn that the PowerPoint (or other presentation format) for a training or conference event you attended is now available for viewing or downloading.
• You lug home substantive hard-copy handouts distributed from a training or conference.
• Can you say, “presentation” and/or “portable”? Whatever it is, if it is a PDF or PPT file it is presumptively shareable.
• If it is the “final” version of a case-related pleading, memorandum, exhibit or correspondence and you think others may find it usable, share it.
• Usable documents you discover and think to save to your desktop as part of research on the Web, regardless of file type (PDF, DOC, XLS, etc.)
• Similarly, when doing work-related research on the Web, anytime you think to bookmark a web page or save the page to your desktop as an HTML or TXT file.
• … you get the drift.

Shareability promotes findability. That’s our story and we’re stickin’ to it.

Fair to say that without a “search box” there is no enterprise search? That being true, consider Designing The Holy Search Box: Examples And Best Practices, yet another interesting design compilation/distillation article from Smashing Magazine. True, this is not The Big Wroblewski (the form abides, dude), but it’s a pretty good read on what to think about when designing, labeling and positioning a basic search form.

We’ve laid out our take on the theoretical approach to the TFP taxonomy. But in practice, how is LSNC actually implementing those organizational concepts or principles? That is what this post is about.

I’ll just give you the end-product upfront and then explain how LSNC sorted out the basic taxonomic structures for its shared document repository. The two PDF files linked below are copies of what was distributed at a program-wide meeting a few weeks ago to address and resolve what the basic organization structures would look like.

• Download: 29 Top-level Project Directories
• Download: Simplified Project Taxonomy

It was actually quite easy to come up with an initial (if bloated) proposed list of likely substantive advocacy content targets, their location, and how the content would be organized, but even that required process.

LSNC has what it calls a “regional counsel” model, which means there are three designated advocacy leaders with senior substantive, litigation and advocacy experience who are expected to provide just that, “leadership.” (One of the three, by the way, is Mona Tawatao who is the recipient of the 2007 NLADA Reginald Heber Smith award.) The regional counsel, with feedback from other management leadership (including the executive director, a few local office managing attorneys interested in this particular project detail, and the senior office manager representing support staff interests) worked up the list, later vetted more broadly with the entire management team, who in turn vetted it with each of their local offices or other program unit.

In the initial proposal, the substantive advocacy content was organized based on the ten LSC Problem categories in current use by legal services programs, plus roughly an additional 30 or so other general categories. The latter included additional substantive categories (economic development, disaster relief, etc.), practice matters (e.g., federal and state court practice issues, discovery, etc.), and other work-related content (self-help clinic content, specialized training materials, etc.) that reflect what LSNC and other legal services field programs actually do for a living. In response to any number of discussions and comments by the smaller group thrashing the details out, the list at times expanded and contracted, went deeper and then sometimes more shallow. This initial organization structure also included targeted content related to local office and central administrative office work. A similar vetting process was undertaken by the senior office manager with all the other office managers in all the core local offices, as well as administrative and business office managers. As mentioned earlier, each of those, in turn, were asked to vet the structures with their respective staff.

This process did not operate in a project vacuum. As not only one of the three regional counsel but also the person responsible for managing this project, I also did what I think managers should always do: I talk to the people affected. I took the time, a lot of it, to speak directly and individually with all of the forgoing to explain the overall project and its technical demands, and in a non-technical fashion (well, at least I tried) the significance of developing an organizational structure, and other, related issues, such as the use metadata models to attribute value to the targeted content, and so on. The point being, to take the time to assure leadership understood from more than a memo what the project is about, why it matters, and answer their questions or concerns. In response to the vetting and these dialogs, real changes were made in the proposed organization and additional content targets were identified. Time investments paid dividends, at least in this case.

By the time our GSA consultant showed up for a scheduled three-day thrashing of our test-bed installation in Sacramento, we had a taxonomy with over 40 top-level directories and a lot of two- and three-level deep subdirectories. He looked at this, in a non-committal fashion said “that’s fine,” and then began to suggest reasons why it should be simplified. This push by the GSA consultant was prompted by notions of usability and manageability of the content areas. As mentioned in the prior post on project taxonomy, there are not significant advantages or improvements to search results in a repository structure beyond a second-level directory. The consultant also emphasized that most users are not likely to locate or use a directory substructure below the second level. (This has to do with users navigating directory structures to add, remove or modify files, for whatever reason.)

Since a significant portion of the metadata models we are adopting rely on the organization structures in order to build logical, searchable “collections,” we simplified the structures in response to the consultant’s recommendation in this regard. Hence, the 29 top-level directories and the “simplified” taxonomy you can see in the memos linked at the beginning of this post, and the reliance on only one-level deeper for those directories.

As we get life experience with this organization structure, my guess is that we may expand to add a few additional top-level directories but not many, if any. I think we have things pretty much covered at the top-level, at this point. But apart from the rigid yet practical exploitation of the dated — but undeniably familiar — LSC Problem Codes for a large chunk of the substantive organization, my guess also is that the one-level down subdirectory structures will likely change as users give us feedback, and we discover that some subdirectories are not particularly used or useful. Proof’s in the pudding, people.

This all came full circle with our program-wide meeting a few weeks back. By the time of that meeting, every manager within LSNC had seen the organization proposals, every manager had a one-on-one conversation with project staff about the project and the organization structure, every manager had vetted the proposal to his or her people, and the memos you see linked here had been distributed to all offices.

That’s how we roll.

First, a recommendation. Get your hands on a copy of Information Architecture for the World Wide Web (also linked on the right, under “Biblio”) and read chapter 5 about “Organization Systems.”

Why? Well, let me put it to you this way.

We did a lot of homework and scoured a lot of books and, of course, talked to our GSA consultant on what is popularly (if imprecisely) referred to as “taxonomy.” You know, how should we organize all the “stuff” we want our users to be able to find? How hard is that?

As we canvassed widely to get an answer to that basic, practical question, we discovered you can get totally befuddled and sidetracked, not only by any number of levels of abstraction, for example, should you choose to wallow in construction of controlled vocabularies; but also by all too “inside-baseball” discussions by the taxonomy community; or, by yielding to the dark side and joining a formal organization for this sort of thing. Of course, there is also the emerging school of “social organization” of content referred to as folksonomy, more popularly known as tagging. And then there is the school of thought within some sectors of the search community that, after all is said and done, taxonomy may not be particularly useful for enterprise search design.

Needless to say, these initial forays into this subject prompted the thought bubble … “Just shoot me now.”

On this point, the GSA consultant was not as directly helpful as I thought he would be. The short story is that he was supportive of what we thought we needed, but at the end of the day he was essentially agnostic on this point, a view that mirrors Google’s online GSA resources. In discussing how to plan for a GSA implementation, Google says not much more on this point other than “analyze your business’s content and decide which directories and files you want indexed.” (In fairness to our GSA consultant — whose name, by the way, is Igor — you should be sure to read below, for his helpful guidance on simplifying the taxonomy we adopted, and the reasons for doing so.)

Which begs the question, how should we do that?

There are online articles that are straightforward and helpful in grasping, at a rudimentary level, the basics of information architecture, one recent example being Better Living Through Taxonomies, at Digital Web Magazine. But based on our experience, I recommend you pass Go and head straight for Peter Morville and Louis Rosenfeld’s Information Architecture for the World Wide Web, a book that is part of the IA canon, and deservedly so. It is a superbly clear-headed, well written overview of what information architecture is all about, and Chapter 5 on organization systems, specifically, is a model of how to explain a technical and complex subject like “taxonomy,” among other things, in plain, accessible language. And it will hit the mark on the main issues you need to think through to get “stuff” organized.

What are those practical issues? Indulge me a bit, since several of my observations here simply echo what I am recommending you read, but for LSNC we distilled our theoretical approach to taxonomy or organizing our content to these four basic precepts:

1. The directory structures need to be a hierarchical or “top-down” organization of simplified, familiar categories.

In the broadest sense of “organizing” things on a file server, and how that same “organization” is reflected in page menus or page navigation or dialog boxes, users need to know where they are and what the folders or subfolders mean. Lawyers, by training and practice, work in an especially pronounced hierarchical environment. (Can you say, “I, II-A, etc.”) While the work environments of legal services programs are famously “anti-hierarchal,” the practical truth is that almost everyone in that environment organizes their work in some hierarchical fashion. (Certainly, there are exceptions.) Simply put, this is the most common way in which most people organize things, lawyers and non-lawyers alike.

2. Names for content folders, subfolders or categories need to be consistent with the shared vocabulary of your organization.

This may seem self-evident, but in practice may not be what users in your program do or are accustomed to. I actually took the time to look at the folder organization of about a dozen advocates in our Sacramento Office, and while there were predictable folder organizations (for example, organizing files by case or project or substantive area), much of the naming was ambiguous. While no doubt obvious to the advocate who created the directory or subdirectories, to others the same structure or organization may be too subjective, ambiguous or confusing to be useful to anyone other than the person who created it — and even possibly for him or her at some later time, when the subjective rationale for the organization has been long forgotten. So, when working out the naming conventions for folders and subfolders, it was important to focus on commonly understood, familiar shared vocabulary or terminology.

From the perspective of the GSA, the particular names, as such, of directory folders or subfolders is of no consequence. The GSA does not care what you call things, which explains the agnosticism of Google and our GSA consultant on this point. At the blunt-instrument level, all it cares about is the URL, the path to where the content resides. You deal with the Tower of Babel; that’s your problem. The GSA will ferret out the content wherever it resides, regardless.

To be detailed in the next post on this subject, LSNC has adopted the most conventional names for its directories it could come up with, including … I pause, for the pain it causes me to say this … the LSC substantive problem code categories, which comprise roughly half of the directories on our shared document repository. If one were organizing legal services practice today, I am confident it would be organized differently than how LSC organizes it. But roughly 40 years in, LSC still uses an extraordinarily unsubtle and somewhat uninformed organization of legal services practice. But it is what it is, and it is what field programs must use, and it is what users within those organizations know and understand, after decades of use. For better or worse, it is the “shared vocabulary” of our organization, and its use offers consistency with how other information and data is handled, most notably client case data.

3. “Lean toward a broad-and-shallow rather than narrow-and-deep hierarchy.”

That’s a quote from Morville’s book. And his observation is consistent with the advice our GSA consultant gave us. The consultant’s advice was not to go more than two levels down, and really pushed for only one level down. The rationale was two-fold: The more subfolders you have, the less likely users will locate or use content in those folders whenever they are navigating the directory structure, in whatever form it is viewed. From the user side, a deeper vertical hierarchy actually reduces findability.

From the GSA side, deeper hierarchy does little or nothing to improve search results. While the search algorithms baked into the GSA exploit the URL path at the directory and subdirectory and sub-sub-directory to improve search results, having third or fourth or more levels does essentially nothing to improve those results. There’s no harm to doing so. It just doesn’t help you.

A counterpart to this issue is the importance of striking a balance. By going broad-and-shallow, one gets the practical advantage of being able to add content without the need for major restructuring. Assuming you have figured out a set of top-level directories that pretty much covers, in a broad sense, the content your users will want and need to search for, from there on out you can focus on adding content below that level, as warranted.

But if you go too broad, from the user side, things get more cumbersome and impractical. Think about it. Whether your users are advocates or office managers or volunteers, whatever, it is going to be more practical and useful if they can visually and cognitively grok the organization scheme. So it needs to be broad enough to cover the bases, but not so broad that it becomes incomprehensible.

Sure, we could have gone totally nuts with the taxonomy and, say, adopted the thousands-of-points-of-substantive-light offered by the well intentioned but ill fated National Subject Matter Index. (Don’t get me started.) We’re more practical. As detailed in the next article, LSNC is going with a simplified 29 top-level directory structure, and each only going one-level deeper. Works for the users. And works for the GSA.

4. It’s not all about taxonomy.

Having a basic, practical, commonly shared taxonomy or organization structure is essential to a project like this. LSNC content needs to be located somewhere to be targeted by the GSA, and those who add or contribute or remove that content need to be able to comprehend what is where. The practical side of what that all means will make more sense in later articles about the document protocols we have come up for LSNC users to locate and add content and how to add metadata to that content.

But having a traditional taxonomy is not the whole picture. There are other types of content you may want to target that don’t fit the taxonomic model: targeted database content (case management systems come to mind, but are not the only example); external site content (such as select public website content to which your organization has access or permission); and alternate content sites that you would want to target but over which you don’t have the same level of control (a current example would be domain-hosted Google Sites, a subset of Google Apps, which you can “organize” in a superficial way but which at the level that matters to the Google Search Appliance, not so much).

What this means for LSNC is that we are targeting the GSA at more than just a nominal taxonomy on our shared document repository.