[Originally appeared 2000.]

Somehow I imagined as I finished the Word of Law column in Word of Law No. 26 that it would be straightforward to finish the explanation of Word 2000’s Table AutoFit functions and offer some final guidance on avoiding “strange” table formatting. After a workshop on Word 2000 table functions and issues with the Word transition team at a law firm, I can offer some fresh insights and still won’t finish the story.

Before reading further, please understand that the intricacies described here are intended primarily for master users and developers. For general users, organizations should construct sample tables with the intricate formatting resolved, as has been encouraged in the last several Word of Law columns. For those working without such support, please consider thisa warning that discovery and mastery of table formatting techniques is not a wise task when trying to complete a document under a deadline. While practicing these techniques, it is safest to work on a document other than “real” production work.

Let’s return to the “strange” column widths mentioned in Word of Law No. 26. The most frequent symptom is a table with a ragged right border, some rows longer than others. Ragged right borders result if column widths are changed or columns inserted or deleted after one or more cells in at least one column of a table have a width different from other cells in the same column. This can occur either by changing the size of some cells directly, or by splitting one or a group of cells into multiple columns without applying that change to the entire column.

In both Word 97 and Word 2000, column widths can be set by dragging the column marker on the Ruler (the shaded bar with a tool tip of “Move Table Column”), by dragging a table border (enabled when the mouse cursor shifts to a double vertical bar with arrows pointing both right and left) and through the Column tab of the Cell Height and Width dialog (Word 97) or the Table Properties dialog (Word 2000). Very interesting things occur when the SHIFT, CTRL and ALT keys are combined with the use of the mouse and the Ruler. Holding down the ALT key while dragging either the column marker on the Ruler or the table border changes the ruler to show the column widths as the marker or border is dragged.

The follow situations occur if no cells have been selected before trying to change a column width:

•           Drag a column marker in the Ruler without SHIFT or CTRL pressed: The column immediately to the left and to the right of the marker increases or decreases in width, without changing the size of the columns to the right. The right edge of the table moves with the change, possibly beyond the right margin of the page.

•           Drag a table border without SHIFT or CTRL pressed: The width of the column immediately to the left and to the right of the border changes, but all other columns remain unchanged in width. The right edge of the table does not change.

•           Drag the column marker with SHIFT pressed, but not CTRL: The width of the column immediately to the left and to the right of the marker changes, but all other columns remain unchanged in width. The right edge of the table does not change. (Yes, this is the same as dragging the table border without SHIFT or CTRL pressed.)

•           Drag the table border of the selected cell with SHIFT pressed: The column immediately to the left and to the right of the marker increases or decreases in width, without changing the size of the columns to the right. The right edge of the table moves with the change, possibly beyond the right margin of the page. (Yes, this is the same as dragging the column marker without SHIFT or CTRL pressed.)

•           Drag the column marker or table border with CTRL pressed: The width of the column and the width of the columns to the right change proportionally. The right edge of the table does not change.

Before we get any further, then, notice that the Ruler behavior indicates what will happen to all of the columns before the change is applied to the table. In all cases, holding the ALT key down while dragging will show the column widths in the ruler.

We can understand these functions even better by looking at the controls VBA provides for setting column width. Although the language of VBA is most familiar to developers, the capabilities revealed by VBA can help others understand table behavior more thoroughly. The SetWidth Method is the VBA tool that allows a column or cell width to be changed. It includes a setting called “RulerStyle” that has four constants:

wdAdjustFirstColumn – The column in which the cursor lies and changes size, as does the column immediately to its right. The remainder of the columns remain the same size and the right edge of the table stays still.

wdAdjustNone – The column or selected columns change size to the stated value, and the remainder of the columns to the right keep their size. The right edge moves left or right accordingly.

wdAdjustProportional – Columns to the right of the selected columns are changed proportionally.

wdAdjustSameWidth – The selected column is adjusted to the set figure, but columns to the right are adjusted to equal width, leaving the right edge of the table still.

Now, with these capabilities stated (I hesitate to write “understood” <g>), we can return to the case where some cells in a column differ in width from other cells in that column. First, to cause this to happen (let’s assume intentionally), select the specific cell or cells first before changing the width by dragging the column marker or the table border. The following occurs:

•           Drag the column marker in the Ruler without SHIFT or CTRL pressed: The selected cell increases or decreases in width, without changing the size of the columns to the right. The remainder of the column in which the cells were selected retains its old width. The right edge of the table becomes ragged. This is the wdAdjustNone behavior.

•           Drag the table border of the selected cell without SHIFT or CTRL pressed: The width of the selected cell and the cell to the other side of the selected border change, but all other columns remain unchanged in width. The right edge of the table does not change and there is no ragged border. This is the wdAdjustFirstColumn behavior.

•           Drag the column marker with SHIFT pressed: This is the same as dragging the table border without SHIFT or CTRL pressed.

•           Drag the table border of the selected cell with SHIFT pressed: This is the same as dragging the column marker without SHIFT or CTRL pressed.

•           Drag the column marker or table border with CTRL pressed: The width of the selected cell changes and the width of the cells to the right change proportionally. The right edge of the table does not change. This is the wdAdjustProportional behavior.

All of the Ruler, mouse controls and VBA commands described above operate both in Word 97 and Word 2000. Changes to Word 2000 tables made with these Ruler and mouse techniques or VBA commands will function properly in Word 97, assuming no other table features (including Table AutoFit) have been used.

The primary difference between Word 97 and Word 2000 for the behaviors described so far is the difference between the Cell Height and Width dialog in Word 97 and the Table Properties dialog in Word 2000. In the latter, the column width controls are presented on the Column tab of that dialog. It introduces a “Preferred Width” setting, which works with both regular column widths and the automated column widths of the Table AutoFit function.

What is missing in both of these dialogs is a way to access the SetWidth functions described above. It is possible to construct a dialog that allows the cell or column width to be set and select one of the behaviors.

Next time we need to look at what happens when columns are inserted when one or more cells differ in width from their column, and return to Table AutoFit.

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

[Originally appeared 2000.]

This is the eighth in a series of columns about using tables in Word 97 and Word 2000 that began in issue Word of Law No. 20. Of the ten questions stated in that column, one remains:

What can go wrong when formatting tables, such as strange behavior in inserts in rows and columns?

Earlier in this series, we covered table-formatting issues arising from paragraph formatting or styles. Besides those, some of the most common formatting problems with tables, especially in Word 97, are columns that exceed the right page margin and tables with a ragged right border, having rows that end to the left or right of the general right border of the table. Some of these issues have been addressed by the changes in table behavior and tools of Word 2000, so answering this question gives us an excuse to explore further the Word 2000 table developments.

In Word 97, it is very easy to cause a table to spill over the right page margin, even running outside the page itself. As a simple experiment, start with a table that fills the page margins. Then select the right hand column and insert a column using the menu entry, “Table|Insert Columns.” The new column inserts to the left of the existing column, and the existing column pushes off to the right. The page margin offers no protection. As the Word 97 help file states, “Existing tables are not affected by changes to the page margins. To maintain the same relationship between the table width and page margins after changing the margins, adjust the table width manually.”

Fixing this problem requires resizing the table columns, whether using the mouse and the cell borders or the table column controls in the ruler, or using the Cell Height and Width dialog from the Table menu. If the table exceeds the right boundary of the page, shifting to Normal View from Page Layout can make this area accessible.

Word 97 also makes it easy to insert oddly arranged columns, causing one or more rows to extend out or shrink in from the right margin of the table. This occurs most easily if one or more cells in a column row vary in width from the rest of the column. This can happen by merging cells horizontally or by changing the width of a cell without changing the width of the column as a whole.

In Word 2000, the new Table AutoFit capabilities can help avoid these behaviors under some circumstances. It is fairly challenging to write about this feature at a level that can be understood by a range of readers. The whole topic of controlling table formats is complex enough (measured at least by the number of columns it has taken to explain it) that it should be considered a skill for master users. From an organization’s point of view, general users should be supplied with a set of working table formats, as we have discussed, and discouraged from changing them.

Plunging ahead for the master users, developers, trainers and architects, Word 2000 offers access to the new Table AutoFit properties in two ways. The first, more complete method is presented in the Insert Table dialog (accessed from the Table|Insert|Table menu entry). That dialog contains three Table AutoFit behavior choices – Fixed column width (accompanied by a sizing control), AutoFit to Contents and AutoFit to window. The second set of controls for Table AutoFit are included in the AutoFit section of the Table menu. That section includes five commands, AutoFit to Contents, AutoFit to Window, Fixed Column Width, Distribute Rows Evenly and Distribute Columns Evenly.

The AutoFit to Window setting does a good job of avoiding the column inserts that cause the table to exceed the right page margin and the right boundary of the page. With the table set to AutoFit to Window (either on creation or by application of the Table|AutoFit menu item to an existing table), the table format stays within the left and right margin. Insertion of a column results in shrinkage of the remaining columns, and deletion of a column results in expansion of the remaining columns, all within the existing margins. Under many circumstances, at least when trying to format one table at a time, this behavior can keep a table looking attractive.

AutoFit to Contents causes more varied formatting. The columns grow or shrink based on the text or other contents of cells of the table. Empty columns shrink to some minimum size. Watching the column sizes change as text is added or deleted gives the impression of a compound version of word wrap, which, in a real sense, it is.

As indicated in the last Word of Law column, these AutoFit functions are not consistent with the goal of keeping tables consistent in formatting throughout a document as a whole, or among the documents of an organization. They have their best use during development of table standards, or in solving the formatting of a single use table that will be used only in Word 2000.

The solutions to the ragged table edge issues turn out to depend on a number of circumstances, including both the methods used to size and insert cells and columns and the relationship to the Table AutoFit settings. Also, there is more to explain about Table AutoFit than can fit this week. We will keep at it for another week.

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

[Originally appeared 2000.]

From the list of ten questions about tables begun in Word of Law No. 20, we are left with questions 9 and 10. Having already broken the order of the questions several times, this column will focus on the developments in tables in Word 2000. As asked in Word of Law No. 20, the question was:

How does Word 2000 change table behavior? What happens when tables formatted in Word 6 and Word 97 get converted to Word 2000?

Word 2000 introduces many new capabilities and controls for Word tables and reorganizes the table menu on Word’s Menu Bar. These are one of the most changed areas of Word’s functionality between Word 97 and Word 2000. For many organizations at this time, compatibility between use of Word 2000 and Word 97 remains very important. Very few large organizations have converted completely to Word 2000, and even those that have must exchange Word files with those that haven’t. Thus, we will concentrate on the reverse of the second question, what Word 2000 table features should be avoided to maintain compatibility with Word 97.

Let’s start from the perspective of the general user, and the changes in the Table section of the Word 2000 Menu Bar. The Table section of the Word 97 Menu Bar can be quite confusing. The available commands change depending on the location of the cursor. For instance, if the cursor is outside a table, the “Insert Table” button (located in the second position from the top of the menu) can be activated. If the cursor is within a table, that same position on the Table menu is replaced with an “Insert Rows” command and the position below it becomes “Delete Rows.” If, while the cursor is within a table, a column is selected, that position changes to “Insert Columns” and the position below it changes to “Delete Column.”

I have always found this behavior difficult. When working intensely with tables in Word 97, I found it effective to create a custom toolbar with six row and column controls, (Insert) Rows, Delete Rows, (Insert) Columns, Delete Columns and (Insert) Cells and Delete Cells. In fact, the last two are much less useful than the first four. All of these commands can be found within Table group of the Commands tab of the Customize dialog. Note that the commands listed as “Insert” here lack that word in the customize menu, and have only an icon with the words “Rows,” “Columns” and “Cells.”

An aside to the developer readers: The same insert row, column and cell functions can be found in the “All Commands” group of the Commands tab. There they have the name of the actual Word command, “TableInsertCell,” “TableInsertRow” and “TableInsertColumn.”

Back to the perspective of the general users. This suggestion to use a toolbar showing icons for these table controls instead of a menu also reflects my personal sense that the structuring and adjustment of table formats is primarily a visual function. The need to relate the verbs of the commands (insert, delete) to the image of the table, imposes a constant translation between word based thinking and visual thinking. Working with table, mouse and icons, purely visually, can sometimes avoid that strain. People seem to vary significantly in the way they perceive these patterns and commands, so these suggestions may not work for everyone.

Ending those excursions, it’s time to return to Word 2000. The Table menu has been restructured. Now it behaves more consistently with common Word menu behavior. The Insert, Delete and Select commands have been grouped into submenus. All of the commands are always visible, and those not available are greyed out, instead of adjusting for context as they did in Word 97.

Also new to the table menus are commands for Insert Columns to the Left, Insert Columns to the Right, Insert Rows Above and Insert Rows Below. These are all new to Word 2000, and are very helpful. The old Insert Columns and Insert Rows commands remain, but their behavior was harder to control, especially in the first or last rows or column of a table.

Use of these commands creates no compatibility risk between Word 2000 and Word 97 tables. The inserted rows or columns have no special Word 2000 characteristics or properties. Word 2000 users, feel free to use and enjoy them.

The next new section in the Word 2000 Table menu is the AutoFit section. This contains new commands to AutoFit tables to the Window (actually margins), the table Contents and for Fixed Column Width. The easiest thing to write about this capability is to avoid using it for documents that are intended to live both in Word 97 and Word 2000. Word 97 does not support the automatic resizing of columns and rows supported by table properties in Word 2000. Understanding what the Table AutoFit properties really do, and fitting them into a strategy for standardizing the formatting of tables in an organization will take some more exploration, to be left for another week.

Word 2000 supports tables inserted within tables, but Word 97 does not. Word 2000 supports new capabilities for table placement. Again, the best advice is to avoid these capabilities if documents are to live in both environments. Exploration of their benefits for table standardization can also wait.

This week’s discussion ends with the expansion of table shading colors. Actually the color fill setting for both paragraph and table cells has been expanded in Word 2000 from Word 97’s black, white, 23 shades of gray and 14 colors to the full “16 million” color set. For those who seek to use color gently in their documents, observing Ed Tufte’s instruction to employ the least effective difference to highlight or otherwise distinguish text, the expansion of the color range is most welcome. When a document that uses the additional colors is opened in Word 97, the color is mapped to a related color among Word 97’s limited set. Whether that result is satisfactory is a matter of taste.

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

[Originally appeared 2000.]

Word of Law No. 23 promised a look at the use of AutoText as a resource for standardizing the formats of tables. What AutoText can do, and do very well, is provide a well-controlled source for new tables, fully formatted to the standards developed by the organization. What AutoText cannot do is change or clean up the format of existing tables.

The creation, organization and storage of a standard set of table AutoText entries should be considered a development activity. That is, either assign it to the Word developer or development team within an organization, or, if working alone or in a small group, undertake this task at some time when not engaged in production work.

The developer needs to prepare a global template that will make available to users the standard table AutoText entries. We recommend that these be in their own global template and not in Normal.dot. Then again, we recommend that virtually nothing an organization seeks to standardize should be in Normal.dot.

The critical step to making table AutoText entries work is to use a distinct Table style, as we have discussed in the earlier columns. That assures that the formatting of the table will not be disturbed by the variations in the parameters of other styles, such as Body Text. The developer should develop the standard table formats working in an empty clean template. Go ahead and save the template with a name such as “Table Source.” It would be a good idea to delete from the Table Source template all styles except Normal and the Table style or styles. Prepare a set of tables, fully formatted, including number of columns, fonts and font emphasis in the heading, first and last columns and rows, borders and shading. It helps to create different versions of tables for portrait and landscape pages. It may be helpful to copy fully formatted tables from completed documents into this template, but there may also be some difficulties. It is likely that those tables have not been formatted using a special Table style. Instead, use the completed tables as a model, but construct the standards tables from scratch.

Generally, the table samples that will become AutoText should not themselves have text in them. That will only create additional work for the users to change the text. If there are tables that are used very frequently with standard headings or first row entries, it may be useful to create AutoText entries specifically for them.

To save each table as an AutoText entry, turn on the AutoText toolbar and place the cursor anywhere within the table. Select the entire table. Use Table|Select Table in Word 97, or Table|Select|Table in Word 2000’s cascading table menu or (in the standard keystroke assignments) ALT and the 5 key in the number pad with NumLock off. Create the AutoText entry with the AutoText button on the left of the AutoText toolbar. Do not use the ALT F3 shortcut to create the AutoText entry. That will store it in Normal.dot, and we want these AutoText entries in the Table Source template. The AutoText button will bring up the AutoText tab of the AutoCorrect multitab dialog. Note carefully the selection in the “Look In” list box at the bottom of the dialog. Before you make a change that should say “All Active Templates.” For the purpose of saving these standard Table AutoTexts, the Look-in list box needs to be changed to Table Source.dot (assuming that you have used that name for this template). Be sure, when you are finished with development, to change the Look-in list box back to All Active Templates.

Naming the AutoText entries is a matter of taste. One good strategy is to start all of their names with “Table” so users can find them easily. The names should be selected to make it easy to expand them during typing. Thanks to the reader who suggested names such as “Table3p” to indicate a 3-column portrait oriented table. Then adept users can enter the AutoText by typing “Table3p” and F3 to expand the AutoText.

To help less adept users, the developer should consider modifying menus or toolbars to make the list of the standard table AutoText entries more accessible and better documented. One approach would be to modify the Table menu to add an entry for the organization’s standard table formats. The menu entry could be called “Insert [Organization name] standard table.” In Word 97’s Table Menu, this would fit logically right below the Insert Table entry. In Word 2000’s reorganized Table Menu, it would make more sense as an additional entry in the Insert submenu.

This menu of table AutoText entries could also be inserted in the Tables and Borders toolbars or its own special toolbar. The menu entries can be more descriptive than the AutoText names, especially if the AutoText names have been abbreviated for power typing, as suggested above. Be sure to include the abbreviated name in the description as well. Then the menu becomes part of the documentation for the table AutoText entries.

The text of the Table Source template can serve as its own documentation. After developing and formatting the standard table examples and saving them as AutoText entries, the text of the template can be expanded with explanation, notes and examples of the AutoText entries in use. It may be desirable to include in the Table Source template a macro that prints a copy of this text so that users can refer to it. That macro could be included in the special menu.

When complete and tested, the Table Source template should be included in the Word startup directory.

A note to developers: The AutoCorrect multitab dialog is called “AutoManager” in VBA. There is a dialog that shows only the AutoText tab. While doing this AutoText development, it may be less distracting to show that dialog. The following macro accomplishes the same effect as the AutoText button on the standard AutoText toolbar.

Sub AutoTextMultiTab() With Dialogs(wdDialogToolsAutoManager) .DefaultTab = wdDialogToolsAutoManagerTabAutoText .Show End With End Sub

This macro shows only the AutoText tab. Sub AutoTextOnly() Dialogs(wdDialogEditAutoText).Show End Sub

These work in both Word 97 and Word 2000.

Now, how many columns did I say it would take to cover tables?

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

[Originally appeared 2000.]

We continue the exploration of issues relating to tables that started in issue Word of Law No 20. In Word of Law No. 21 and No. 22, the first four of the ten questions about tables were covered. The next question was:

How can a firm or other organization standardize the formatting of tables?

We are looking for the tools and techniques that will allow an organization to standardize the formatting of tables, yet allow tables to have the variations they must to support varying amounts of information or to take on the range of appearances desired for the different parts of an organization. Further, we want the table formatting solution to allow a table to change formatting to meet these needs without complex end user intervention.

To answer this question, we have taken a detour to question 8 and have begun to explore how styles interact with tables. We finished the column in Word of Law No. 22 with the suggestion that before inserting a table, the user should insert an empty paragraph in Normal style. This would cause all of the cells in the table to be in Normal paragraph style.

In Word of Law No. 22 we suggested that tables should have their own paragraph styles. To keep this strategy fairly simple, the table style or styles should have settings only for fonts. The next design decision to make is whether the font should be based on the font of the Normal style. One of the basics of Word’s style function is to permit one style to be “based on” another. This relationship is indicated in the Style Dialog in the Description box and in the Modify Style dialog, where the Based On entry is shown. These relationships can be printed, using the “Print What” selection in the lower left hand corner of the Print dialog and selecting Styles from that pull down menu. A series of styles can be chained to each other using the Based On entries. This allows a setting in the first style of the chain to modify all of the rest of the chain. For instance, by setting the font only in the first style in the chain, all the related styles can change fonts by changing the font in the first style.

For that reason, it is a good design feature for most templates to set the font in the Normal style, and use it as the first style in the chains for the other styles in the document. This permits all of the fonts in a document to be changed by changing the font of the Normal style. If the design of the document calls for the tables to have the same font as the rest of the document, tables can be created within a Normal style paragraph.

It may be desirable to have tables use a font different from the body of the document. In that case, it could be desirable to build tables based on a style not based on Normal style. It might be called Table Base. A style can start a new chain by having no entry in the Based On box.

This brief column advances the story of tables. We didn’t really address the question at the start of the column. Obviously, it will take several more columns to complete it.

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

[Originally appeared 2000.]

We continue the series of columns on tables started in Word of Law No. 20. Of the ten questions listed in that issue, we have covered the first four. The next question asked how organizations can standardize the formatting of tables in their Word documents. Regular readers of this column might wonder how that question could be answered without exploring the answer to the eighth question, “How should styles be used in tables?”

In fact, it has taken enormous restraint to write about tables without explaining the potential for paragraph styles. So, let’s address that question next. In the course of addressing it, we will touch on issues that relate to several of the table formatting questions.

For this discussion, please read or reread first the Seven Laws of Styles in Word of Law No. 1. Please note that references to “styles” here mean paragraph styles.

Following these rules, styles enable Word to apply consistent formatting to paragraphs that have the same function. Named and applied consistently, paragraph styles also allow the formatting of documents or components of documents to be transformed to meet the formatting standards of different groups within an organization. Can this approach work for tables?

To answer that question, we need to understand what aspects of the formatting of a table, its cells and the contents of its cells can or should be controlled by styles. This gets quite intricate and is aimed at master users, help desk staff and developers.

First, we need to understand where the paragraphs are in tables. Each table cell contains at least one paragraph. If the view settings show paragraph marks, an empty table cell (as well as the end of row marker) shows a table cell marker symbol (a circle with 4 small straight lines pointing outward at about 2:00, 4:00, 8:00 and 10:00 viewed as a clock face). A table cell may contain multiple paragraphs. If it does, then the paragraph marks for all but the last paragraph in the cell appear as the standard paragraph mark character.

If no direct formatting has been applied to the paragraphs in table cells, they will have the formatting characteristics of the style that has been applied to them. These include font, line spacing, spacing before and after, tabs, left and right indents, first line indent and alignment. They could also include borders and shading and numbering. These settings apply to each paragraph. If a cell only contains one paragraph, they will apply to that paragraph. If it contains multiple paragraphs, they will apply to all of the paragraphs.

Table cells have several formatting settings that can overlap or interact with these paragraph based settings. These include borders and shading and cell height and width. These settings apply to the cell as a whole.

When an empty table is inserted into a document, Word applies to each paragraph of the table the formatting of the paragraph in which the table was inserted. For instance, if a table is inserted in a paragraph to which Body Text Indent style has been applied, and Body Text Indent has a font of 12 point Bembo, left and right indents of 1 inch and space before and after of 6 points, then each of the cells in the table will inherit the application of the style and most of the formatting. The fonts, tabs and line spacing are inherited without change. The left indent and first line indent are reset to 0 automatically in the table, using direct formatting. A more dramatic instance of this inheritance occurs if the paragraph or style had numbering applied. Then all of the cells in the table will inherit the numbering. These behaviors are the same in Word 97 and Word 2000.

The paragraph settings applied to the table cells include both those from the style applicable to the paragraph in which the table is inserted and any direct formatting applied to that paragraph.

We can begin to draw some conclusions from these observations. First, styles used outside of tables are not likely to work properly in tables. Indents and tab settings that work in the body of a document can throw a table completely out of whack. Thus, tables will need their own set of styles. Styles for tables should not control borders and shading. Those should be controlled by the table cell formatting.

Second, insertion of a table in any paragraph that has special formatting or numbering applied will have unintended consequences (at least) in the table. We hope that those troubleshooting table formatting will find this explanation of table formats helpful.

A safe starting point for inserting a table is to first insert an empty paragraph and apply Normal style to it. Then insert the table. Select a desired format for the table with Table AutoFormat.

Yes, these instructions violate two of the Laws of Styles. In fact, observing the Laws of Styles helps make this strategy work. Normal Style should have the least possible formatting settings, perhaps only the base font for the document. This approach does not achieve all the goals for standardizing table formats in an organization, but it may help keep many users out of trouble.

We will continue the exploration of tables in the next column.

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

[Originally appeared 2000.]

The Word of Law column in Word of Law No. 20 began the discussion of strategies for tables, and set out a list of 10 questions to be addressed. We continue this week with the next two related questions.

What’s the difference between a table used for presentation and a table used for the organization and storage of data?

By a “table used for presentation,” I mean the use of Word’s table feature solely to format text on a page. This clearly includes use of tables just to solve formatting issues, such as the address and signature blocks and legal pleadings captions mentioned in the last column. In those cases, tables allow control of alignment and spacing of text vertically, while permitting a variety of alignment within each column. Critically, only tables support word wrap within each column. That gives them a significant advantage over formatting based on tabs, even when taking advantage of the control permitted by right, centered and decimal tabs.

Microsoft Word tables can be used for the storage, organization and manipulation of data. The rows and columns of a table create a framework into which structured information can fit. To take an example as simple as an address list, the columns may indicate elements of data for each addressee, such as name, street address, city, state, zip code, email address and telephone, fax, mobile and pager numbers. Each addressee gets her own row. How did the word “simple” get in the second to last sentence?

The issue is what the user expects to do with the information. If the only purpose is to display information, formatted legibly and attractively, then I consider the table “used for presentation.” If the purpose of the table is to collect information, to be able to keep it sorted, select from it for other purposes (such as inserting an address in a letter), manipulate the information (such as changing the office address for all addressees who work for the same company), then the table is in the latter category.

So what? Actually, that is the purpose of the next question.

When should a spreadsheet or database program such as Excel, Access, Outlook or a larger scale database be used instead of a table?

We have already begun to answer this by describing the ways a user might want to reorganize, select, link, modify, export and import information into a table. While Word includes rudimentary capabilities to perform some of these functions, they do not compare to the capabilities of spreadsheet tables or of real database programs. As a matter of vocabulary here, we will use Excel and Access represent spreadsheets and databases, although Word can work with others, of course.

At the very least, a general or master user should ask oneself, how much do I need to work and rework the information in this table? Does that table contain arithmetic, even as simple as rows that are the sums of the entries above them and columns that are sums or products of entries to their left. If the answer to the first question is more than twice (maybe even more than once) and the answer to the second question is yes, then the table should be in Excel and not in Word. The user will need to know how to copy and format text derived from Excel in Word, but we will cover that in a later column.

From an organizational perspective, an equally important question is to what degree should the information stored in a table be shared among users. That address list we have been describing most likely can serve the needs of several users working on the same project or for the same client. These are issues for the developers and system architects. They must evaluate whether the information in the tale the power of a database. They must determine whether a commercial product fits the need, or whether custom development is required. They need to set up the linkages so that information from the database can be made available to Word, so that general users can benefit from it with a reasonable level of training. They must structure training and help desk support to promote these techniques.

The system architect should search for the use of tables among the population of general users. They are likely to find many databases in disguise, with much repetition of effort among users. Tables really are a window from Word to much of the rest of the world of computing.

In the next column, we will continue with the questions about table formatting.

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

[Originally appeared 2000.]

A reader asked where to learn to be a system architect, a position described in Word of Law No. 19. Discussing this with a colleague recently, I said, “intense curiosity, self teaching and the good fortune to have a job that allows me to do it.” There is very little instruction or literature addressing Word in this way. It is one of my ambitions for this column to help fill that void.

The next several columns will focus on tables and Word. After those, I expect to tackle document comparison, including Word’s capabilities and those of third party programs such as CompareRite and DeltaView.

This discussion of tables starts with “why,” not “how.” I don’t intend to replace or repeat the kind of detailed instruction in the use of tables that appears in books such as Using Microsoft Office 2000 by Ed Bott and Woody. Instead, in this and the following columns, we will address at least these questions:

1. Why use tables?

2. What role should each of the types of users of Word play  in the use, support, design and construction of tables?

3. What’s the difference between a table used for  presentation and a table usedfor the organization and  storage of data?

4. When should a spreadsheet or database program such as  Excel, Access, Outlook or or a larger scale database be  used instead of a table?

5. How can a firm or other organization standardize the  formatting of tables?

6. What are appropriate formats for tables?

7. How helpful are the Table Autoformats?

8. How should styles be used in tables?

9. What can go wrong when formatting tables, such as  strange behavior in inserts in rows and columns?

10. How does Word 2000 change table behavior? What happens when tables formatted in Word 6 and Word 97 get converted to Word 2000?

This week’s column covers the first two questions. The use of tables should be guided by the principles of all of The Word of Law columns. Organizations should design and promote use of Word that makes easy consistent formatting, makes documents as reusable as possible and enables documents to transform to the requirements of different groups or users. Along the way, there should be at least a few tips and tricks.

Why use tables? Tables should be used to organize and display structured information. Tables should be used where they offer the most effective and easiest solution to formatting a document. In some cases, tables also can serve to control a user’s navigation through a document, such as electronic forms.

Tables should be used for any columnar presentation of data, whether or not the table employs borders. The need is clear when the information consists of rows and columns of numbers. Tables offer the best solution any time text entries in columns must wrap across multiple lines. Although word processing has supported tables for at least 10 years, we still see examples of data formatted with tabs or even spaces.

Tables without borders can be used to solve a number of formatting problems difficult to solve with other techniques. A one row table can be used to format text that appears to be flush left and flush right on the same line or in the same paragraph. The text in the left cell would be aligned left, while that in right cell would be aligned right. This may be useful in headers and footers. A third cell in the center might be aligned center. While the same effect may be achievable with a center tab and a right tab on the right margin, such text can be harder to control and will not wrap in each column.

Tables without borders can be especially useful for memo headings, address blocks and signature blocks. In legal pleadings, tables have become a common tool for formatting the case caption.

Tables enable organized storage of information. The issue is not whether tables work, but are they sufficient for an organization’s needs when that stored information needs to be reorganized, filtered, analyzed, reused, maintained or shared.

What role should each of the types of users described in previous Word of Law columns play in the use, support, design and construction of tables?

General users should be able to insert tables, correctly formatted for the organization’s practice and type of document. They should be able to insert text and numbers in tables correctly, including a high degree of comfort in navigating around tables. They should know how to apply styles, when they are used to control formatting. They should be able to use tables for simple data storage and organization tasks. General users avoid the more difficult table tasks. For instance, they should not often need restructure table formatting, or master insertion of Excel tables into Word documents.

Master Users should be able to handle table formatting and structure thoroughly. Although they too should work with the organization’s standards created and maintained by the developers, specific documents often require variations. They need to master the skills for organizing information, such as sorting and filtering. Master users should be comfortable switching between Word and other applications, such as Excel or Access, and know how to present information stored in those files in Word. Advanced table skills are one of the keys that differentiate master users from general users.

Help Desk and Trainers need to understand all of the tables skills required of general and master users. They need a strong grounding in troubleshooting techniques. They need to understand the organization’s standards for table usage, and how to apply them to the variety of documents.

Developers need to understand how to mold Word to support standards for table formatting. They need a thorough understanding of the role of tables as formatting solution. Developers should support needs for custom design or configuration of spreadsheets and databases that need to connect to Word, especially the configuration for import and presentation of information from those programs to Word. Developers need to master the VBA, template and AutoText functions that can be brought to bear to support table use.

For starters, System Architects should know how to ask and answer all of the questions posed at the beginning of this column.

These suggestions are not intended to exhaust the topic.

One table oddity finishes this week’s column. The cursor position immediately following a table has a special function. In Word 97, the Insert Table command is disabled when the cursor is located at this position. In the standard Table menu, the “Insert Rows” command appears where the Insert Table command normally appears. The behavior of that command differs from its “normal” function within a table. Within a table, Insert Rows will insert the number of rows selected. If the selection is collapsed, one row will be inserted. If the cursor is located at the position following a table, and the Insert Rows command is selected, an Insert Rows dialog box appears prompting for the number of rows to be inserted. This dialog is not presented as even an optional choice for modification of the Table menu or a toolbar. It can be forced to appear in both Word 97 and 2000 with a macro command of the form: Dialogs(wdDialogTableInsertRow).Show

In Word 2000, this empty paragraph has similar behaviors, but the menu commands have changed, as we will explore in a later column. With the cursor at the position immediately following the table, the Table|Insert Rows Above command is enabled.

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

[Originally appeared 1999.]

From time to time, I have written about the distinctions in tasks and skills that should exist between the staff who use Microsoft Word to write and produce documents and the staff who support and develop the Word environment. This and the following columns will describe those issues in detail for medium and large organizations. In those organizations, each of the roles described below may be staffed by different persons. Some of the skills may be best supported by outsourcing. There are lessons, however, for smaller organizations, or even individuals, in the divisions of responsibilities. The columns will develop that perspective as well.

No matter what the size of the organization, the ultimate measure of success with Microsoft Word is the experience of the end users. However trite that statement, it should never be forgotten as developers congratulate themselves on the elegance of their dialog box or programming code. For those who have worked directly with me, I acknowledge both the lapses and the need to obey that rule.

End users should be able to employ Microsoft Word to produce their organization’s standard documents with a minimum of effort devoted to formatting, troubleshooting or other distractions from getting the words (and images) right. The tools for accomplishing these tasks should be highly visible and accessible. End users should have available a set of templates, styles, AutoText, macros and other Microsoft Word tools that allow them to write documents in final form. Training should be centered on the tasks of producing those documents and using the appropriate tools to do the job.

This perspective on the experience of end users is critical to achieving the benefits that are supposed to accrue from computer usage, including efficiency, production speed, quality control and consistency. In (this year’s) consultant’s vocabulary, they enable reduced Total Costs of Ownership.

By these statements, I am not trying to argue that general users need not be sophisticated in their understanding of Microsoft Word, or that training should be “dumbed down.” In fact, we want a user community that understands precisely how Word works, so that they will embrace its most powerful features, such as thorough use of styles. We don’t want to burden end users with the responsibility for the development and presentation of those tools. We just want them to use them correctly.

Note in this discussion that I am not drawing a distinction between authors and secretaries. In many organizations (especially outside of traditional legal practice), authors have primary responsibility not only for the words in their documents, but their production as well. Secretaries may serve a number of authors, and have significant responsibilities besides producing documents. The title “secretary” is disappearing, replaced by “assistant.” In some markets, it can be very difficult to even hire secretaries. Given those developments, this orientation to the use and support for Microsoft Word has special force.

Let’s call the next level of responsibility and skill for Microsoft Word “master users.” These users have a thorough and deep understanding of the front end of Microsoft Word. They know all of the functions relevant to their organization outside of the Visual Basic Editor. No matter how well an organization develops its standard environment for Microsoft Word, there will be documents that require special handling and skill. In legal practice, for instance, public disclosure documents may incorporate a range of formatting and features far more complex than standard briefs or agreements. Assigning such tasks to master users allows greater quality control and ease of production, while avoiding significant frustration for users who haven’t mastered such functions.

Master users need to understand and manipulate features such as complex tables. They need to understand the intricacies of the division of documents into sections, with multiple headers and footers. They should understand fully the capabilities of styles, and know when special formatting requires new styles or direct formatting solutions. They should understand the use of fields, including cross reference and style reference fields. Where an organization’s documents require it, they should understand the full set of features for graphics and images. The skills for graphics production represent an even more specialized set of talents.

In the next column, we will look at the skills required for support and development.

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