Archives for October 15, 2012

Word of Law No. 43 – Word Mayven – Don’t Meander, Navigate

[Originally appeared 2002.]

I’m very, very pleased to announce that Bob Blacksberg, our “Word of Law” columnist has found the time to grace these pages once again. As many of you know, Bob specializes in using Word in a corporate environment – specifically big law offices, where some of the most demanding Word work goes on every day.

We’ve decided to change the name of Bob’s column, specifically because he deals with problems that confront every advanced Word user – whether they’re in a law office or not. Thus, with a tip o’ the hat to William Safire, Bob will henceforth be known as WOW’s Word Mayven.

Quoth the Mayven:

“ Long documents strike fear among many Word users. When a document such as a report, proposal, training guide, agreement or brief exceeds 10 to 20 pages, comfort with reading, writing and editing on screen drops dramatically. I see many users (and often find myself) trying to find our way through the document by pressing the down or up arrow or the Page Down or Page Up key until we get near the desired location, then hone in by keystroke or mouse to the right text. Often enough, all this effort brings us to the wrong place.

In this column, we will review Word’s tools for navigating long documents. Beyond that, we will consider enhancements to Word’s navigation tools and compare the user interface of other programs, especially Adobe Acrobat, and consider how they might inspire better use of Word (or even a better Word).

The use of the word “navigate” is most deliberate. The reader/writer/editor shouldn’t see and travel through a Word document as if it were a featureless swamp or desert. It should feel like walking/cycling/driving a well planned city with excellent signage. The point of this metaphor is to understand that Word documents have or should have features that enable the reader, writer and editor to navigate through them by their content and structure.

The well trained Word Navigator should master the Select Browse Object menu (I did not make up that name), the Go To dialog and the Document Map. The most adventurous Navigators can add the Outline View to the list. (Unless mentioned specifically, all of these functions operate similarly in Word XP, 2000 and 97.)

CTRL Page Up and CTRL Page Down: The Browse Power Tools

Sitting mysteriously in the lower right hand corner of Word’s screen, at the bottom of the Vertical Scroll Bar are three controls, a circle in the middle and chevrons pointed up and down. These controls are in fact part of the Vertical Scroll Bar and do not appear if the Vertical Scroll Bar has been disabled in Tools|Options|View. Clicking on the circle opens the ten icons Select Browse Object menu. Two icons launch the GoTo and the Find Dialogs. The other icons on the menu offer a choice among the Field, Endnote, Footnote, Comment, Section, Page, Edits, Heading, Graphic and Table. Clicking the mouse on the up or down chevrons then moves through the document to the previous or next instance of the selected feature.

Notice that the tooltip for the Browse Previous and Browse Next icons changes to the Previous or Next command for the selected Browse Object. In fact, this is the way to know which Browse Object is in operation.

The default keystroke mapping makes CTRL Page Up the same as Browse Previous and CTRL Page Down as Browse Next. With this capability, these are true power keystrokes, navigating through a document precisely to the element in interest. They are especially powerful after executing a Find command, since they will navigate back or forward to the text searched without the screen clutter of the Find dialog.

The Select Browse Object menu has not changed components, but has changed arrangement through Word 97, Word 2000 and Word XP.

Visually aging or classic, but powerful: THE GO TO DIALOG

The GoTo Dialog offers the “classic” interface for navigation. It can be launched many ways in the default Word installation: F5, CTRL G, the Go To icon in the Browse Menu and by double clicking on the location area in at the bottom of the screen. Barely changed in appearance since ancient days of Word (at least version 6), it adds to the visual Browse menu’s list of navigable features Line, Bookmark, Equation and Object. It allows movement by multiples, so one can move 20 pages ahead with one command. The Bookmarks selection creates a drop down list of bookmarks. Many of the entries allow navigating to an item by number, including Page, Section, Line, Footnote, Endnote, Table, Graphic and Equation and Heading. This solves the problem of how to navigate correctly to Section 4, page 5. First Go To Section 4, then Go To Page +4 using the Go To Dialog.

For keystroke fans, with some use of the tab key, the Go To dialog allows navigation a long document without ever mousing. The dialog has sticky settings, so it retains the last setting for the Browse Choice and item number or other fill-in chosen. The Find/Replace dialog works similarly.

Delightfully, Browse Next takes on the values selected in the Go To dialog, even if they don’t appear separately in the Browse Menu. So if Bookmark has been selected in Go To, then Browse Previous and Browse Next will Browse by Bookmark, although the Tool Tips read Previous or Next Find/GoTo.

THE DOCUMENT MAP: Good User Interface but only sometimes effective

The Document Map has been available in Word since Word 97. It creates a pane on the left side of the Word screen, similar in appearance to the frames that have become a familiar part of the Internet and Windows Explorer interface. We style enthusiasts find it both useful and effective, since it allows us to navigate directly to Heading Styles and other styles that have been set for inclusion in the Table of Contents. The Document Map does not show content that has been marked for a table of contents using the TC field inherited from early versions of Word.

For the aspiring Word Navigator, the Document Map, when working, represents the best of Word’s user interface. The Document Map remains active on the screen, out of the way of the document text. The Document Map can be collapsed or expanded by heading level, either for the entire document or for segments. The Document Map can be turned on or off for each open document window.

Are these tools enough for effective Word Navigation? That and the Outline View will start the next issue of this column.

This 2002 article originally appeared in Office Watch.Subscribe to Office Watch free at http://www.office-watch.com/.

Word of Law No. 42 – Styles, Word and WordPerfect

Bob Blacksberg, whom you all know as our “Word of Law” columnist, had a thought-provoking response:

“David’s perspective seems to be that of a sole practitioner, and doesn’t take into account many of the issues that apply in a firm with many lawyers, no less with multiple offices. Standardization in legal writing has significant benefits to the efficiency and quality of conducting a law practice. Microsoft Word’s structure, when used well, enables and encourages that standardization. My motto for legal documents is that they should be consistent, reusable, interchangeable and transformable.

It can be difficult to achieve these goals with WordPerfect. Its stream of text and codes makes it very easy to develop “easy” personal solutions to formatting that can be very hard to replicate and share. The results of cutting a fragment out of one WordPerfect document and inserting it into another vary, depending on the techniques used to format it. Style based paragraph formatting in Microsoft Word addresses many of the issues. To paraphrase David (in a sense), properly formatted Body Text, plus a Heading 1 through 9 styles, when backed by shared templates with proper format settings for the styles and the special text and formatting of the opening and closing sections of documents, cover much of the ground in legal documents. Keystrokes can support the application of the Styles without any VBA formatting. In our work, we assign Body Text ALT-B and Heading 1 through 9 ALT 1 through ALT 9.

WordPerfect 5.1, a terrific program, had a number of shortcomings, even for legal writing. The fixed character screen display made use of proportional type faces difficult. A typical line of Times Roman 12 point stretched past the right edge of an 80 character wide screen. We adopted tricks, including special display alterations, but all of these gave way to the clarity of the Windows display, especially on a larger monitor at screen resolutions of 1024×768 and above. Control of the formatting, editing and navigation in tables in WordPerfect 5.1 was frustrating and difficult. Again, this essentially visual task benefits enormously from the Windows display and the additional visual controls available on it. While I am a major fan of keystrokes for editing, a mouse can be very helpful when adjusting the width of a table column.

WordPerfect 5.1 did not support collapsible outlining. As an attorney who wrote complex documents, including financing agreements and disclosure materials, the ability to manage and navigate text through the entire structure of a document is very significant. The outline view of Microsoft Word, combined with the use of Heading Styles for outline headings, achieves this well. It could not be done in WordPerfect 5.1, and, although incorporated in subsequent versions of WordPerfect, has never been satisfactory for me.

WordPerfect 5.1 did not support new document templates. One could create such a structure with macros, but later versions of WordPerfect have used this feature, as have all versions of Microsoft Word. The Word of Law column has covered the benefits and capabilities of templates many times.

Keystrokes are not hard to find or use in Microsoft Word, although Microsoft hardly goes out of its way to point them out. Some of the most valuable keystrokes for navigating and editing text are in fact shared with WordPerfect, especially the Windows versions. CTRL plus the direction arrows have the same functions in WordPerfect 5 on and Microsoft Word (word left, word right, paragraph up, paragraph down). CTRL + SHIFT plus the direction arrows makes that navigation a selection tool. These are extremely powerful. CTRL Page Up and CTRL Page Down navigate by the last selected Browse Object. This sounds technical, but can make navigation by last search, table, figure, page or section very easy.”

 

This 2001 article originally appeared in Office Watch.Subscribe to Office Watch free at http://www.office-watch.com/.

Word of Law No. 41 – Document Assembly 1

[Originally appeared 2001.]

After a pause of several weeks, thanks to several writers for serious and thoughtful responses to my questions about success in teaching and using templates with a strong style orientation. Your reports confirm that organizations that take the time to develop and promote such standards gain much. As Office XP becomes available, we can review strategies for templates and styles in the light of new the formatting features and viewing options available in that upgrade.

For now and the next several columns, we will explore the strategies, tools and methods for document assembly. This column will cover definitions, identify the questions to be covered and describe the basic capabilities needed to support document assembly.

This discussion will focus on standardizing the content of documents and automating the tasks of creating individual documents based on standardized text. In many of the Word of Law columns, the role of Microsoft Word templates has been featured. The columns have highlighted formatting and other features of templates that can control the Word environment, such as keystroke assignments. Templates of course, can contain text. With the power of macros and other features of Microsoft Word, such as fields, it should be possible to automate the creation of new documents with standardized text. That goal has been “obvious” since word processing arose in the late 1970’s and early 1980’s, yet its achievement remains elusive.

Although the tools matter, the challenge and solutions to document assembly remain primarily in the people – the skills, staffing, responsibility, authority and time investment necessary to the success of a document assembly project. Often we have seen in legal practice, as well as other professions, the assignment of document assembly projects only to information technology staff. These projects fail. Document assembly needs (some) programming knowledge. Document assembly requires (much) content knowledge.

We begin by restating a definition for document assembly. Document assembly means the automated creation of documents or portions of documents using standardized text, including the insertion of data into the text and the selection of applicable text based on responses to questions or other pre-defined rules.

To take stock of the current state of document assembly, we need to address at least the following questions.

1. What functions in Microsoft Word and supporting programsare required to support document assembly?

2. For what types of documents does the effort to preparedocument assembly have the highest payoff?

3. What responsibilities must be staffed and what methodsmust be employed to succeed in a document assembly project?

4. How well do Microsoft Word and VBA support theprogrammatic requirements for document assembly?

5. What help is offered by third party programs?

6. Where does the Web fit in?

7. What’s next for document assembly?

The rest of this column covers the first question. Document assembly requires the insertion of data into standardized text. It should be no surprise that the characteristics of the data that may be inserted into documents in document assembly resemble those of databases. The data should be classified into various types, many of which have characteristics similar to the data types in a program such as Microsoft Access. They include text, number, date, currency, yes/no or true/false and multiple choice. Data may be unlimited in content or format, or may be limited to specified choices of content and formatting. Data may be derived from other data in accordance with programmed logical or computation rules.

The document assembly tool should enable an item of information to appear in different places in a document in different formats. A date, for instance, should be entered once, but able to appear as March 20, 2001 or 3/20/2001 or the twentieth day of March 2001.

Document assembly must support conditional inclusion of text based on logical rules. Blocks of text, including insertion of standardized text shared among several documents, should be included or excluded based on the answers to true/false or other logical questions, or the values of data.

The data and rules for selection of text or provisions for document assembly should be able to be derived from several sources. It may be obtained from user input during the assembly process, from one or more dialogs. It may be obtained from answers to such user input dialogs in a prior instance of the assembly process saved separately from the document. It may be obtained from one or more databases. It may be obtained by calculation from other data, including logical values. For instance, if the assembler of a standard contract form chooses a renewal option for annual renewals unless cancelled on 90 days notice prior to the anniversary of the contract, the dates for renewal notices could be inserted automatically based on the effective date of the contract. It should be possible to mix and match these data sources.

Finally, the results of the document assembly, in most instances, need to be an editable document. For the purposes of this column, that means a document in Microsoft Word. In many instances, the “programming” of document assembly does not or can not resolve all issues required to prepare a draft of a document. The assembly process must be able to leave the assembler able to complete the drafting. An open question is whether the document that results from assembly can be reassembled. Although there are instances where this capability has been supported by document assembly solutions, it is uncommon.

 

This 2001 article originally appeared in Office Watch.Subscribe to Office Watch free at http://www.office-watch.com/.

Word of Law No. 40 – Styles and Templates

[Originally appeared 2001.]

The arrival of the new year provides a good excuse to take stock of the major theme of the Word of Law columns, share some thoughts about putting these concepts into practice, and look ahead to the subjects deserving coverage this year.

This column is devoted to the art of successful use of Microsoft Word by medium to large organizations. Drawing and focusing on this author’s experience in the practice of law, technology and the combination of the two, we trust that the concepts and guidance have benefit for many organizations.

THE key theme of these columns has been the central role played by styles in Microsoft Word formatting. In this space and in our client work, we urge organizations to design and deploy a set of templates that allows their user community to prepare documents consistent both in appearance and underlying structure. Thorough use of styles allows documents to be CONSISTENT in appearance, with easily REUSABLE and INTERCHANGEABLE text, TRANSFORMABLE to the variety of formatting requirements of different authors or groups of authors within the organization.

However appropriate this statement may be as a goal, putting it into practice remains the test. We continue to hear of challenges to getting users to adopt style-based formatting.

I especially welcome your reactions to the following questions. Some of you have been kind enough to share your thoughts on these issues in the past, and I welcome updates.

Has your organization been successful in designing, deploying and using a set of Microsoft Word templates based on a thorough and consistent set of styles?

If you have been successful in promoting style-based formatting, what works best to teach it and sustain its use?

Besides troubleshooting problem documents, have you adopted any quality control procedures to examine and review formatting “in the wild?”

If you are successful in your organization, how do you deal with documents exchanged with other organizations?

Looking forward to the Word of Law in 2001, at least two subjects stand out for coverage. Document assembly is a very important part of our work. Many documents have standard content, portions of which contain predictable information and other portions of which should be selected for inclusion based on definable rules. As with other topics, we will consider the tools available, the roles of different members of professional and support staff in developing and maintaining document assembly systems, and the elements of design for construction and sustaining the systems. We will look at strategies using the tools of Microsoft Word, as well as third party programs that work with Word.

Assuming Office 10 arrives as expected later in the year, we will have an opportunity to revisit several topics, especially styles and numbering. From a relatively brief look at Office 10 Beta 2, there are new features in these areas that deserve careful coverage. There may be some suggestion that these new capabilities allow the benefits of styles without the “trouble.” I don’t expect to retreat from the advice given here, and trust (and will test) that it works as well or better in Office 10.

We look forward to continuing to intrigue and challenge you. Please keep reading.

This 2001 article originally appeared in Office Watch.Subscribe to Office Watch free at http://www.office-watch.com/.

Word of Law No. 39 – iScrub my Word Documents Clean

[Originally appeared 2000.]

It has been several weeks since the Word of Law has appeared thanks to this author’s busy schedule. Readers of this column may find helpful an article published in Peer to Peer, the newsletter of LawNet, entitled, “Three E’s for Excellence: Critical Strategies for Microsoft Word.” [No longer available.] Written with a very tight word limit it summarizes the major themes of this column.

Since the appearance of the last Word of Law column, I have been working with my colleagues on the development of a enterprise-wide tool for the management and cleanup of Word metadata. We hope that by sharing some of the design concepts of what we call iScrub, we can help readers connect the concepts stated in this column with a metadata solution.

In the article in Peer to Peer, we offered the following critical rules for metadata management:

Create clean documents. When creating a new document, disconnect it from its past life. Copy the body of the old document into a shell created with new document templates.

Edit cleanly. Avoid use of Versions and Fast Save that can leave deleted text in a document. Add substantive or instructional comments using the Comment function, not hidden text, footnotes or endnotes.

Don’t send, publish. Users must practice appropriate procedures when sending or sharing an electronic copy of a file with outsiders. Publishing a document means following electronic cleanup procedures such as removing comments, undesired Track Changes or other unwanted information.

We drew on these principles, as well as the major themes of the series of columns on collaboration, when designing iScrub.

When creating a new document, use a new shell.

Many of the difficulties with metadata occur when documents are modified and saved under a new name, but then fail to lose their prior history. Even without a more sophisticated metadata solution, the practice of copying the core content of a document into a new document shell (preferably created from one of the organization’s standard templates) helps cut off this old information. Other side benefits, such as reducing the number of unused styles or numbering list templates can also result from this technique.

The determination about what to clean from a document should be made at the firm-wide or company-wide level, and not be left to individual discretion.

This principle responds to at least two concerns. First, users should not be burdened to develop a personal understanding of the metadata issues. Many elements of metadata are quite technical, or at least divorced from everyday tasks of creating and editing documents. To expect the user community to master these issues and determine what steps are required to clean out metadata places imposes a great burden. Second, metadata cleanup should be performed consistently throughout the practice. From the perspective of law practice, this principle addresses whatever risk management concerns might be created by inconsistent, infrequent or haphazard metadata cleanup.

It should be possible to correct the metadata elements that directly indicate user identity to a firm- or company-wide standard on a continuous basis, without running a “cleanup macro” explicitly.A dynamic and continuously running solution is needed.

The October 20, 2000 article on the front page of the Wall Street Journal, entitled, “Beware, ‘Invisible Ink’ Inside Computer Files May Reveal Your Secrets” described the metadata issue for a broad reading public. This article described how metadata identifying a document’s author tied an accusatory series of e-mails to the staff of an opposing candidate. The metadata solution should enable all documents created by an organization to have empty values for the documents “Author” and related identifying properties, or to have standard values, such as the name of the firm.

The metadata solution should distinguish between documents that are internal, documents that are shared with “cooperators” and documents that are transmitted to “adversaries.”

Many of the elements that we have discussed as metadata may be valuable, or even critical when a document is used inside an organization. For instance, in order to make an organization’s styles, macros and AutoText specific to a type of document available, a document’s attached template is likely to be a template other than normal.dot. It might be desirable, to facilitate efficiency of document creation and production, for the document template to have specific information about a client, and even be named for the client. When sent outside the organization, however, it may be undesirable or even harmful for the document to indicate this relationship

The motto, “Don’t Send, Publish” captures this issue. The best time for metadata cleanup occurs when a document needs to be delivered electronically to a person outside an organization. Teaching users to use special procedures to “publish” a clean copy of the internal version of a document when transmitting it outside is achievable. It is the electronic equivalent of the instructions to check to see that there are no pencil markings or notes on the paper document before copying it for distribution. In iScrub, we classify the cleanup procedure “Publish as Scrubbed Document” and provide users with a choice of “Cooperator” or “Adversary” to determine the appropriate level of cleanup.

 

This 2000 article originally appeared in Office Watch. Subscribe to Office Watch free at http://www.office-watch.com/.

Word of Law No. 38 – Word Metadata 2

[Originally appeared 2000.]

We continue the exploration of the storage of information other than the text of a document in a Word file. We explored in Word of Law No. 37 the potential for exposing deleted text and commentary. The potential for disclosure of undesirable or even damaging information from those elements of a Word file is fairly high. The methods for keeping documents clean of such elements as track changes, elements and comments are readily available for aware users of Word.

The document properties discussed in this issue, generally, pose a smaller risk of adverse disclosure. These properties can unintentionally disclose the identity of the persons who participated in editing a document, as well the timing and effort involved in editing a document. Such information may have more potential for embarrassment than harm. Some attorneys, for instance, have suggested that accidental disclosure to a client that a document was used for another client (or worse, copied from that other client’s file) may hurt their client relationships.

The properties, however, are harder to control or clean out.

Track Changes Identities and Timing.

If the Track Changes | Highlight changes function has been enabled, each change contains, in addition to the text inserted or deleted, the values of the user identity, date and time when the change was made. In prior columns, we have described the importance of either not using Track Changes, or accepting changes prior to distribution of documents when this information should not be shared.

Title Property.

This is a built-in document property. Unless set deliberately, the Title Property preserves the opening phrase of a document the first time the document is saved, whether or not that phrase has been retained in the document during drafting. If the template on which the document is based has a value for the Title Property, that may be transferred to documents based on the template. In either case, the contents of this property may not be appropriate. This behavior can be controlled by viewing and correcting document properties when saving a file. As described in issue 5.42, check the box for “Prompt for Document Properties” on the Save tab ofTools|Options. Don’t leave the value empty. At least insert a space in the field if you want it to be blank.

Routing Slip.

When the File|Send|Routing Recipient function is used, the name of the recipient is stored in Word’s electronic file. This can be cleared by removing the routing slip value. (On the File | Send To | Routing Recipient dialog, select “Clear.”).

Past Authors.

Word stores the value of the user identity (Tools|Options|User Information|Name) in the file each time a document is edited, up to the last 10 authors. This can not be disabled, and can not be controlled directly within Word. Microsoft’s Knowledge Base article suggests saving to RTF or HTML, then restoring to Word format to clear this property. That may not be the last word on this subject.

Creation Time Property.

This built-in document property automatically records the date and time when a file was first saved.

Last Saved Property.

This built-in document property automatically records the date and time when a file was most recently saved.

Last Accessed Property

This built-in document property automatically records the date and time when a file was most recently opened.

Printed Property.

This built-in document property automatically records the date and time when a file was most recently printed.

Revision Number.

This built-in document property tracks the number of times a document has been edited and saved.It is not dependent on the use of Word’s Versions function.

Total Editing Time.

This built-in document property automatically tracks the elapsed time that a document has been open for editing.This function can be turned off, at least with the Office Policy template in Word 2000 (and other Office 2000 applications, which offers the choice to “Do not track document editing time.” This creates a registry key called “NoTrack” in HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\9.0\Common\General. I have found no reference to a similar control for Word 97. I found a tool for controlling this value at www.xtech.com. Needless to say, making such changes should be done carefully, in a controlled environment, before trying them in production.

Document Statistics.

The additional information in the document statistics properties of word, such as word and character count, are generated from the file, and not stored as values.

Document Contents Property

This built-in document property can have values assigned to it, but does not acquire them automatically.

Author Name Property.

This built-in document property automatically takes the value of the user identity at the time the document is first saved.If the value is made blank, Word automatically assigns the user’s network identification to this property, if the user is logged on to a network.This value can be edited on the Properties dialog.

Author Initials Property.

This built-in document property has automatically assigned to it the value of the user initials (Tools | Options| User Information | Initials) at the time the document is initially created.

Company Property.

This built-in document property is automatically assigned the value of the Company in user’s Windows setup. It can be modified on the Properties dialog. To make it “blank,” insert a space.

Manager Property.

This built-in document property may have a value assigned to it, but does not have an automatic assignment. It can be modified on the Properties Dialog.

Last Author Property.

This built-in document property has automatically assigned to it the value of the user identity when the document was last saved.

We have indicated some techniques for controlling or cleaning these properties, where that may be critical. Further columns on metadata will discuss a few additional features of a Word document that may convey unwanted information, and then proceed to explore strategies for cleanup in greater detail.

 

This 2000 article originally appeared in Office Watch. Subscribe to Office Watch free at http://www.office-watch.com/.

Word of Law No. 37 – Word Metadata

[Originally appeared 2000.]

We return to the questions raised in Word of Law No. 29, that began the series on collaboration. Three remain, of which two are:

What techniques can be used to assure the identity of the persons who have worked on a document? Does Word permit or support an audit trail of document revisions? How do third party tools help?

How does Word preserve evidence of the drafting process? What strategies can be used to avoid creating this information in the first place? When it is desired to include such information during drafting, how can it be cleaned out before distribution of a document?

The discussion about these issues has come to be entitled, “metadata.” For instance, Microsoft has posted the Knowledge Base article “WD97: How to Minimize Metadata in Microsoft Word Documents http://support.microsoft.com/support/kb/articles/Q223/7/90.ASP and Microsystems has posted a white paper entitled, “…Shares Well with Others…”. http://www.microsystems.com/Shares_Well.htm . We have referred to some of these issues in the preceding columns.

I am not happy with the word “metadata” as a title for this discussion. It sounds either too techy or too classical to help us understand the issue at hand. The key questions are:

What information does an electronic version of a Word document contain in addition to the text and graphics that we intend the reader to read and see?

Does the disclosure of that information have a potential for harm or embarrassment?

What steps can be taken to avoid the inclusion of the information, or to remove it on distribution of a file to others?

Answering these questions will also answer the questions listed in the first two paragraphs of this column.

Not all information contained in an electronic file other than the intended text creates a risk of adverse disclosure. Some of that information may be necessary to the proper formatting or intended automation of the contents of the document, at least during certain stages of a document’s life cycle. Some elements may be appropriate to share among Cooperators, but not with Adversaries. The distinctions between those groups were explored in issue 5.28.

The rest of this column and portions of the following column will examine the elements of a Word file that have a potential for unintended disclosure of information other than the document’s text.

We have grouped these elements into categories based on the type of exposed information.

“Deleted” Text.

These elements of a Word file may expose text that had been deleted during the drafting process.

Track Changes Text.

This is the deleted text remaining in a document when “Track Changes” is enabled.(Tools | Track Changes | Highlight Changes or the “TRK” button on the Status Bar).The Track Changes function has an option that records changes in the document as they are made, but does not show them on screen or in print.If not removed, a recipient of a document can restore access to the deleted text by re-enabling it for viewing or print.

As discussed in issue 5.35, the safest way to avoid unintentional disclosure of information is to avoid use of the Track Changes feature.

Versions.

This function enables Word to save prior versions of a document as part of the electronic file. (File|Versions).There is an option to automatically save a version every time the file is saved.A recipient can access any of the versions that have been saved.

As discussed in issue 5.40, this feature has a very high probability of unintentional disclosure, and should be avoided.

Fast Save.

This option, still part of Word from the time of much slower personal computers, hard drives and networks, causes only incremental changes to a file to be saved. (Tools|Options|Save|Allow fast saves).Deleted text can still exist in the electronic file when the function is enabled. This option should be disabled.

Comments and friends.

The second group of Word elements are used by some or many users to add commentary to the text of a document. It may be appropriate to share this information with Cooperators, especially within a legal practice or other organization, but not with Adversaries.

Hidden Text .

This is a Font attribute that causes the text so formatted not to print, unless print options have been specially set.

Users who have employed this technique for commentary or instructions should be redirected to use comments. There are legitimate reasons to use the hidden text property for formatting and or other control of Word, such as enabling heading styles to work fully for tables of contents, so mechanical stripping of hidden text from a document is not a recommended technique for metadata control.

Comments.

These are inserted special fields that can contain written or audio commentary.(Insert|Comment). They are highlighted on screen, and do not print unless print options have been specially set.

Comments are the appropriate tool to use for commentary or instruction among cooperators. They should be removed before distributing a document to Adversaries. Even among Cooperators, it may be desirable to remove some comments. Footnotes and Endnotes. Some users employ these for commentary during drafting. Again, they should be directed to use comments and leave footnotes and end notes for their purpose as text.

The next column will continue with a detailed look at document properties both visible and less visible that track information about drafting history and the identities of those who have edited documents or even portions of them. To begin to expose these elements, in the Save tab of Tools|Options, check the box for “Prompt for Document Properties.” A dialog will appear when a document is saved that lets the user control the content of some, but not all of these properties.

This 2000 article originally appeared in Office Watch.Subscribe to Office Watch free at http://www.office-watch.com/.

Word of Law No. 36 – Tracking Document Versions in Word

[Originally appeared 2000.]

Much of the discussion in the current collaboration of The Word of Law has focused on comparison of documents. To make the comparison meaningful, it is essential to keep track of the version of the document.

Let’s set aside some features of Word that might appear to be helpful, but in fact are not. Word 97 and 2000 documents have a property called “Revision Number.” It can be viewed on the Statistics tab of the Properties dialog (File | Properties).

Unfortunately, it increments every time that a document is revised and saved. If one practices the first rule safe computing (save early, save often) this number can (and should) become large. For those of us who compose or edit directly on screen, the importance of frequent saves cannot be over emphasized. Try keying CTRL-S along with entering each paragraph mark. One way or the next, we cannot rely on the Revision Number property to be an accurate guide of the identity of a document version.

The second theoretically helpful feature is the Versions function of Word (File | Versions). This enables Word to store in the electronic file for a document multiple versions of the text. There is an option to automatically save a new version on closing a document. At least for our lawyer readers, we recommend very strongly not to use this feature. It causes the prior text of a document to remain in the file, raising the risk of unintentional disclosure of changed or deleted text. The storage of multiple versions, especially in larger documents, increases the file size and raises the risk of failure in editing the document.

That leaves file naming conventions to keep track of versions. Many law practices and some other sizable organizations have deployed software called document management systems to enhance the storage and retrieval of their electronic files. Without explaining the rest of their features, document management systems offer version control by associating all versions of a document together. The user interaction with the several versions is similar to that provided by Word’s Versions function. Users generally edit the most recent version of a document, but have access to the prior versions.

Unlike Word’s Versions, the prior versions are maintained in distinct files, so the problems of adverse disclosure and file integrity are avoided.

For those without document management systems, similar tracking can be accomplished through document naming conventions, especially taking advantage of long file names. The naming convention can include version number as part of the document name. It might be abbreviated v1, v2 … or Ver 1, Ver 2, or it could be spelled out as Version 1, Version 2.

The key issue, whether or not using a document management system, is to know when to identify a new version. Here are some rules worth observing.

1. Increase the version number whenever a document is distributed to others for review. This should occur whether the distribution is internal to an organization or external. This supports unambiguous use of document comparison tools to trace changes between the version distributed and the revised version. It may be desirable to track separately internal and external distribution. For instance, there might be three internal revisions between version 2 and version 3 distributed to third parties. To distinguish the revisions, use a subversion number for the intervening internal revisions. Some document management systems support these directly. With document naming conventions, the subversions could be labeled 2A, 2B or 2.1, 2.2 and so forth.

2. Those who receive and revise documents should rename their copy. Rather than increasing the version number, they should add their identity to the current version name. Thus, if I were to be reviewing a version 3 of a document written and managed by Peter Deegan, I would save my revisions to the file as “Document Name, Version3 (Blacksberg).” Obviously, long files names are a must.

These are not new concepts. With electronic collaboration growing rapidly, and multiple copies of files traveling by e-mail, however, the advice grows more important.

This 2000 article originally appeared in Office Watch. Subscribe to Office Watch free at http://www.office-watch.com/.

Word of Law No. 35 – A Collaboration on Collaboration 6

[Originally appeared 2000.]

We continue the series on collaboration, written by Bob Blacksberg in collaboration with Sherry Kappel of Microsystems. We have been reviewing third party tools for document comparison, looking to find solutions to the difficulties encountered with Word’s internal Track Changes and Compare Documents functions. In Word of Law No. 35 we quoted the Microsoft Legal Users Guide’s recommendation to law firms that a third party tool should be used for document comparison. A reader directed us also to guidance not to use both Word’s internal Track Changes feature and CompareRite.

In this week’s column, we consider the document comparison capabilities of Adobe’s Acrobat and Workshare’s DeltaView.

Similar to Lexis-Nexis CompareRite, the Compare Pages function of Adobe’s Acrobat delivers a report of changes between one document and another. Thus it supports the Comparison function, but not Tracking or Incorporation, that we have described in the preceding Word of Law columns. Acrobat’s technology avoids the document formatting and appearance issues that we have covered in the preceding columns, since the PDF (Portable Document Format) files are created from the print process.

There are several drawbacks to document comparison with Adobe Acrobat. These limit its effectiveness and practicality as a solution for document comparison and collaboration in legal practice and other work that requires a high degree of document comparison precision.

The Compare Pages function of Acrobat only highlights broad portions of text as changed, either entire pages, or significant portions of pages. Thus it does not offer the capability of showing changes in specific wording or sentences, or indicate text has been moved. It does not explicitly mark insertions and deletions.

The process of producing such a PDF comparison report from Word requires publishing both the original and the revised Word documents to PDF, then comparing the pages to determine the changed results. This function requires the full licensed version of Adobe Acrobat, not just the free and widely used Acrobat reader.

While these shortcomings make Acrobat fall short as a tool for supporting the document comparison functions we have sought, it can play a significant role in document collaboration under some circumstances. Publishing to Acrobat solves format incompatibilities among collaborators. If responsibility for editing is not shared among collaborators, then the PDF format and Acrobat’s tools include many features that assist in collaboration, such as document annotations. Publishing to PDF avoids transmitting undesirable information about the drafting process to third parties.

The newest document comparison product, DeltaView from Workshare Technology, Inc. (www.workshare.net) raises the bar significantly in its capabilities and performance in document comparison. It deserves serious evaluation by legal practices and any organization that requires intensive comparison of Microsoft Word documents. The availability of the most recent version, 2.5, was announced on August 17, 2000. The descriptions here are based on that version.

Where CompareRite was designed as a tool to create paper images of the results of document comparison and Adobe Acrobat was designed to create the electronic analogue in its print and page oriented presentation, DeltaView has been designed to create an on screen environment rich in its capabilities of supporting the document comparison, review and incorporation process. It also thoroughly supports printed reports of comparisons.

DeltaView works by launching a session with Word, opening the original and revised documents, then, using the inherent RTF SaveAs filters of Word, DeltaView creates a rich formatting context in which comparison of the document content can begin. Again, like Acrobat and CompareRite, DeltaView delivers a report of the changes. This report is delivered in either a .WDF (a Workshare proprietary format) readable by DeltaView, or an RTF file format which would then enable an editable report by any application which can read or open an RTF file format, or as a Microsoft Word document.

DeltaView’s onscreen review environment offers a multi-paned view of the document comparison report. It can show the results of comparison only, or present simultaneous views of the comparison results, together with either or both of the original document and the modified document. It can also present a pane with a summary of document changes. Navigation tools include backward and forward arrows to move from change to change, as well as live links between the document change summary and the changes in the document. All of the visible windows are linked, so navigating in any of the views moves the other open windows with this.

This multiple view addresses the concerns about legibility of document comparison that we described in issue 29. While the comparison report indicates where changes occur, comprehension of the meaning of the revised text often requires a “clear” reading of the modified document.

DeltaView supports comparison to show changes in formats, and, in a development most welcome, shows a variety of change in tables, including addition and removal of table cells. The rendering set allows distinctive coloring of inserted, deleted and moved table cells. On screen, these indications are very clear. For those relying on the printed output, the need to support color printing just grew.

The current version of DeltaView does not directly support Incorporation. An enhanced version of DeltaView, which Workshare calls “DeltaView Premier” is described on the Workshare web site, with an availability later this year. It will add an Incorporation function, making the “Modified” document window a functioning instance of Word linked to the other document comparison windows of DeltaView.

When the DeltaView comparison is saved to Word format, the markings for inserted, deleted and moved text use distinctive DeltaView styles. It would be possible to construct a macro based system for Incorporation, working with those styles. Given the support for that function in the Premier Version, such an effort needs to be weighed against waiting for Workshare to support this function.

Workshare’s experience with enterprise document tools shows in the features of DeltaView. The developers of DeltaView had been the authors of SafetyGain, a companion product that supports offline use of the document management system, DOCS Open. DeltaView includes enterprise configuration support, such as the management of rendering sets and integration with iManage, DOCS Open and WORLDOX document management systems. The additional collaborative capabilities of DeltaView Premier look intriguing. We will track those developments and report on them as that version of the product becomes available.

All of this discussion of document comparison requires some reminders of the importance of version control. That can lead off next week’s column.

This 2000 article originally appeared in Office Watch. Subscribe to Office Watch free at http://www.office-watch.com/.

Word of Law No. 34 – Collaboration on Collaboration 5 – Comparison with CompareRite

[Originally appeared 2000.]

We continue the series on collaboration, written by Bob Blacksberg in collaboration with Sherry Kappel of Microsystems. In Word of Law No. 33, we looked at the capabilities and shortfalls of the document tracking and comparison functions of Word 97 and 2000. The limits of these built-in functions to meet the demands of precise and complete document comparison required for legal practice, together with the unintended evidence of the drafting process that can remain in an electronic version of a document after track changes has been used, left Microsoft advising law firms to look to third party solutions for document comparison.

As usual, we trust that the focus here on the needs of legal practice informs the users of Microsoft Word in other organizations, especially when documents need to be written and edited with the care and precision used for drafting legal documents.

This week’s column considers CompareRite, the historical leader among third party comparison tools. For several years, this product has been owned by Lexis Nexis Group.

CompareRite works outside of the Word application, reading the original and revised files, then creating a third document, reporting the changes found between the two. Similar to the Compare Documents function built in to Word, the resulting report is an editable document. Where Word’s Compare Documents function applies Word 97 and Word 2000’s track changes feature to mark changes, the results of CompareRite document uses character insertions (“[” or “]”, for example) and character attributes – strike-through, bolding, double underlines – to denote inserted, deleted or moved text.

CompareRite supports a greater variety of methods of reporting the comparison than the built-in function in Word, such as changing the boundary characters and formats for inserted characters, using placeholders instead of strikeout text for deletions and applying special markings for moved text (instead of Word’s pattern of showing the text deleted in its original location and inserted in its new). The selection of options can be stored by users.

Of the collaboration functions relating to document comparison described in issue 35, CompareRite supports only Comparison, not Tracking or Incorporation. That is, it can only produce the document reporting changes, but not create a record within the document of who made the changes and when, as the Track Changes feature does in Word, or automate the process of incorporating changes into a revised document, as the Accept or Reject Changes feature does in Word.

This limitation of CompareRite has its benefits, since it assures the integrity of the original and revised documents, including protecting the clean revised document from the evidence of the drafting process that can be left behind when Track Changes are used.

One cannot speak about CompareRite without realizing first that law firms have long integrated use of the tool into their daily work, bringing one legal secretary to conclude that her “attorneys have forgotten how to practice law without it!” In fact, when the product was paired in its early years with WordPerfect 5.1, the two applications worked almost in harmony, creating a level ofstability and performance difficult to match in with any other word processing application.

It is not nostalgia which made CompareRite the legal industry’s de facto choice, but rather its “pinpoint” comparison algorithms. Historically, comparison products have underachieved when – dare we say it? – compared to CompareRite’s routines for precisely detecting complex moves and changes. It is, in fact, this precision and accuracy which continues to justify that an organization ferret out solutions and workarounds to CompareRite’s common fits and starts – a situation which exists whether it is comparing two Word documents or (even) two WordPerfect documents.

This situation has evolved over the course of the last decade, as CompareRite continued to revise its proprietary binary file converters to meet each new word processing application’s enhancements and binary file format revisions. This legacy has challenged the application, reaching a critical stage with the release of Word 97:

Prior to that release of Word 97, CompareRite rendered the comparison of Word 6/95 documents by reading the applications’ binary file format, and writing a binary Word result. With the release of Word 97, however, when the significantly revised binary file format specification was not made available for nearly a year from Microsoft, Lexis was forced to take an alternative plan of action. Microsoft provided the vendor with an RTF file converter which would run stand-alone – without invoking Microsoft Word itself.

It turns out this filter was several revisions behind the released converter internal to Word. If you have not completely suppressed these events from memory, the RTF converter which was internal to Microsoft Word suffered more than its share of flux during that period of time. Because of these issues, as well as CompareRite’s inability to compare the content of tables, CompareRite and Word 97 had much difficulty operating together.

These difficulties have promoted, however painfully, an awareness of the importance of common formatting practices and consistent and intelligent procedures for conversion of documents from WordPerfect to Word. This, coupled with the recent release of CompareRite’s Version 7, Patch 9A, have eased the burden’s of the use of CompareRite to some degree. Patch 9a, whose design and stability benefits are only experienced fully, however, using Word 2000, can run Word to generate its RTF files, improving its accuracy and stability.

Still there are common issues which compromise the success of using CompareRite with Microsoft Word. These include:

  • Non-uniform tables. CompareRite doesn’t handle tables at all. If they must be compared, turning troublesome tables into text makes the most sense in many of these situations.
  • Poor or corrupt field code construction (e.g., unpaired field codes, or improperly delimited field code text).
  • Inconsistent formatting between the original and revised documents, primarily in the realm of numbering.
  • Corrupt or poorly converted documents.

It is hard to write about using CompareRite without restating the need for good version control practices. That, however, merits its own column. In the next column, we will continue the story with the document comparison capabilities of Adobe Acrobat and WorkShare’s DeltaView.

This 2000 article originally appeared in Office Watch. Subscribe to Office Watch free at http://www.office-watch.com/.