Every Page Is Page One: Topic-Based Writing for Technical Communication and the Web Paperback – 18 Oct 2013
|New from||Used from|
- Choose from over 13,000 locations across the UK
- Prime members get unlimited deliveries at no additional cost
- Find your preferred location and add it to your address book
- Dispatch to this address when you check out
Frequently Bought Together
Customers Who Bought This Item Also Bought
Enter your mobile number below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
Getting the download link through email is temporarily not available. Please check back later.
To get the free app, enter your mobile phone number.
About the Author
Mark Baker has helped set up an industrial workshop for autistic adults and has worked for some of the major manufacturers of woodturning tools in the U.K. He is now the editor of Woodturning magazine and the group editor of all GMC Publications woodworking magazines. Previous books include Woodturning Projects: A Workshop Guide to Shapes, Wood for Woodturners and Wood Turning: A Craftman s Guide, all published by GMC Publications
Most Helpful Customer Reviews on Amazon.com (beta)
Because of my dual role as a database specialist and technical writer, I know Microsoft SQL Server documentation very well, but it was not after reading this book that I realized why this documentation is so well structured and comprehensive, and why this type of writing is a pattern to follow. The same can be said about Wikipedia, which is an example used in several chapters. This book provides a compelling argument against traditional books or book-style user guides and manuals, and explains the fundamentals to write documentation your users and customers will find -finally- useful. Isn’t this exciting enough?
The only thing I missed was more examples. If you open the book this may seem contradictory, because it has plenty of examples and metaphors that makes the explanation easy to follow (I particularly liked the “recipe” example), but I am referring here to examples using “real” technical documents. In this way, I think it would be great to have some examples about how a chapter from one “traditional” manual can be rewritten in an "EPPO way”, or how DITA and EPPO can both work together in a topic. Yes, I know after reading the book this is not as simple as it sounds! :)
Overall, this is an excellent book, well thought and well researched, and plenty of fresh ideas in a field that is particularly stagnant and, in most of the cases, lacks innovation. As part of my development into the technical writing and communication field, I have read several books about the subject, and this is by far the most revealing and helpful one.
If you are reading this and have something to do with technical writing, buy this book. This small investment may have a great impact in the way you think and work around technical writing.
same behavior in his research subjects using paper manuals.
Learners also often skip over crucial material if it does not address their current
task-oriented concerns or skip around among several manuals, composing their
own ersatz instructional procedures on the fly.
—The Nurnberg Funnel[8, p. 8]””
This quote is taken from the introduction to Chapter 1 in the book, “Every Page is Page One”. How apt it is! I do this very thing and skim through a manual trying to find how to do a particular task, and get frustrated when it isn’t there. Then I have to go back and read it again to find what I missed. Of course, many times what I’m looking for isn’t there anyway, but until I do read it I don’t know that. Either scenario is frustrating. Even on the web, sometimes I find it incredibly hard to find something on the website that I’m looking for.
I have learned from this book, and one of the most important thing is to make sure people can find the information I’m writing about by treating each page as if it is page one. I suppose I never stopped to think that deeply about it. But then it’s rather hard to have each important point to be the first sentence. However, I can make use of white space and create snippets to the side of the documents which will tend to hi-light information, similar to how the book is written.
If you write technical manuals, either hard copy or web copy, this book can really help you. It helps by giving you a ‘window’ into how your readers use the material. I skim, even when I search for something, but then I click on a link and I skim again, when not finding it, I will slow down and actually search for the word on the page. Click back or close the tab and move on to the next. I love to read and I’m an avid reader and I love to learn, but I just don’t have to search the whole manual to find two sentences that tell me how to do something I’m trying to do. Little snippets, and especially either a table of contents or an index will be most helpful.
I appreciate the work the author has put into this book, and I have learned from it. Now if I can just remember how to place little snippets in my work. LOL.
I highly recommend this book to others, regardless of which kind of writing you do.
Could have been much tighter. Seemed to be a lot of repetition, which would be resolved, in part, with better organization.
I wish it would have suggested some ways to measure the success of an EPPO initiative. Are there Google analytics that are useful? What else?
Even as an appendix, an example - from beginning to end - would have been worthwhile. It's one thing to show examples that already meet EPPO standards, but it could have been more meaningful to show a before and after accompanied by an explanation that anticipates the real-world issues that may come up in applying these principles.
What Baker does is give tangible form to thoughts and ideas that he, other technical writers, and even I have had in the abstract. How do we provide needed information to people who seek it in an age where the web makes almost anything searchable? Do manuals still matter? What about other forms of documentation? Are there changes to our style of communication, to our style of writing and presenting information, that will make the information seeker's task easier? Baker discusses serious and realistic ways we can improve our field.
I enjoyed reading this book. I have benefited personally from reading this book. I am taking this book in to my workplace and sharing it with the other tech writers there and I believe our workplace and our employer and our customers will benefit from this book. If you work in the field, I'm convinced you will, too.