A lot of the information design being done in technical communications today is what I think we can fairly call a linear/hypertext hybrid. Perhaps this is a necessary stage in our evolution from static linear paper manuals to dynamic hypertext information sets, but if so we have lingered in it far too long, and we are still producing and using tools and systems that are designed for the linear/hypertext hybrid rather than for true hypertext.
This thought occurred to me when reading Tom Johnson’s post on collapsing sections. As I commented there, collapsing sections are a symptom of the linear/hypertext hybrid. They are hypertext in the sense that you have to click a link to open the section, but still linear in the sense that they are written and organized as part of a single consecutive narrative. As such they have some pretty significant problems, as I noted in my comment on Tom’s post.
- If collapsing sections are being used simply to shorten a long narrative passage, they just force the reader to do more work to read the narrative.
- If collapsing sections are being used to make ancillary information available to users who might need it, that is what links are for. To place ancillary information inline will almost certainly mean duplicating it in several places, as it is likely to be ancillary to more than one topic.
- Worse still, if it is ancillary to more than one topic it may not get included in other places on the old paper-world argument that it is already in the manual somewhere.
- And even worse, there probably won’t be a link to it in those other places where it might be wanted, and even if there is, such a link will probably lead to the page that contains it in a hidden section, not to the ancillary information itself, making it very difficult to find.
- Worse yet again, as well as being ancillary to a number of topics, it will probably also be an important topic in its own right to some readers, who are going to have a hard time finding it when it is buried in a collapsed section of another topic.
But this is not the only symptom of the linear/hypertext hybrid. The entire concept of tri-pane help, with its expandable table of contents, is a linear/hypertext hybrid. By placing a collapsing TOC to the left of the content, we essentially invite the reader to view the content pane as simply the current expansion of one node of the document, the structure of which is modeled in the TOC pane. Again the design is superficially hypertext, while actually remaining fundamentally linear.
The basic problem with linear/hypertext hybrids is that they make for lousy hypertext systems. Despite the division into topics (or something we might call topics if we are generous in how we define that term — certainly not always Every Page is Page One topics), and some use of linking (usually very little) it is still the linear model that dominates the design. Try to use it like a hypertext system, however, and it stubbornly refuses to cooperate. This is at best linear design in a cheap knockoff of hypertext’s clothing.
Part of the ongoing attachment to the linear/hypertext hybrid may be that it makes it easy to create book-length PDFs. Creating a PDF from material organized for a linear/hypertext hybrid is trivial. The material is already in linear order and all you have to do is convert its topic hierarchy into a conventional book hierarchy of chapters, sections, and subsections. But if you must create a book-length PDF, you can do so by creating a linear collection of Every Page is Page One topics — or smaller collections more suited to an individual reader’s immediate needs.
More fundamentally, though, I suspect the continuance of the linear/hypertext hybrid is a result of a deep-seated cultural hangover. Despite living in a hypertext world, we are still very much book-normative in our attitudes to content. We use hypertext, but we still venerate the book form. We design to content to conform to past norms rather than to work for current readers.
But even though our readers themselves may have book-normative prejudices, they are more and more Web normative in their behavior all the time, and the Web is not organized like a book.
We have to start thinking, writing, and designing in hypertext terms. Make each topic self contained, treat only one subject, and link richly to ancillary material. Every Page is Page One.
For help breaking out of the book-normative forms of the last century and moving your content into the hypertext world of today, contact Analecta Communications Inc. today.
“…I suspect the continuance of the linear/hypertext hybrid is a result of a deep-seated cultural hangover. Despite living in a hypertext world, we are still very much book-normative in our attitudes to content.”
That paragraph is a perfect summary of this problem. Most tech writers have a history of creating manuals (books), trained with tech writers who did that, or learned how to write manuals n tech writing classes (#1 and 2 for me). I also have tech writer friends who would love to focus on online-only docs, but they’re forced to create PDF manuals to comply with outdated regulations. (And the PDFs get filed away, unread.) Most doc tools offer more support for creating manuals than creating “true” online documentation.
Thanks for the comment, Neal.
I agree with all you say. Another problem is that many executives are book-normative as well. They may not use books to solve their own technical issues, but when they give 7.5 seconds of thought to the question of what they want in their company documentation, the book norm is likely to assert itself, leading them to demand PDF manuals.
That is, of course, until they have some sort of a-ha moment about the fact that their customers are actually on the Web, at which point they usually give the documentation staff the same 7.5 seconds to move their content to the Web.
This is why I think it is important for tech writers to move to Every Page is Page One, even if they are still being asked for manuals. You can collect Every Page is Page One topics into a manual, but when it comes time to move to a Web-friendly format, you will be ready to respond.
Hi Mark,
you are so spot on on this one, I could run away yelling 🙂
What you describe here is exactly the issue I’m facing with my current project.
My customer required me to update some service manual from one product generation to another. The output is done as a book length PDF with approx. 800 pages.
As I’m the first external writer to update such a manual, the review process has been done very thoroughly and – surprise – I had a ton of corrections on parts, that didn’t change for years, neither in the documentation nor in practice.
This clearly shows, that this PDF never has been read – despite the fact they use this very manual for training their own service staff.
In theory this manual is thought for printing, but it’s simply impractical (none of those service guys will ever take a 800 page paper manual on tour).
It is even written in a somewhat basic EPPO style, but with sparse linking and redundant information all over the place (which is partly responsible for those 800 pages).
When I’ve been asking, if that information could be placed non-redundant, the answer I got was, that, if someone prints the manual, they don’t have the information in place where needed.
Thanks for the comment, Alex.
One of the side benefits of a move to EPPO is that you tend to get far better reviews. People reviewing books get highway hypnosis and drive right by gaping errors and omissions.
The duplication of content is a major issue for monolithic linear media, whether they are printed or not. My rule of thumb is that people should not have to click to keep reading their current thread. Links are for ancillary information. This does involve some duplication of information, but this is manageable with even elementary structured writing tools (not to mention several unstructured tools). And in a non-linear collection of independent articles, it does not have a lot of downsides for the reader.
That said, there are many cases where repetition in a linear text should be replaced by linking in a hypertext environment.
The web-based perspective (and EPPO) is good for many things such as non-confidential software user guides, but less suitable for highly complex confidential documentation.
Ideally we would create some sort of deliverable mini-web to them complete with all of their confidential documentation – until then we will deliver PDFs. Even with PDFs of course there can be opportunities toward topic-based writing.
Thanks for the comment, Michael. I get that comment a lot — that EPPO is suitable for less complicated things, but not for more complicated content. The truth is actually the reverse. The top-down book approach works for problems of small to medium complexity, but fails for highly complex things.
The hierarchical organization of the book model does not scale well as the amount of content rises, and for complex material — material whose subject matter contains many complex relationships — it forces the organization and relationship of the content into a single hierarchy which effectively breaks most of the important relationships in the content.
We have seen the EPPO model become he default model of the Web precisely because of the size and complexity of the information collection that is the Web. Truly huge sites like Wikipedia, which house content that expresses extremely complex relationships, work entirely on a bottom-up, Every Page is Page One model.
As far as confidential documentation is concerned, in most cases, keeping documentation off the Web is simply a mistake, which damages the reputation of a company by making their products harder to use due to lack of easy access to helpful information. For cases where confidentiality is required, however, I agree with you that delivering a mini-web is the right approach.
Since XML is hierarchical, whether it is used to deliver books or not, would any XML model be suitable for interlinked nodes of content containing many complex relationships?
Would a graph database model be more suitable for EPPO?
Thanks for the comment, John.
XML is fine for the structure of individual XML topics (hierarchies work fine at a small scale). But you are right that the XML model is not so good at expressing the relationships between nodes in a bottom up information architecture. This is not to say it can’t be done in XML. The DITA approach of a hierarchical map is not the only one you can express in XML. TopicMaps allow for the arbitrary expression of multiple relationships on multiple axes — which I guess is a way of saying that TopicMaps are a form of graph database.
Anyway, yes, a graph database seems like an appropriate way of expressing the rich linking along lines of subject affinity that EPPO calls for.
I’m re-reading EPPO, and I can see parallels with my thinking that web documents can be fragmented into thousands of very small web pages with brief snippets of reference information. Those snippets have only enough detail to give the user what they want without any introductory information. The model breaks out of the linear narrative of book forms by providing information in standalone micro web pages without any introductory text that you find with conventional tech writing. The trick is bringing all those disparate standalone topics together in one place, and visual technologies such as SVG could be the key.
Thanks for the comment, Dave.
I don’t think of EPPO in terms of fragmenting documents. Indeed, the point of EPPO is that every page is an independent document, not a fragment of something larger.
In that sense, there is no requirement to bring them together in one place (I would suggest that place has very little meaning on the Web). They are connected to one another by links, but not assembled into any larger whole. They may be included in collections of related topics, but even then, the collection is virtual, and one topic could be a member of several collections.
While lengthy introductions are not needed in an EPPO topics (it only does one thing, so there is not a large amount of material to introduce), context setting is vital. Often the so called topics we encounter in “topic-based” tech comm today are so devoid of context setting material that they only make sense at all in the sequence or hierarchy of a larger book or help system, and the reader is often forced to navigate that hierarchy to discover the context of the topic they first landed on. Fragments are not topics.
Ashley Force-Hood posted her personal best time in this Facebook/cell amusement and
under no circumstances use up galaxy legend hack apk the points you
call for. But here’s the thing about system diversions
accessible on ios and Android they’re all fundamentally the same.