Every Page Is Page One
The following is a guest post by Mark Baker.
The a-ha moment came for me reading David Weinberger's Everything is Miscellaneous, a book Tom and I both admire. Weinberger's central thesis is that miscellany has become more powerful than order. No one ordering of information is ideal for every reader. The web allows readers to find information for themselves, and to organize it for themselves and for others. The power to organize content, Weinberger argues, has passed from the creators of content to the consumers.
What have we always told people our job is? Organizing content so people can find it. That's how we have justified our existence to sometimes skeptical development and product managers. You need us because we know how to organize information. If you leave it to the developers, it will be a mess and no one will be able to find anything. Miscellany bad. Hierarchy good.
Not so much, it turns out. By digging and liking, and tweeting, and tagging, readers lay down their own paths through the content, paths that are non-hierarchical, miscellaneous, and increasingly well travelled. This is a battle that has been fought out on a global scale. On the side of hierarchy and order was Yahoo, which set out to catalog the entire web with a legion of human editors. On the side of miscellany was Google, with a whacking big search engine. Remember who won? It may put you in mind of an earlier battle between man and machine: John Henry hammering in the mountain, trying to beat the steam drill, until the handle of his hammer caught on fire.
What then must we do? Die with our hammers in our hands? Or find a new way to do this job? Because it is no longer in our power to control the order in which readers read our content. They will read it any way that suits them.
In the age when the search engine is king, writers can no longer direct where the reader will land in the documentation, what they will read first, or what they will read next. The reader may begin anywhere, and that means that any page may be page one for that reader. And if any page may be page one for someone, what that really means is that every page is page one.
That was the a-ha moment: Every page is page one. Any page is as likely as another to be the first page the reader sees. There is no first, last, previous, next, up, or back. There is only page one. This page, that page, every page: all page one.
What if the page that the reader lands on does not work as page one for them? Where do they go? Backward and forward through the document hoping to find page one? No. They go to the next page listed in the search results, click on that, and that becomes their next page one.
Now, you may argue, this may be true on the web, but our docs are not on the web. We have a self contained help system, and we have the power to designate page one for our readers, to structure the reading experience for them. Alas, it is not so. Twenty years ago, readers came to help systems from the world of books, and they expected them to work like books. Some of the more interesting experiments in help system organization actually got smothered out of existence early on by the reader's demand for a familiar book-like organization of the help system. Help systems vendors and authors complied, and help systems have pretty much been organized that way ever since.
But readers no longer come to a help system expecting it to work like a book. We are all children of the web now, and we come to any information system looking for the search box, and expecting the search to work like Google. Recent user feedback that I have been reviewing made this very clear to me. Our users see the documentation as one thing, not a collection of books, but one seamless whole, and they expect to find things by searching the entire doc set from one place.
If anyone in the tech pubs business thinks they are being innovative by moving from books to topics, I'm afraid that innovative is not the word for it. A little less behind the times that the rest would be a more honest assessment. Our readers are way ahead of us. They are already treating our documentation as if were a collection of topics, and being disappointed when the first topic they land on does not meet their needs, does not work as their page one.
Every page is page one -- this is a fact, not a choice. Making every page we write a good page one -- that is a choice. And this, I believe, is the single most important thing we must learn to do as technical writers. To be sure, many trends are claiming our attention, and there are a dozen new things every year that we are told we absolutely must master if we hope to stay relevant. But in the end, we exist to give people the information they need to do their jobs, and the way to do that is to create content that works for them no matter how or where they find it. If we do everything else and forget this, we will fail. If we do this and forget everything else, I think we will still succeed.
We will still succeed, even if we do get everything else wrong, because the Iron law of the Internet is that good content gets found. Thousands of recordings, mostly abysmal, are uploaded to YouTube every day. There is no sorting, no editing, no promotion. Yet the great ones go viral, usually within hours. Content that deserves to be found, gets found.
What then must we do? The answer, I am convinced, is that we must write every page as if it were page one. What does that mean? How do we write every page to be page one? That is apt to be a large subject. I don't have all the answers, but I am exploring the subject on my blog, Every Page is Page One. I hope you will join in the discussion and the exploration, both here, and there.
Mark Baker has been a technical writer for over 20 years and has worked on topic based authoring, structured writing, single sourcing, and SGML/XML for almost as long, including a stint as Director of Communications for SGML pioneer OmniMark Technologies. He has designed and built topic-based authoring systems and has spoken and written frequently on topic based writing and the applications of markup technology. He is currently Senior Staff Technical Writer at Wind River System. He blogs at everypageispageone.com and tweets as @mbakeranalecta.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.