SIMS 213 Final Report

Problem Statement

Solution Overview

Personas and Scenarios

Final Interface Design Description

Design Evolution

Problem Statement

Legal professionals (law students, paralegals, legal researchers and writers, law librarians, lawyers, judges, and law professors) rely on legal briefs to keep abreast of developments in the law and to prepare new legal briefs for current appeals. A legal brief is a written legal argument submitted to a judge during the appeals process. Law school organizations like The Samuelson Law, Technology and Public Policy Clinic at Boalt Hall ("Samuelson Clinic") and public policy organizations like the Electronic Frontier Foundation and the Media Access Project are writing a significant number of legal briefs representing the public interest in technology law. In addition, a number of individuals and smaller organizations work on only one or two briefs a year. Presently, individuals conducting a comprehensive search for legal briefs relevant to a specific issue must contact many organizations in the technology and public policy community ("TPP Community"). Furthermore, an individual authoring a new legal brief cannot easily distribute this brief to the TPP Community and obtain recognition.

Solution Overview

To simplify the processes of searching and submitting legal briefs within the TPP Community, Tom Selsley and Mary Trombley developed a Microsoft Access database for the Samuelson Clinic. For our SIMS 213 course project, John Fritch and Kaichi Sung joined with Tom and Mary to develop and test a web interface that facilitates the searching, retrieval, and submission of legal briefs. The interface was built in ColdFusion and HTML.

Personas and Scenarios

     Persona 1: Wilma Donahue, frequent user of legal briefs for research

Wilma is a Law Professor at U.C. Hastings College of Law, where she teaches techlaw and runs a student clinic practicing public interest law. She has been a professor for six years, and prefers academic life to her early career practicing Intellectual Property law in Silicon Valley. She stays in constant motion between her office and lecture halls, collaborating with students and her staff of three. Her students know her for being tough but fair. Wilma does not tolerate her collaborators being late to meet her because one late appointment messes up her whole day.

Wilma is 41, and lives in a 1921 bungalow near campus with her architect husband, Michael, and their eight-year-old daughter, Caitlin. Wilma makes every effort to be home by 6 pm to relieve Heidi, the au pair. Wilma zips home in her Audi Allroad she chose for its adjustable ground clearance--higher for extra speed on her neighborhood's famous speed bumps. Wilma often arrives home starving, having forgotten to eat anything more than a green banana and caffe latte.

Wilma travels frequently and uses many different computers between locations. She has had a Lexis-Nexis account since starting law school in 1983. She is a whiz with office applications, particularly using Word for the stringent formatting required for submitting legal documents to courts. She uses Netscape 4.7 on all her computers because it is not a Microsoft product and she is most familiar with it. Wilma relies heavily on her Palm Pilot for her extensive contact information, but her Palm Pilot to will not sync with any of her computers.

Briefs are an everyday part of Wilma’s life. She applies high-level analysis techniques to her research. Given her familiarity with the law, individual cases, and the techlaw community, she can quickly assess the value of a brief by the writer’s name, the quality of the argument, and the quality of the writing.

Wilma belongs to an informal network of techlaw professionals. When she needs a brief, she can often contact the lawyers involved to get the information. She is obligated, then, to forward her own briefs to other researchers. Both requesting and distributing briefs takes valuable time, and Wilma cannot hand off these tasks to her overworked assistant.

Goals:

• Recognition. She is dedicated to her convictions, and would like her ideas recognized and put in practice in the legal system.
• Finding the right legal argument in a document. Wants to make sound legal arguments that sway appellate judges and therefore win cases and set precedents. Wants a robust collection of legal briefs available to her.
• Convenience. She already spends too much time on the phone and unopened Fedex packages of legal briefs stack up on her desk for days.

     Persona 2: Alex Garcia, infrequent legal brief searcher

Alex is a third year law student at Hastings. Originally from Phoenix, Alex earned his undergraduate degree in economics from Arizona State University. At ASU, Alex was an active member of the campus’s chapter of College Republicans and interned for Senator John McCain during his senior year. Following graduation, Alex moved to Los Angeles and worked as a market analyst for a dot com until it ran out of funding.

During his studies at Hastings, Alex realized that the positions advocated by Wilma were consistent with his free market ideology. He has been involved with Wilma’s clinic for the last year. Alex admires Wilma and strives to impress her by producing quality work product in a timely fashion. Two of his clinic projects have required searching for legal briefs. These searches were somewhat frustrating because web services like Nexis-Lexis and WestLaw do not provide legal briefs. Consequently, Alex had to rely on his Internet search skills to find either briefs posted on the websites of the involved parties (or other interested parties) or at least the names of the attorneys for the involved parties. Furthermore, Alex realized that there are often issues with the completeness and/or authenticity of briefs found on web sites. Following such frustrating experiences, Alex heads to the gym and plays raquetball to let off some steam. Considering the self imposed pressure of excelling at the clinic and school, Alex plays a lot of raquetball.

Upon graduation from law school, Alex is going to clerk for a California circuit court judge. He expects this is the first step in his plan of becoming a judge.

Goals:

• Impress Wilma with the quality and timeliness of his work product.
• Minimize the frustration of searching the Internet for legal briefs, even though searching for legal briefs is an infrequent activity.
• When searching for legal briefs, locate briefs that are complete and can be authenticated.

     Scenario 1: Search our collection (Part I)

Wilma instructs Alex to research MPAA v. 2600 and find all the amici briefs for the plaintiff that relate to the MPAA v. 2600 case.

     Scenario 2: Search our collection (Part 2)

Wilma asks Alex to write a brief on a case similar to Eldred v. Ashcroft. She remembers that she found a particularly good brief about Eldred v. Ashcroft at BriefBank several weeks ago, but she doesn't remember its name. The brief discusses whether the D.C. Circuit Court made a mistake when it ruled that Congress has the power to retroactively extend copyrights. Wilma instructs Alex to find that brief.

     Scenario 3: Submit a brief

Wilma has written a brief that recently has received cert from the Supreme Court. Her colleagues have been driving her crazy asking for copies. She decide to send her brief to BriefBank. That way, she can just refer other lawyers to that site when they want a look at her research.

Final Interface Design

     Functionality

Search Functionality

The user can access the search from both the Home page and the Search page. The search interface is simple and allows the user to enter one or two party names as well as choose a specific court, the default being ‘All Courts’. Search returns results based on matches between user input and case metadata. Search does not allow users to search for a specific brief directly, but returns all briefs associated with cases matching the search terms. Detailed metadata is provided to help users in their evalutions of the search results.

If the user enters one party name into either party search fields, that will be used as a keyword for searching the following metadata fields of cases in the database: case title, responding parties, and moving parties. If two party names are entered, matches will result only if both party names are found in at least one of the above fields. We provide redundancy in our search due to the discrepancies in naming of parties in the database (e.g. American Civil Liberties Union might be represented as “ACLU” in the case title but written out full in the moving parties field.) If a user selects a specific court, then that parameter will be used in conjunction with any party search terms as a boolean ‘AND’.

From the search results page, users can either revise their search or conduct a new one. Search results consist of detailed metatdata for each case found and a listing of each brief associated with that case. Each brief name links to the full text of the brief in either pdf or html format.

Browse Functionality

The browse functionality allows users to ‘browse’ all cases in BriefBank by one of three metadata facets: case name, court, or contributor. Browse by Case groups the cases alphabetically by case name. The alphabet list allows users to filter their view by case name and there is also an option to view all. Clicking on a letter will provide a list all all cases by that letter first, as an overview, with the number of briefs in each one as well as links to the specific case on the page where users can see all the metadata. Browse by Court and Contributor provide a similar view without the alphabetical function.

Contribute a Brief Functionality

This provides an interface for users to use if they wish to contribute a brief to BriefBank. We have implemented a gateway page giving an explanation of the brief submission process and listing our Terms & Conditions which potential contributors must read and accept by proactively clicking a checkbox before they may proceed to submitting a brief. The submission page contains fields for entering metadata associated with the case and brief, with required fields clearly marked. Contributors may indicate what personal information they would like to have shown on the website and have the option of staying anonymous. We have also implemented field validation for the required fields. Users are presented with a review page summarizing their input with an option to revise their entries. Lastly, they are required to attach a document containing their brief before submission is confirmed. Submitting generates an email to the webmaster containing all the metadata entries and the attached document.

     Interaction Flow

Site Overview

Search Overview

Browse Overview

Contribute Overview

     Unimplemented Features

• Alternative way to using long list boxes (Courts)
• Sorting by metadata on results page
• Ability to bookmark search results
• Allow multiple courts selection for searches
• Javascript help popups

     Tools used in System Development

Tools for prototyping and implementation

For the lo-fi prototype, we used Adobe Photoshop and Illustrator to create pages for our interface which we then printed out for user testing. During testing, we also utilized Post-Its for quick changes when needed.

For the other prototypes, we implemented our interface using ColdFusion and HTML on top of a Microsoft Access database backend. Javascript was also employed when necessary, especially for form validations. We coded mostly in Dreamweaver and Textpad.

How tools helped and did not help

ColdFusion was helpful in that it provided a lot of needed functionality in the form special tags. For example, it was able to automatically generate its own Javascript on the fly for form validation. It was also very useful for creating complex forms and of course, necessary for generating dynamic pages based on SQL queries. This was especially important for generating our search results based on user input. ColdFusion integrates very well with HTML, but we found that it was difficult sometimes to combine our hand-coded Javascript with existing ColdFusion tags. Dreamweaver is useful because it catches syntax and other errors during coding while Textpad is cleaner and does not mess with the code format like Dreamweaver does.

Design Evolution

     Initial Concepts

Our initial sketches focused on the steps necessary to search for a legal brief and contribute a legal brief. We incorporated these steps into the following conceptual overview:

     Lo-fi Prototype

Our lo-fi prototype consisted of at least one piece of paper for each of the components in our conceptual overview and a test member "playing computer".

     First Interactive Prototype

We developed the first interactive prototype using ColdFusion and HTML and began linking the interface to the Microsoft Access database. Based on the results of our test of the lo-fi prototype, we made the following changes for the first interactive prototype:

• Redesigned the home page to include less text, more prominent navigation links, and a search function. For the lo-fi prototype, the home page consisted primarily of text describing BriefBank and navigational links. Our testers said, the text drew their attention away from the navigation links. The testers also said they expected to be able to search from the home page.
• Redesigned the search function. The lo-fi prototype included a basic search page and a separate advanced search page. The basic search page was confusing because it only included one textfield for a search query and testers could not tell which facets could be used for searching. The advanced search page was less confusing but included too many possible facets. For the first interactive prototype we allowed users to enter a search query using the party, case, or court facets.
• Dropped the Recently Viewed Briefs page because testers did not express any interest in this function.

     Second Interactive Prototype

For the second interactive prototype, we replaced most of the "Wizard of Oz" techniques used in the first interactve prototype. We continued to refine the search function by dropping the case facet as a search query option. We dropped this facet because the case name consists of the names of the parties to the case. However, we increased the case metadata for briefs listed in the search results and browse page.

We made the following changes based on the heuristic evaluation:

• Redesigned the navigation bar to clearly separate navigation links from function buttons. The first interative prototype contained a navigation link titled "Submit a Brief" and a function button titled "Submit". To avoid confusion, the navigation link was renamed "Contribute a Brief".
• Implemented a gateway page for the Contribute a Brief function and indicated the which fields are required when submitting a brief to BriefBank.
• Made "All Courts" the default court selection for the search function.

     Third Interactive Prototype

For the third interactive prototype, we continued to refine the interface. One refinement consisted of changing the display of cases on the Browse by Case page to allow for the anticipated increase in the number of cases. In the second interactive prototype, we provided one list containing all of the cases. For the third interactive prototype, we separated the cases alphabetically and provided a separate list for each letter of the alphabet.

We made the following changes based on the results of the pilot usability study:

• Increased the amount of metadata for each brief listed in the search results page or the browse pages. Our testers said knowing whether a brief was an amicus brief or not and knowing which party a brief supports would make it easier to evaluate briefs.
• Changed the layout for briefs listed in the search results page and the browse pages. The new layout groups briefs according to the additional metadata.
• Increased the visibility of BriefBank's sponsors and contributors ("branding"). We increased the branding by listing the sponsors and key contributors on the home page and elevating the link for the Our Contibutors page to the navigation bar. Our testers said knowing the sponsors and contributors would influence their perception of BriefBank's credibility.

     Usefulness of Evaluation Techniques

We gained valuable insight from all of the evaluation techniques. The heuristic evaluation was important because it pointed out all of the technical issues that we needed to address. Prior to the heuristic evaluation, we were focusing on developing the main functions for the interface. The heuristic evaluation showed us what we needed to address to make the interface work for users that did not already know how to use these functions that way we intended. From the pilot study we learned the importance of elements that are not directly related to the BriefBank's functionality. In particular, we learned that branding will be vital to BriefBank's success.