More and more writers are encountering Agile programming, and often find themselves trying to fit the content development process into an Agile development process. Because the shift to Agile is driven by the development organization, it can often be an uncomfortable fit for content developers.
Agile can be seen as the principles of Lean thinking applied to the development of software. Lean is a system of principles and practices, originally developed by Toyota, and now used across many industries. Every process, every function, and every organization that adopts Lean principles applies those principles to develop lean processes that are specific to their industry, their function, and their company.
Taking the exact procedures that make sense for software development in you company and attempting to apply them directly to content development may not create the best content development process. Creating a Lean content process that integrates well with the Agile development process may work much better than trying to force content development into an existing Agile mold.
This session will take you back to the principles of Lean thinking and Agile development and give you the opportunity to consider what a Lean content development system might look like for your organization, and how it can enable you to create more content in less time — even if your development organization is not doing Agile at all (or is doing it wrong).
Readers dive into the middle of your content using search, links, or indexes, but often find themselves lost in the middle of a long consecutive narrative. Even when the content is produced using common topic-based writing techniques, it often organized like a book, and individual topics do not work well as a starting point for the reader. On the Web, in particular, readers can come from anywhere and land anywhere. Is your content ready to receive them?
People seeking information on the Web are impatient and have many options to choose from. If your content does not work for them immediately, they will move on. Expecting them to navigate complex hierarchies to find the information they need just won’t cut it with this audience. Whatever page they land on has to work for them immediately. It has to be page one.
Whether you deliver on the Web, in a help system, or on paper, we now live in a world in which every page is page one. You need to provide your readers with Every Page is Page One topics, or they quickly become someone else’s readers. In this session you will learn how to write Every Page is Page One topics that work for the reader no matter how they land on them.
Mark Baker is Principle Consultant with Analecta Communications Inc., and author of Every Page is Page One: Topic-based Authoring for Technical Communication and the Web from XML Press. He has been practicing and implementing structured writing since the SGML days, and gave his first paper on topic-based authoring at SGML 95, under the title “Component Based Information Development”. His previous positions include Manager of Information Engineering Methods at Nortel and Director of Communications for SGML pioneer OmniMark Technologies. He blogs on topic-based authoring at everypageispageone.com. He is also the creator of the SPFE (“spiffy”) architecture for structured authoring and publishing, which is described at SPFE.info. He tweets as @mbakeranalecta