As lawyers, the vast majority of us build WORD-TYPE THINGS, such as coverage opinions, complaints, contracts, manuals, forms, discovery questions, objections, arguments, warning labels, EULAs, and on and on. To build all of these objects we have to research (and re-research) and write (and rewrite), a process that can be quite maddening when you’re staring down a deadline. The nature of this process demands a significant amount of reuse as well, which is why so many of us keep our past WORD-TYPE THINGS and research digitally, organized by client-matter, searchable by type of content (KM, CMS, and on), and why we demand the ability to cut and paste. We hate reinventing the wheel, just hate it. And although the final product we make may not be considered a “widget,” it is designed for a specific purpose and constructed to meet a consumer’s needs. I say building is in our blood, whether we acknowledge it or not. All of which leads me to this post.
In the first post on this topic, I suggested we need to change our frame of reference—search for a new metaphor—for legal research by asking a different question: What do you want to do with the law today? I suggested that by making this change, we could extricate ourselves from the library metaphor and start thinking about how modern legal research could be (THINK: already is being) conducted. Rather than searching up and down aisles of cases, statutes, codes, rules, ordinances, administrative orders, and the like, we could approach the problem of legal research as if we were building with LEGOs*.
I have often argued in my business that writing a law book is much like writing software (or maybe the other way around), which is something I know nothing about (writing code that is). But when my programmers say why a particular project is delayed, the reasons sound remarkably similar (READ: exactly like) to the ones given by my development editors about a forthcoming title. Along these lines then, I found it interesting that around the same time Ethan Katsh was nailing down his thoughts on the library metaphor and the future of legal research, IBM published an article about the shortcomings of the library metaphor and computer software development. See Griss, Software reuse: From library to factory, 32 IBM Sys. J. 548 (1993). To be clear, the problems of software development identified in the paper are not kin to those of online legal research, but I think one of the solutions suggested could at least make them step-sibilings:
The LEGO metaphor has been used by many authors to suggest parts that fit together and (subliminally) exhibit ease of use. Over the years, the LEGO Systems blocks have evolved from a small variety of simple generic parts, to a rich family of kits, composed of a mix of generic and specific parts. Different LEGO kits build spacecraft, farms, castles, and other “domains.” Each system comes in carefully-packaged boxes, illustrating the range of related models the kit can build. The boxes are marked with the user “maturity” level for which the kit is most appropriate. Detailed instructions included with the kit specify the process to be followed in using the kit. Application notes are available to indicate how several kits may be combined to build even more complex applications. Some of the series also come with “domain-specific” frameworks (e.g., the space platform, or landing fields).
While the above example seems perhaps whimsical, it illustrates our view that a “kit” should contain well-designed and packaged compatible reusable work products, tools, and processes to assist in providing more “complete” solutions for application developers. Good kits will substantially reduce the software construction costs and improve the quality, functionality, and interoperability of software in a particular domain.
Griss, Software reuse, 32 IBM Sys. J. at 558. As LEGOs are familiar to us all, we are reminded that kits are comprised principally of colored building blocks and specialized pieces. The instructions included in these kits are “picture books,” containing almost no text explaining the process for assembling the pieces. Dead simple.
As I turned the LEGO metaphor over in my mind, I kept asking myself how does this work as a conceptual hook? And for that, I considered how the metaphor might relate to the law.
So, what is a legal research brick? I think it can be any component that is part of answering the question of what you want to do. In other words, it can be case law, statutes, codes, rules, agency and administrative decisions, orders, or rulings, city ordinances or charters, uniform laws, secondary resources, forms, jury instructions, damage awards, briefs, blog analysis, video, and on. If we take up Katsh’s suggestion and start thinking about the space we’re operating in, the bricks are potentially limitless.
And what about colors, what do they mean? A specific color represents each different kind of brick (e.g., cases, statutes, etc.).
Does the size, shape, or length of a brick mean anything? Perhaps, as a means of understanding the type and size of the data set you’re playing around with and universality of the piece. For example, specifically shaped pieces may only work with certain kits (e.g., cases work with nearly all kits, but IRS private letter rulings only work with tax and estate planning kits).
What in the world is a legal research kit? A kit, as I think of it, is the broader subject-matter you’re working within. On the litigation side, if it’s a summary judgment you’re working on, then the kit includes all the principle bricks for answering your question related to that subject matter. If it’s a contractual provision, the kit gives you the appropriate pieces for that as well. Kits can be both conceptually large and small and highly specialized (e.g., a kit for summary judgment in a California medical malpractice case involving a failure to diagnose cancer).
And how do the idea of domains fit? The domain (i.e., the platform on which the kit is assembled) is your location. Not just state, but city and county as well. So the contents of the kit can change depending on the user.
Now, some of you are probably thinking, “So BFD? The LEGO metaphor is basically what we’re doing now.” But it isn’t, and let me explain what I’m thinking.
By conceptualizing the various components to legal research as colored bricks, we can now change the way we might interact with them (and the system) because we are thinking about building, not browsing. Some initial thoughts I’ve had are these:
- A user dashboard. The dashboard displays the contents of the kit so you immediately see the number and kinds of pieces you can assemble. It’s the default view after you indicated what you want to do. It’s fully customizable, and you can change your domain (i.e., location) at any time.
- The publisher is now a “legal research factory” and is responsible for constructing the pieces and ensuring they work together and providing the framework for utilizing, refining, and building kits.
- The pieces are interactive. When a blue brick (e.g., case results) is stacked on a red brick (e.g., codes) the information actually builds a new structure. So when you take a closer look at it, blue bricks and red bricks are mixed in to form a structure representative of the data, in this case, a ladder. Practically speaking, when you are reading a case, the statutory text is embedded and accessible by long touches or some other input to allow you to call it up for greater context. But importantly, when other bricks play a role in understanding the information, you get instructions showing that there are other pieces needed to complete this portion of the kit. For example, when you call up the statutory text, you might see an instruction to add a yellow brick for important legislative history, or a green brick for expert commentary, all of which builds on a particular paragraph in a case. Everything is brought to you as part of the building process, rather than you having to move up and down an aisle searching for the right pieces. Of course, if you just want to play with the blue brick, you can do that as well. But it isn’t as fun.
- The kit will default to “today,” meaning it’s not going to offer pieces the factory determines won’t help you answer the question. If you want those pieces, then you’ll have to ask for them (“give me a kit for today and 1992″). The factory is concerned about optimization of your time, so older bricks are out. Think about current LEGO kits. The focus every quarter is on the latest model, not the past ones.
- You can share designs. If you build a structure, you should be able to share that design with others. Now imagine this: what if you got an in-system credit for having a popular design? The more people that used your design, the more “store credit” you get, which could be applied to buying more bricks or as a discount on your monthly fee. The idea here is that you are saving other people time. The store’s home page could even have a ranking for most popular designs, encouraging others to build even better ones (READ: spend more time and money on the system ← that’s for factories BTW).
- Other people (READ: third party developers) can make new bricks for your system. When I think of the LEGO metaphor, I’m envisioning it as an ecosystem that allows others to imagine new structures you can build with the bricks. They write text-free instructions that allow you to create new things with the bricks or actually add to the bricks by bringing in other shapes (i.e., data). Think of it as iPhone OSesque: part operating system, part data. And if it has a revenue sharing plan, developers are incentivized to create new and (hopefully) useful pieces (← this is another one for factories).
These are just a few ideas. But I like the notion of moving beyond stacks and imaging data as something we build. I also like the idea that the metaphor is device neutral. It doesn’t require us to believe the iPad or some other mystery multi-touch mobile device will be the change agent. It only requires us to think about what it was like as a kid, turning these hard, colored objects around in our hands, thinking about what great thing we can build. And it reflects what we knew all along, namely, that we are not only architects, but builders as well.
Let me know what you think.
*LEGO® is a trademark of the LEGO Group of companies which does not sponsor, authorize or endorse this site.
[Image (CC) by Dolinksi]
You must log in to post a comment.