In Word 2007, I was the program manager responsible for driving both the changes in the styles user experience and the investment made in lists. There a number of decisions that were made by those of us involved in those efforts that folks are still talking about (including in recent comments on this and other blogs). This post gives you some of my personal insights as to why we went in the directions we did. The goal is to provide a bit more information about both how Word works and why it works the way it does in these areas.
The Style User Experience
The organization of the Home tab of the Ribbon had two primary driving forces from my perspective. The first was to get the most commonly used commands readily available to the user. The second was to present the style features of Word in a UI that matches their design (separating text styles from list styles from table styles). The underlying reasoning for this second focus was to subtly guide users in properly using these features.
The UI is very much biased towards applying text styles, with both visual and semantic cues to guide in the selection of the appropriate style. We made this change for three reasons. The first two relate to taking advantage of new user experience technologies â galleries and live preview. For the first time, users could see what applying a style would do to their content. The other was to separate text styles (which can be applied to any range of text) for the more specialized list and table styles (which should only be applied to those structures).
Note that List Styles are on the Home tab â but in the UI that emphasizes how they are meant to be applied. And Table Styles are on the contextual tab for a table â out of the way except for in the cases where they have meaning. One of the benefits of this organization was that we could add more specific UI around these styles. For example, when you apply a list structure from the Multilevel List gallery, we highlight the list that you are formatting. (Note that the Multilevel List gallery includes both list styles and unnamed multilevel list structures â a topic discussed in other blog posts.)
We also ensured that we continued to support two of the most common ways that power users applied styles. We updated the UI that you see when you use Ctrl+Shift+S, adding a bit more power to that dialog box. And we made sure that you could still add the old Style combo box to the QAT if you preferred that model (which has the advantage of reporting the dominant style for the current selection).
Linked Styles is functionality introduced in Word 2002 as the default definition of new styles. Its purpose is to allow the easy creation of ârun-inâ headings where only the first few words of the paragraph are formatted as the heading. This meant that the style could either be used on the full paragraph (as a traditional heading paragraph style) or on a range (as a heading character style) and both would pull to the same level in a Table of Contents.
In conversations with various people, including several MVPs, we agreed that being able to turn off the ability to apply to a range was very useful in some cases. This led to exposing the concept of a Linked Style a bit more aggressively in the UI so that people could explicitly define a Paragraph Style (prior to Word 2007, any paragraph style was automatically a linked style). And to allow me to add the âDisable Linked Stylesâ option to the Styles pane, which forces any linked style to behavior as a paragraph style â applying to the entire paragraph even when a range is selected.
The number structure in Word is extremely complex for a variety of reasons including the need to support scenarios that require that list structures and paragraphs each independently have indents. The most common scenario that I can easily describe is one where bullets are used to imply meaning and indentation is used to indicate importance. The classic of this might be red/green/yellow bullets for status and indent for priority. Itâs not the core scenario but it is one that Word has always supported.
Restart is one of the most challenging aspects of lists and I admit I can see several different ways we might have implemented it. Word treats restart as part of the definition of how the automatic behavior of the list should behave â you can think of it as training Word how to number. The reason for our current model is that in many list structures (most notably in legal), the restart is not based on the level immediately before but rather a higher level. Thus, you see structures like the following:
1. Level 1
a. Level 2
b. Level 2
i. Level 3
ii. Level 3
c. Level 2
d. Level 2
iii. Level 3
iv. Level 3
2. Level 1
e. Level 2
f. Level 2
i. Level 3
ii. Level 3
In this example, the second level (the lettered list) does not restart based on the first level but the third level does. Certainly these are not the most common structures â but they are ones that Word needs to support to appeal to its breadth of users.
One of the things thatâs not obvious about this type of structure is that you neednât actually have any bullet or numbering at a level. This allows you to define a level of plain text that will trigger the restart of a list. (Of course, using this sort of model is one of the cases that then pushes the need for more than nine levels of numbering â something weâll definitely consider in the next version).
Restart is very different then from a Start at value, which is used to associate a specific numbering value with a paragraph. You canât associate a Start at value with a paragraph style because in almost all cases, it is a better model to have all of the paragraphs within a given list level share the same paragraph style.
Numbering is ON Paragraphs but Paragraphs are IN Lists
The most common lists, those that have one or two levels with consistent formatting are easy to define. Itâs even relatively easy to see how several of these might work within the same document. And these are generally managed by our simple list UI, not needing the added complexity of a list style (or multilevel list). In these cases, the list is managed by the numbering being associated with the paragraph. And the UI for creating a paragraph style reflects this simple relationship. Multilevel lists (including List styles) exist for when the structure of the list is complex and when the ability to promote and demote among levels in the list is important.
I think the core confusion is the belief that you would ever apply a List Style to a paragraph â thatâs never been the intent or the internal structure. A List Style is used foremost as a structure for formatting a collection of paragraphs based on âlevel.â You might apply a list style to a group of paragraphs and thatâs why it has its own gallery on the Home Tab (which neatly highlights the members of the current list when you go to change the applied formatting). The second purpose is as a container to relate a set of paragraph stylesâto define how one moves among them using promote and demote actions. In that case, one applies the paragraph style, not the list style, to any individual paragraph.
To be clear, in earlier versions, it was possible to associate a paragraph style with a single level of a list structure. This was a flawed model in that it did not explicitly define the promote or demote behaviors for that paragraph style while given the illusion that more than the formatting of the single level had been created. The UI is reworked to emphasize that if you want a list format as part of a paragraph style, you need to be associating only the simply number formats (not a list structure).
Using Adjust List Indents should be updating the indents stored in the list structure. However, if you have created paragraph styles linked to levels within a list structure (rather than a list structure that contains paragraph styles at the various levels), then changing the indent would indeed change the relationship (because youâve in effect redefined the list that the paragraph is associated with).
The Poorly Named âIn Useâ
Word 2007 introduced a variety of ways for the style creator to organize the styles in the UI, stepping away from the solely alphabetical listing of previous versions. Part of the reason for that was to provide the sort of control that people had expected from the âIn Useâ string. At its most well-behaved, the âIn Useâ functionality reports any built-in style that has ever been used in the document and any custom-defined style in the document (whether or not it has ever been applied). I think the naming is unfortunate but so far no one has come up with a better description that wasnât significantly longer.