Chunking and organizing: headings - mike's web log/comments

March 19, 2012 | Chunking and organizing: headings | 1537 hit(s)

Microsoft Word has built-in styles for up to 9 levels of headings. It makes me think that someone wanted to be very sure that customers did not call Tech Support complaining about running out of heading levels. But it also horrifies me because, gah, 9 levels of headings?!?

Headings serve two purposes: chunking and organization. To generalize madly, the organizational aspect benefits writers, and the chunking aspect benefits readers. I've seen examples of both that I think are not doing it right.

Chunking: good. It's pretty well established that readers who are looking for information don't prefer long stretches of text. Chunking the text makes it easier to scan and provides some textual relief.

This can be overdone, tho. If you find yourself with headings that have one or two sentences each, maybe you're not really doing the reader much of a favor. Here's an example — look under Event Subscriptions. Does this section really need three subheads?

A more common problem I see is heading levels used to excess. In a long document, it does help (the writer for sure) to establish a hierarchy that reflects the organization of the material. I recently worked on a What's New document that runs about 46 printed pages and that features 3 levels of headings. (The table of contents (TOC) at the top shows a bird's-eye view of the structure.)

A problem with web-based content, tho, is when the user is flailing about in the middle of a long piece of content, heading levels are often not obvious. The reader has a sort of keyhole view of the text, and web pages are often missing the types of cues that a book reader might have (like running headers or bleed tabs) to help them suss out where within the content organization they might be. (Web pages often don't use indentation to mark content hierarchy, either.) If the content is linked dynamically to a TOC, that's great. But that's also rare.

One possible solution is to use "scientific" headings that use numbers (1.0, 1.1, 1.1.1, etc.) to mark heading levels. There's a good example in the Ruby on Rails Tutorial by Michael Hartl.

Note carefully that even tho Hartl's piece is book length, he never uses more than 3 heading levels. Because the book is delivered as separate chapters (one chapter per web page), in effect Hartl is really only using two levels in any given chapter/document. Hartl uses headings both as an organization principle and for chunking, and gets it right for both.

I maintain — perhaps because I am not all that good with nested-level stuff myself — that readers don't really cope well with anything beyond a third level. When I see anything beyond a heading level 3, I start getting very nervous on behalf of the user. If I see heading level 5, I start rending my garments.

More practically, I also start editing these headings away. Turns out this is rarely a problem. When I see heading levels 4 and 5 in a document, it almost always means that the writer is thinking too hierarchically and is forgetting that the reader is probably not subconsciously nested down there with the author at the 5th level.

So: use headings intelligently. Break up the text with headings. But don't impose a burden on readers to have to mentally keep track of where in your convoluted structure they are.

Brian 22 Mar 12 - 7:07 AM

For most of my publishing career, the templates we used only allowed four levels of headings, and the policy was that you'd better have a darned good reason for resorting to an H4. Eventually, some templates just dropped the H4s altogether. I often found that if the heading hierarchy was going that deep, the problem was on the other end -- the H1s were too broad, and needed reorganizing.

I'm curious what you think about the other two big heading issues: skipped heads and widowed heads. The skipped head is when an author has an H3 subordinate to an H1, with no intermediate H2. The justification is usually that the author feels the H3 isn't important enough to warrant a higher heading, but I can usually fix that.

Widowed heads were always the bigger problem. For example, within a given H2 section, there would only be one subordinate H3. As a rule, you could have zero subheadings, or two or more subheadings, but never just one. The idea was that using just one subheading means that you have a parallel topic in there someplace, but the heading is missing. The analogy we were told to use is that you can't divide a pie into just one slice. I got more pushback from authors on that issue than just about any other, with accusations of imposing "fifth-grade rules" and such.

mike 22 Mar 12 - 9:47 AM

First, thanks for articulating that the issue of H4s (and beyond) is often a problem at the H1 level.

Skipped headings do bother me. I see these in the surpsiringly common case of authors who want to typographically deemphasize a heading, and I have a very strong bias against misusing styles to get a specific look. I also see this when the writer is using a heading for a non-heading purpose, like wanting to emphasize the first sentence of each item in a bulleted list. (Unfortunately, Word encourages this via "linked" styles.) Generally we can sort this out; in most such cases, it's rarely the only organizational issue, as it turns out.

I think that enforcing a proscription on widowed heads is an example (or can be) where the writer's thinking about organization is trumping what the reader might need. To eliminate widowed heads, you'd have to believe that the reader is so aware of heading levels while reading that a "missing" heading is going to bother them. I suspect not so much. Then you'd "fix" the problem by a) removing the subhead, which might be there for chunking or b) artificially add another subhead, which can end up being there for the writer, not for the reader. I would love to see some research that tested this question. As noted, I strongly suspect that readers don't keep track of the number of subheads and balk when that number is < 2.

Brian 22 Mar 12 - 1:18 PM

Your thinking about widowed heads is pretty much the same as the conclusion I came to eventually. I can't imagine that readers ever notice, and although there are plenty of rules that editors enforce that readers never notice, this is one that I think we could let slide. Unfortunately, it's often a judgment call. About 75% of the time, I could remove the widowed head, or insert another, parallel head, and improve the text by doing so. But it was the remainder of the times that bugged me, when I found myself saying, "Yes, this topic is clearly subordinate, and deserves a new heading, but it really doesn't have a parallel, so...it's a legitimate widowed heading." When I'm working for a client, I have to enforce the client's style rules, but it's one of those things that's said in hushed tones to other editors: "Maybe we don't want to enforce that one all the time."