Law firms, by the nature of legal work and court requirements, are required to keep hard copy and associated paper documents of much of their work. Unfortunately, the paper filing systems, used to keep these documents, have numerous shortcomings, resulting in excessive time to retrieve items, real and intangible costs, frustration, and in some cases lost documents and information. An inability to reliably retrieve information and documents, previously stored, can mean the difference between winning and losing a case. The loss of an original contract document can result in the unenforceability of an agreement with the associated loss of large sums of money. The nature of a law firm's work demands extremely reliable retrieval accuracy of previously stored documents.

The shortcomings are the result of human mistakes and slips, which are provoked by the current design of the system. Personnel file documents incorrectly. They lose documents. They forget where they have filed documents or forget to return them to the file. They many times do not relate to the filed documents the way their boss does.

The retrieval accuracy of paper file systems can be improved by changing the faulty retrieval model currently in use. A major problem in life is retrieving information or an item that you have placed somewhere. To retrieve either, you must first recall, in human memory, the physical location of, or a map to, the information or item. Studies have shown that you can recognize much more information than you can recall. A system that aids mapping through recognition would greatly improve file retrieval speed and accuracy.

We believe that the retrieval of filed documents can best be enhanced by aiding the user to recognize categories, words, subjects and other mappings, uniquely associated with a document and the file system, rather than depending on a user to recall them. You can recognize much more than you can recall.

The current file systems, in the examined law firm, have a number of advantages. A major advantage is its existence for over 10 years. Personnel are familiar with it. Other advantages are its similarity with other file systems in other law firms and corporations. New personnel can learn it quickly. Retrieval is quick for small systems, even in the "date organized" filing "piles." The newer Portable File uses a current database software package to quickly find documents.

Although there are many advantages of the system, there are also many disadvantages. You must correctly file documents in a recallable location, relate the location of the document to the data entered, and be able to remember the recall keys (primarily numbers, dates and words) which you previously entered or scanned from the document. Most documents have no tracking when removed from the file, which leads to loss.

Beagle will address a major drawback of the file system: remembering the keys, categories or words that allow you to locate a document. Beagle will operate on the principal or recognizing rather than recalling keys and categories. It will not preclude early recall, but will aid you in recognizing how you might recall. It will provide you with "cues." If the first attempt doesn't find the document, browsing and further prompts will help recall.

We have focused on the main or everyday filing system rather than the portable system used for court and depositions. The interface technologies used in our approaches are available today, even speech recognition. Our approaches cover a spectrum from language interaction to navigation through a document space.

For practical purposes, we need to constrain vocabulary and grammar to avoid the ambiguity of everyday spoken language. Accuracy of the speech recognition tool will directly affect performance of the system. Because providing full interaction between the human and a computer is difficult, graphical output will be used to display the result. Document summaries are displayed as well.

The user will specify document criteria through menus and forms. To display the results, images of documents are presented, allowing browsing and recognition. By offering actual images to the user, we think that it will help maximize the use of recognition over recall. To aid migration from the current physical system, we model search criteria in the way the physical file system is searched.

A Camtree is the horizontal variant of the Conetree, which aids in labeling nodes. User selects which criteria are used in building the tree. The user browses tree to find documents. Additionally, documents can be highlighted or excluded from tree by specifying criteria.

This interface is based on computer understanding of human language. It uses the metaphor of a human assistant who goes out and searches for the documents needed. Ideally the user would describe the document(s) to the computer in the same manner that they would be described to a secretary. In a more practical application the user would specify the different attributes of a document using a relatively formalized language that would help avoid much of the ambiguity found in normal speech. The output of the system would be a graphical display both because it allows for faster interaction and because it avoid the need to develop full interaction dialog. The system returns a document or set of documents that the user may browse through. If the user sees the document that he wants he can select the document(s) and get their locations. Otherwise he can change the search parameters. Documents returned by the search would be sorted by title (or what ever field the user prefers) with a brief description by the title. If the user wishes he can call up a picture of the front page of the document for visual recognition. It would also be possible for the user to select a document and ask for more documents like the selected one.

This interface is based on the idea that the lawyers already have to give a sufficient description of the document to their secretaries for the secretaries to be able to find the document. What this does is take that description and use it to define the parameters of the search. Because the interface is based on normal human speech it should be easy to learn. It allows the user to directly state the attributes he is looking for without having to search for the proper input field. Also it frees up the entire screen for the system output.

Date: 11/3/98

"Computer, open dialog. Three days ago, Hilmmerman case, memos."

(The computer screen replies that there is no Hilmnerman case. It also shows the parameters of the search.

Case: Hilmnerman case

Document type: memos

Date: 10/31/98

)

"Case name spelling H. i. l. m. m. e. r. m. a. n."

(The computer screen shows a list of all memos made about the Hilmmerman case three days ago.

Case: Hilmmerman case

Document type: memos

Date: 10/31/98

)

"Hmm… Change document type to correspondence"

(The computer screen shows a list of all correspondences made about the Hilmmerman case three days ago.

Case: Hilmmerman case

Document type: correspondence

Date: 10/31/98

)

"No. Reset Dialog"

(The computer screen shows that no parameters are specified and has a list of 0 documents.)

"Dustave case, four days ago, investigations"

(The computer screen shows a list of all investigations made about the Dustave case five days ago.

Case: Dustave case

Document type: investigations

Date: 10/29/98

)

"Date 1. 0. 3. 0. 9. 8."

(The computer screen shows a list of all investigations made about the Dustave case four days ago.

Case: Dustave case

Document type: investigations

Date: 10/30/98

)

"View investigation Y"

(A picture of the front page of investigation Y fills the screen)

"Close"

(The picture closes)

"Include document type memos"

(The computer screen shows a list of all memos and investigations made about the Dustave case three days ago.

Case: Dustave case

Document type: memos and investigations

Date: 10/30/98

)

Lawyer scans the memo subject lines and sees the one he needs.

"Location of memo X and investigation Y"

(The computer screen shows a list of all memos and investigations made about the Dustave case three days ago. It also shows the location of the two requested files.

Case: Dustave case

Document type: memos and investigations

Date: 10/30/98

)

"Close dialog"

(The app closes)

User evaluations and testing would be very helpful when developing this interface. One reason is that it would allow us to gauge how easy this system is to use in comparison with the current system. On a similar tack it would give us feed back on how easy the system is to learn. Also we could run comparisons on what type of descriptions that lawyers give to their secretaries and then use those descriptions to help design the specification language. Another area where feed back would be helpful is in comparing the speed of this interface with the speed of the current system. It would not only allow us to see which system is faster but it would also allow us to see where the bottle necks of our system are so that we can work at removing them. A problem that many agent systems have is that the users come to think that the system can do more than it actually can. One function of the user feedback would be to see if that happens with our interface and then to see what needs to be done to remove this problem.

While in it's current state this system is not very friendly to the blind because of its dependence on graphical output. A variant could be built which either used Braille or gave vocal feedback. Also a keyboard option could be developed for those users who are mute.

The Menu Based Document Browser (MBDB) utilizes a color graphics based computer display (PC) to search for documents. It attempts to retain the original search techniques the law firm uses to manually find documents in a paper based filing system. In addition, it provides for the capture of document images electronically and adds new database search techniques to find documents. The database interfaces and search techniques are designed for file clerks, secretaries and paralegals that use the law firm's filing systems. Although attorneys can easily learn the system, it is unlikely that they will become users.

The search techniques are based on the principle that the user can recognize much more than they can remember. Multiple approaches, such as visual icon (picture) reminders, listings, key words and phrases and visual images of documents, are provided to prompt the user’s recall of a document. The search is menu based prompted with common functions grouped together and color-coded. The main menu screen provides a "glimpse" of all the techniques that can be used to find a document. The design intends to make it unnecessary to use any other screen for the majority of searches. The screen nesting is limited to one level below the main menu. One may quickly return to the main screen to begin a new search, abort a search, view documents, add additional criteria or reset a menu. The system is designed to keep the user from getting "lost" in the search process.

Multiple function icons and buttons are avoided. For example, a "help" and "more" function are located in each area of menu groupings. Help is localized to that area of interest. The "More" button takes you to the selections next screen of expanded information. For most searches, the user only needs to deal with the main menu.

Documents are scanned with an image scanner with OCR software to capture the text and visual image of the document in computer memory. The user familiar with the document may enter further information about the document. Therefore, both the words and phrases of the document as well as information about the users current relation to the document are stored. A sequential number is automatically assigned to the document during the capture process to speed manual file access for trials and depositions and indexing locations.

When the electronic search process finds the document, the user can print the document or retrieve it from the file location indicated. If the document is not found, the user can "Reset" the search criterion, reset a part of the criterion, enter other search parameters or abort the search and start over. The user may take advantage of the "Categories" to suggest how the document might be recalled.

This design uses many of the Human Computer Interface (HCI) principles of Usability. The system supports good Learnability through the search technique that mimics the old search techniques of the physical file system. For example the system searches the electronic files by consecutive dates in the same manner the user would search through a file folder visually. The electronic search is faster and has the advantage of additional search criterion being added to the date browsing. The user, who is generally computer or word processor literate, is able to learn the system faster from familiarity with the old system and the current windows based graphics PC's. Once date browsing is learned, the user is able to predict and generalize how other search criterion can be used. The outputs and inputs for different methods of searching are consistent, since similar menu search techniques produce a list of documents and the electronic image for every method of searching. Color-coded organization, groupings of functions, single mode menu buttons and visibility of results improve Learnability of the system.

Flexibility is provided through the multiple ways the user can search on documents. Dialog Initiative supports multiple methods of user interface. The user may choose for prompting and a guided path or bypass all menu functions and enter keywords to search for a document. One is not forced down a search path.

A user may substitute keywords and phrases for others and take advantage of equal opportunity. For example, the output of one search criterion can be, and is used for the input for another search criteria. The user may search on most any content or relation to the document that can be thought of. If you can’t think of a way, the organization and categories will prompt you.

Observability of the documents and the contents of the documents achieve Robustness. The content of the electronic memory is presented in multiple ways during a search. Everything is visibly known about the state of the search process from the main search menu window. Recoverability is provided for by the up-down, east-west movement buttons, reset buttons, one level of hierarchy below the main menu and individual localized help buttons.

The system is extremely responsive when compared with the old system. The user can browse through folders of documents much faster than manually leafing through them. Task conformance is accomplished by the multiplicity of techniques for a search and mimicking the old manual system. The task of finding the document is enhanced.

The above features take advantage of the familiarity with the old manual filing system and add powerful new techniques to help you recognize and then remember documents.

A typical user will be a file clerk, secretary or a paralegal. The paralegal is the more sophisticated and knowledgeable user. A typical use of the system by a secretary, a middle level user, will be to find a document requested by an attorney in the firm. He/she will take notes of what the attorney tells them about a document. The information may consist of the type of document (correspondence, memo, report, etc), people, dates, meetings, and any other ways the attorney relates to the document. For example, consider how a letter would be retrieved from the correspondence file.

Physically looking through the "Correspondence" file, which is date ordered, is the way a letter is found. In the new electronic system, the search is initiated for the "Correspondence" file by clicking on the "File Tree" icon. Upon display of the list of all files, the "Correspondence" file is selected. By clicking on the "Date" icon, the dates are listed in order in the "Selections" window. This mimics the date ordering of the old manual file system. The secretary now looks at the first pages of the documents displayed in the "Documents Retrieved" image window, but does not find it. Clicking on the "More" button brings up the next level screen to display the first 10 to 12 documents in the file. Not finding it, he/she then decides to return to the main screen with the "Return to Main" button. After checking to see how many items are in the "Correspondence" file, he/she decides that this file is too large to search.

He/she decides to narrow the date search with the "Trips" "Category", since he/she makes all the attorney's travel arrangements. Clicking on "Trips", and looking at the trips, nothing looks familiar. The error in going this path is fully recoverable and is visually indicated by the same number of documents (no reduction). Simply consider another "Category"

The "Trips" icons cause he/she to recognize that most trips involve meetings. He/she remembers that something was said about a meeting the attorney was at. Since he/she didn’t bring the notes taken in the presence of the attorney, it is decided to click on the "Meetings" prompt to see if the meeting can be recognized. The "AND" side of the menu is used to sort the files on "Correspondence" and a recognized meeting. There it is. "Meeting at Hilton Head" was captured along with 20 other meetings in the "Correspondence" file, when the document was entered. Now, 10 documents are listed that fit this criteria, 4 of which are displayed in the main menu. He/she clicks on "More" to see all 10 documents.

Before browsing the 10 images, he/she remembers that the attorney mentioned a Mr. Adams. Returning to the main screen with a click, he/she types in "Adams" in the criterion in the "Keyword" window. The "AND" function is still on. The search is narrowed to two documents, which are displayed in the main menu document window. The correct one is identified and printed out locally rather than retrieving it from the manual files.

The assessment involves the designer's judgements, the Gromit team and those of the paralegal at the surveyed law firm. Telephone conversations were initiated with the paralegal to discuss this design approach. The results and suggestions were minimal. This is attributed to the time spent in the discussion and the lack of visual contact. The user does not think in computerese and had trouble relating over the phone. This was a defect in the design assessment and will be corrected in the next phase.

The one suggestion the paralegal gave was to describe clearly, in everyday language, the different search techniques. There is a lack of understanding with the typical user of the relational database vocabulary such as "query". Therefore, any manuals and training must be in everyday language, preferably using terms and mapping to the older manual file system. All technical jargon should be eliminated. Although well understood by the design team, it must find another explanation for the "AND" and "OR" terms.

This design accomplishes a number of desirable HCI goals as outlined in the above discussion of the Rationale. Some desirable afterthoughts are appropriate. Although, it is desirable to see everything, related to a search, from the main menu, it was discovered that the icons and buttons should be larger than can be accommodated on a 15" screen. However, the only solutions are a bigger screen or more hierarchical menus. A bigger screen is the more desirable solution since additional menus make recovery from slips and mistakes more difficult. Becoming lost in menu levels is equally undesirable.

The design team must help the user understands "AND" and "OR" functionality. Additionally, the user should know at all times which function they are using. This problem will be investigated further. Most modes are self-indicating. The "AND/OR" issue can result in an erroneous failed search, simply because the user did not keep track of the "AND/OR" function.

Perhaps more work needs to be done on a portable machine for the attorney, to encourage them to use it. The screen size becomes an issue. That will be left for another project.

The original usability criterion has been exceeded in this stage of the design process. In addition to familiarity, predictability, and consistency (Learnability), we can accomplish generalizability as discussed previously. Originally, one goal was dialog initiative (Flexibility). Substitutivity with equal opportunity is now an additional goal. Along with observability and recoverability (Robustness), responsiveness and task conformance will be added.

The primary objective, recognizing contents and relationships, rather than trying to remember them, to help recover a document, continues.

A Conetree is a 3D hierarchical tree. Each node may have sub-items below, arranged in a ring. The links between the node and the items form the outline of a cone. A variation of the Conetree is the Camtree. It is built from left to right, rather than up and down, which makes labeling the items easier.

In our implementation, the user can select which criteria are used to build the tree. The user may also modify the order of the criteria. To search for an item, the user can browse through the tree. Although this may sound like an extremely slow method of searching, the hierarchical arrangement allows fast comprehension of where documents are located. Also, nodes of the tree are labeled with the criteria and the ranges of values of the documents below. Furthermore, an additional highlight feature is provided that allows the user to perform operations more like a traditional search. By specifying search criteria, documents of interest in the tree are highlighted. The user may also rearrange or select new tree building criteria to co-locate the highlighted documents in the same part of the tree. These search criteria can also be used to control which ranges of documents that are used in the tree. This can focus the user's search by eliminating documents that are known to be wholly irrelevant.

Interaction with the 3D tree can be done through a typical 2D interface. A mouse or similar pointing device can be used to browse the documents. Each document is labeled with a document title. Placing the cursor over a document will display a short summary of the document, much like the "tool tips" or "bubble help" in many programs. Clicking on a document will display an image of the document, allowing the user to visually recognize or even read the document and determine it's relevance. A second display would be useful to display the documents large enough to be readable, and keep the Camtree visible. Since documents are located in rings, many documents may be obscured. Clicking and dragging on a ring or using a wheeled input device like the Microsoft Intellimouse will rotate the ring. The user can use a zoom tool to zoom into a section of the tree. To help control clutter, the user can click on a node. This will collapse or expand the node's sub-tree.

One of the problems of browsing and searching for documents on the World Wide Web or any large document database is getting lost. It is hard to remember the path that has been taken to the current document and difficult to retrace one's steps back to the point when one made a wrong turn. Presentations such as a Camtree allow an overview of the entire universe of documents. The ordering of the tree is configurable which allow the user to browse the tree in a way that makes sense to the particular user. Traditional methods of searching that require specification of characteristics or keywords are replaced by tree traversal. Searching is often an iterative process that requires more criteria to be specified as the search is refined. Expert users may form strategies that must be developed and remembered. Camtrees can capture these strategies in the selected criteria and their order. Walking down that tree automatically causes the user to follow that strategy. The user also has the freedom to break from the strategy and jump further down or across the tree.

Often a lawyer will ask a clerk to find certain files related to a case. In the scenario, Alice, the lawyer is working on the Smith case. Simon has been asked to find an environmental report and a letter from Joe Smith about the environmental report.

Simon would go to his desk and bring up the Camtree. Since he knows that the documents are related to the Smith case, he can select only the documents related to the Smith case. He could then set up the tree building criteria. He would chose "document type" and then "author." Each node is labeled, so he can see the sub-trees that are for letters and reports. Since there are few reports, he can spin the reports and find the environmental report. Clicking on the environment report icon brings up images of the report on his second monitor. Simon can print the document, email it to Alice, or look up the Bates number and pull the hard copy document out of the files.

Simon then continues to try to find the Smith letter. He sets the system to highlight all letters from Joe Smith. No documents are highlighted. He clicks on the letter sub-tree and spins his Intellimouse (or drags the mouse). The document icons spin past, he reads the labels until he sees 10 icons labeled "Letter from Joseph Smith." Since he has focused the view on the 10 letters from Joseph Smith, he can select new highlighting criteria for a keyword search for all documents with "environmental report." One letter is highlighted and Simon can click on that letter and peruse it to make sure it is the proper letter. Again, Simon can print, email, or pull a hard copy.

User studies would be a good way to quickly assess this system for deployment. There are several dimensions that should be measured. The current system and this proposed solution should be compared. The learning curve of the systems should be measured. If the learning curve is similar to the current system, then expert use should be examined. The speed of lookup should be evaluated. Also, the number of keystrokes and mouse clicks should be compared. This is important since new OSHA guidelines and medical concerns have emphasized the need to avoid repetitive stress injuries. While there are models to predict keystrokes and mouse clicks, this information can be easily collected while other dimensions are being measured. Also, since this system gives some search functions in addition to tree browsing, it would be important to see which features are used more. Large variations in how users divide their time between functions would mean that both features are important, while users focusing on the search type functions could mean that search functions are a better match.

One drawback to this system is that its graphical nature does not lend well to use by individuals with visual impairments. Also, Camtrees have been used to handle up to 10,000 items. While cases at the law firm we examined do not exceed this limit it is conceivable that some special cases may.

The fist change to our requirements is our focus on improving the main filing system rather than the portable file system. We feel that the main filing system has a richer set of criteria to work with. We have also added the following usability criteria: Generalizability, Substitutivity (equal opportunity), Responsiveness, and Task conformance. The AND/OR function should be more visible and the use of technical and database terms should be avoided. Consistency, dialog initiative and observability will remain our formal measurement criteria.