What We Do Differently
The short answer to what we do differently is: Just about everything. But here are a few of the ways in which we differ.
We start with a complete set of writing methods
It may sound hard to believe but we don’t know of another publishing company that has an inhouse manual for authors and editors that shows how to do every phase of writing a book. Oh sure, most companies will have a “style manual” that covers subjects like how to capture screens and how to format captions, callouts, new terms, and computer code. But you can get all of that right and still end up with a book that doesn’t teach the skills that the title promises.
Our inhouse manual, How to Write
a Murach Book, provides detailed
guidelines for doing every phase
of writing a Murach book.
In contrast, our inhouse manual, How to Write a Murach Book, provides detailed guidelines for doing every phase of writing a Murach book, including:
- How to develop the table of contents for a book
- When and how to develop the applications for a book
- How to plan the contents for a chapter
- How to develop the figures that storyboard each chapter
- How to write the first draft of the text for each chapter
- How to develop the exercises for each chapter
- How to prepare the final draft of each chapter
As we see it, those are the critical skills that authors need to master before they write a technical book.
Our writing methods continue to improve
Mike wrote the first version of our inhouse writing manual way back in the 80s, under the title Structured Technical Writing. But we continue to refine and improve those methods. In fact, we like to think that we’ve learned something from every author we have worked with.
About 15 years ago, for example, we realized that there was something wrong with almost all technical books, including ours. The problem was that readers had to dig out the skill-building information that they needed from pages heavy with text. Then, to review that information, they had to dig it out again. That’s when we developed a new presentation method that we now call “paired pages.”
With this method, each topic is presented in a two-page spread. The page on the right presents the examples, coding, and critical skills that you need to master, and the page on the left explains and enlarges upon that as needed. The result is that you read less and learn faster. And when you’re done with the book for training, this is the perfect format for on-the-job reference.
Today, we use our paired-pages presentation method in all of our books, and we’re the only publisher that does. That gives our books a distinct advantage over all of the competing books. But honestly, that’s only one of the reasons why our books work so well.
Our inhouse editors enforce our writing standards
For many years, all of our books were written and edited by our staff of trained writers and editors. In those days, it was easy to enforce our writing standards because everyone was trained by Mike!
In recent years, though, we’ve been teaming up our editors with outside authors. To make that work, the authors start by reading How to write a Murach book. Then, as the authors deliver manuscript, our editors provide training that helps the authors improve their skills until they’ve mastered all of our methods.
Our editors are able to enforce our standards and help train our authors because they are technically competent. That means that as they edit a book, they learn the subject themselves, as part of the editorial process. That way, they can catch technical errors, test applications, make suggestions for improving the content organization or the coding examples, and help improve instructional effectiveness.
If this sounds like the way every technical publisher works, you may be surprised to find that it isn’t. Often, for example, the editors don’t understand the content that they’re editing. So they can fix grammar, punctuation, and formatting errors or manage the schedule or budget for a book, but they can’t improve a manuscript in any significant way.
That of course means that the quality of the book is left in large part to the author. But remember that the author gets no training in the best methods for organizing and writing a book because the company has never established any.
We don’t make “camels”
Ever hear the expression, “A camel is a horse put together by a committee”? Well, we don’t make camels. Instead, for most of our books, one editor teams up with one author. When the manuscript is complete, a third person may be one of the proofreaders or maybe help develop some of the instructional materials, but that’s usually as far as it goes.
In contrast, take a look at the credits at the start of many competing books. For instance, a simple book on Joomla! gives credit to the author, two reviewers, an acquisition editor, a lead technical editor, two technical editors, a project coordinator, and two proofers. To complicate that, only a couple of them work for the company and a few aren’t even in the same country. Camels, anyone?
Even the trim size of our books is different
Ever notice that most technical books are from 7 to 7 ½ inches wide by 9¼ inches tall? That’s because most printing presses are optimized for that size so the cost per book is cheaper.
In contrast, our books are 8 inches by 10 inches, even though that size costs more to print. We’ve used that size from the start, even when the extra cost hurt, because that size is better for listings of programming code. And it still is.
When we started using our “paired pages” method of presentation, that size became even more valuable because it accommodates more information on a single page. It also works better for screen shots and diagrams and all of the types of illustrative material that you’re likely to find in a programming or web development book.
That’s just another example of our dedication to excellence. And by now, that dedication has become a way of life for all of us.
