Archive for July, 2013


Word: Use multiple outline numbering sequences in the SAME document or not?

July 11, 2013

Recently, I had a single document to edit that the author had divided into four parts. She had used separate outline numbering sequences for the headings within each Part. In other words, she had Part I, sections 1.1, 1.2, 2.1, 2.2, 2.3, etc. AND Part II, sections 1.1, 1.2, 2.1, 2.2, 2.3, etc. AND Part III, sections 1.1, 1.2, 2.1, 2.2, 2.3, etc. AND Part IV, sections 1.1, 1.2, 2.1, 2.2, 2.3, etc. — all in the same document.

I queried her about the use of these multiple sequences, as I believe they can cause problems for readers, reviewers, and current and future authors.

My reasons against multiple outline numbering heading sequences IN THE ONE DOCUMENT:

  • Word really doesn’t like them and I don’t believe Word was designed to deal with them effectively
  • Table and figure caption auto numbering is repeated in the list of tables/figures, so you can’t easily refer someone to Table 1.2 as there could well be four instances of Table 1.2 in the document. Ease of readability and comprehension is compromised by using multiple sequences — you WILL frustrate your readers as a result!
  • Word’s auto table and figure captioning sequences could reset themselves at some point (remember, Word isn’t designed for this sort of repeat auto numbering)
  • Cross-referencing is made more difficult for authors as there are multiple instances of section numbers, table number, figure numbers, so selecting the correct one becomes problematic
  • If reviewers are doing a round-table document review and are told to go to Section 1.2, for example, which Section 1.2 do they go to? If you have four Section 1.2s, then that becomes confusing, frustrating, and annoying
  • Updating the fields in this document took a LONG time; I suspect this was related to the multi-sequence numbering.

Possible solutions:

  • Either use an unused Heading style (e.g. Heading 9) or create a new style for the Part I, II, III headings and add that style to the TOC as a Heading 1 TOC level. That way you shouldn’t upset the existing heading numbers.
  • Set the Part numbers as Heading 1s only and demote all other heading levels by one — i.e. current H1s become H2s, H2s become H3s, etc. Easy enough to do, especially using the Outline view ‘demote’ buttons and demoting the lowest headings first (i.e. demote H3s to H4s first, then H2s to H3s, then H1s to H2s, then apply H1 to the Part titles).
  • Keep the existing H1s, but make them one long sequence, so Part 2, for example, would have its first heading numbered as 3.0 if Part 1 has two subsections.
  • Separate this document into four different documents, one for each Part. While this is easy enough to do, it is just as likely to be as frustrating for readers as multiple number sequences in the one document, so consider this option carefully.

Bottom line: You need to make a decision about your outline numbering sequence for headings that will NOT upset your readers or reviewers or cause them frustration, will not create further problems with broken cross-references, and will make it easier for you or any other author to continue work on or update this document in the future.


Word: Getting an Excel table into Word

July 10, 2013

Typically, you have two choices when you want to insert an unlinked Excel table into a Word document:

The choice you make will depend on what you need to do – or not do – with the data once it’s in Word. If you don’t need to modify it, then insert it as an image; if you do need to modify it, then insert it as a Word table.

Related articles:

For inserting a linked table and other options see:

[Links last checked July 2103; based on a Writing Tip I wrote for my work colleagues]


Should you fix the window size in Help?

July 1, 2013

B asked:

I wanted to set the size of the XHTML window when the user brings up the help. I did a search and found your script to set the initial window size, which worked great. I would, however, like to set the window size so that all of the text fits in a pre-determined window size and the user does not have to scroll to see content. Would you know how to do that and be able to help me?

My response:

I’m not sure how much I can help you as I’ve hardly worked with any form of HTML/XHTML in several years. And when I did, I didn’t set the window size as the user can do that themselves, if they want.

That said, let me ask you a few things.

  • When you say scrolling, are you talking about vertical or horizontal scrolling? Vertical scrolling is generally unavoidable unless you make your topic content short enough, and even then, if the user increases the font on the fly, the scroll bars will still appear.
  • Do you have tables or images in your content? If you do, then horizontal scrolling may be unavoidable too, unless you make those tables % widths (whole table and columns), and you make the images % widths (even then, I’m not sure that the images will resize to fit the available viewport of the window).

By default, your text content should wrap within the viewport, so at worst you may have vertical scroll bars if your text is long. But tables and images may not fit within those dimensions and thus create horizontal scroll bars for those topics.

I think you also need to do some user research and find out if your users *want* a fixed window for the Help. Personally, I wouldn’t be happy if someone set the window size or position and I couldn’t resize/move it. In fact, I’d get angry that someone presumed they knew how I read Help or how I wanted to read Help. For example, I use two monitors (as do many people), and will put the Help on one monitor while I do the task in the app on the other one. Windows size is unimportant under those circumstances, unless of course it is too small, or resizes itself to a fixed size/position, when I would curse the Help developer every time I went to a new topic and it resized, or every time I opened the Help. I would give up on that Help very quickly.

And I deliberately say do some *user* research – what your bosses want may well not be what the users want, and the users are the ones who read the Help, not your bosses. The user wants to get in and out of the Help quickly, wants to be able to find what they are looking for quickly (have you accounted for a long/wide TOC in the window size?), then get on with their task. If they have to continually resize a fixed window (or if they can’t resize it!), then that distracts them from that task. And if a user resizes the font so they can read it *at a size that suits them*, then all the fixed sizing you do is moot.

Also, if your app is available for mobile devices or other small form factor devices, then a fixed window size will be MORE than a pain for the users.

Finally, have you considered how people who don’t have 20/20 vision might view your Help? If it’s in a fixed windows size, then they will get the scroll bars when they resize the font no  matter what.

Bottom line: Don’t do it.