An Issue in Review
I often receive questions, especially from new authors to the magazine, about what it takes to put out an issue of the magazine, what our schedule is behind the scenes, and so forth. We spend a lot of time working to make MSDN Magazine and TechNet Magazine quality resources for you, and as such I thought some of you might have similar questions. I'm currently stuck in the Dallas airport waiting through what can only be described as a comedy of errors, so it seemed the perfect time to take a few minutes to describe our processes.
An issue begins many, many months before it ends up in your hands. Approximately six months before the first issue of a calendar year, let's say the January 2008 issue, we decide on our column schedule for the next calendar year, in this case the January 2008 through December 2008 issues. These decisions are malleable and do change over time, frequently in response to your feedback about your interests and content desires for the magazine. Nevertheless, by July 2007, we have a pretty good idea of what our columns will look like for the following calendar year of issues. Note that this doesn't mean actual column topics. For example, we may decide that the Security Briefs column will run every other issue starting with the January 2008 issue, but that doesn't mean we decide at that point in time what each of those columns will be about. That would be silly; in an industry that moves as fast as ours does, how could we possibly predict what would be relevant so far in advance? On the contrary, we take pride in the flexibility we provide to our columnists, and it's usually the columnists who take the lead, with some direction from us, on what a particular column will be about. And that decision doesn't need to be made until a few months before the cover date for an issue. As an example, the columns for the January 2008 issue will need to be written and submitted to us by September 15th, 2007. That may seem like a long time, until you consider that the January 2008 issue is actually in the mail to subscribers at the end of November 2007 (it may even be in some subscriber's mailboxes by then), and is online for everyone to view for free by mid-December 2007. In order for the January 2008 issue to be in the mail stream by the end of November 2007, we need to have it to the printer by the beginning of November 2007. That means we have around six weeks with an issue from the time the content is in to the time we need to ship it out; not a whole lot of time to put out a complete, top-of-the-line product, especially when you consider that our team (which does both MSDN Magazine and TechNet Magazine), has to ship twice a month to handle both magazines.
At the same time columns are due, the feature articles for the issue are due. Feature articles are typically assigned anywhere from two weeks to three months in advance of their due date. Whereas the topics for particular column editions are mostly determined by our columnists, with some guidance and input from us, we take a much larger hand in determining the topics for feature articles. These days, in a typical month, we'll receive upwards of 60 article ideas/proposals, some from authors who have written for us previously, some from members of the product teams or other groups here at Microsoft, and some from talented folks in the community we haven't had the luxury of working with in the past. In any given issue, however, we typically only run five to seven feature articles (along with typically 9-12 columns). This is a vast amount of content, no less than 80 pages of content and frequently closer to 90 or more. But even with that, we don't have space to run all of the content we'd like to bring to you each month. As such, we have to make hard choices in narrowing those 60+ submissions into the 5-7 we can handle, and that doesn't include the articles that are generated as a result of us reaching out to specific individuals to create specific content we desire (which typically amounts for 1-2 articles in each issue).
As a note to those folks interested in writing for the magazine or who have submitted proposals in the past that haven't been accepted, please keep these numbers in mind when you submit ideas. We genuinely want to hear all of your ideas and are excited to receive them, and frequently a rejection is simply due to us not having enough space. Of course, sometimes rejections are due to other reasons, such as us already having run or planning to run similar content, an abundance of content on similar topics elsewhere accessible to our readers, the timeliness of the topic, or any one of a myriad of other reasons. Please don't let this discourage you; we want to hear from you, and if you have a good idea (or better yet, several ideas) for articles you feel will be timely and very useful to the general Microsoft development community, please send those to us. The best way to submit proposals is at mmsubmit@microsoft.com or tnsubmit@microsoft.com (for MSDN Magazine and TechNet Magazine, respectively); we review every single submission we receive and do our best to respond in a timely way, but if you don't hear from us within a week or two, please resend your proposal as it likely got lost somewhere along the way. My friend and counterpart on TechNet Magazine has already written a good post on the TechNet Magazine blog about what makes for a good submission, so I won't reiterate that here.
Once all of the content for an issue is in, our editorial and art team get to work on it. The styles and formatting necessary for a quality print publication are pretty complicated (I frequently get them wrong), so we don't require our authors to use them, and instead request that articles be submitted in Word docs (.doc or .docx format) with simple styles and formatting. When articles come in, our art team then formats them appropriately using our print styles. In addition to formatting the document, we also run several tools over the articles to manipulate them in several ways. For example, we wrote a tool called EgCop (named after the popular FxCop) that finds common problems with articles and automatically corrects them when possible to meet our editorial guidelines around acronym usage, product naming, common capitalization issues specific to Microsoft development, and so forth. EgCop will also highlight potential problems that don’t have an obvious fix, so that it's called out to an editor when following up later.
Our art team also does preliminary reviews of all artwork in the article (screenshots, diagrams, and the like) to make sure that they were generated appropriately. Diagrams are all redrawn by the art team in order to ensure that they're not only clear and consistent, but in-line with the visual style of our magazine (using our color palate, fonts, and so on). Screenshots are edited when necessary to ensure they're as useful as possible (cutting out extraneous elements that would otherwise confuse the core message, and so forth). Screenshots are also checked to ensure that they were taken correctly. All of this formatting takes a bit of time, which is why when an author has to make changes to an article after its been submitted, we ask that they first contact us to find out the best way to get those changes integrated. From the moment the initial article is submitted to us, we've forked a version, and thus an author just submitting a new doc with changes really complicates things and frequently wastes time, which is not something we have a lot of to spare.
All of our articles exist in a source control system. The initial article submitted by the author is checked in, and from then on all changes to that article are tracked. Every time someone from our team needs to modify the doc, be it to edit the text or to work on its figures or diagrams, the document is checked out, modified, and checked back in. This enables a variety of things. For one, we can easily track all changes made to documents, who made them and when, and we can roll back to previous versions should the need present itself. We can also do more interesting things. For example, I wrote an app that analyzes the changes made during each edit phase. The app is then able to provide statistics on the types and amounts of changes made during each editorial phase, which can provide interesting insights into things like the quality of an article when it was submitted. A variant of this application can also be used for plagiarism detection, whether between a given article and a previous one written by the same author (to copy from one's self is still plagiarism, and still unacceptable) or between that article and something previously published on the Web, for example.
As mentioned, once submitted an article is formatted and is run through all of our art checks. Once complete, our terrific editorial staff dives in. The first edit is typically a "developmental edit", or "dev edit" for short, done by one of our talented dev editors. This editorial pass focuses on the big picture: making sure the article flows well, making sure subtopics discussed are relevant to the overall article, making sure that the content of figures is relevant and well thought through, and so forth. While there's some copy editing done in this phase, the line editing is mostly left to another editor later on in the process. The dev editors work with the authors to make sure that all of these details are sorted through. As part of that process, after the dev edit is complete, the article's author will typically get a chance to review the article again, working with it in our formatted copy to both review the dev editor's changes and also to supply any minor corrections of their own (hopefully at this stage they don't have anything major to revise).
Once an article has been dev edited, it'll typically go through one or two rounds of copy editing before being put into layout. After these copy edits, there may still be a few grammatical or spelling errors here and there, but for the most part the article should be in a very good and readable state.
There is another very important edit that's done sometime between the time the article is submitted and layout: the technical edit. It's our goal that all of the information in MSDN Magazine and TechNet Magazine is as close to 100% accurate and relevant as possible at the time of publication (and, ideally, well beyond), and it is one of the responsibilities of the Technical Lead/Technical Editor to ensure this. Even the material from our best authors may have technical inaccuracies, and we want to ensure that these inaccuracies don't work their way into the final publication. To this end, all of our content is reviewed by technical experts at Microsoft. In addition to me (for MSDN) or Josh Hoffman (for TechNet) massaging the content for accuracy, adding additional details where relevant, or trimming away misleading statements, we also work with the product teams at Microsoft to ensure that those responsible for the features being discussed get a chance to provide feedback and comments. We then work to integrate this feedback into the content. Through this process, most mistakes are found. However, it would be naive of us to believe that we never publish an inaccuracy. Sometimes details change after we publish an article, which frequently happens in content discussing prerelease applications or tools, and sometimes we just plain get it wrong (magazines can have bugs just like software). To this end, we have several processes in place to fix errors after publication. Obviously it's not possible to modify the printed page in the copy of the magazine you hold in your hand (at least not with current printing technology), but it is possible for us to fix the errors in the online version. For more information on that, see our previous posts. Awareness of the errors we fix come from a variety of places. Sometimes the author of the article will find an inaccuracy in their work and report it to us. Other times other folks at Microsoft will discover the problems. But most of the time, it's you, the Microsoft development community, that points out the errors of our ways. You email us, or you post comments on the articles online (yes, we do pay attention to your ratings and comments... I look at them daily!) Either way, we very much appreciate your interest in making MSDN's content the best it can be. Please do get in touch in the future if you discover anything you believe to be inaccurate.
Once an article has been dev edited, copy edited, and tech edited (and reviewed), the art team jumps back in. This usually happens a few weeks after the article's due date, which means the editorial staff really doesn't have all that much time to get an article into shape, given that they're dealing with scores of articles at the same time, and the staff isn't all that large (as you can see by looking at the masthead in any of our issues). All of our editing is done in Word documents (using the Track Changes feature), and we use Adobe InDesign for layout. The article is dumped from Word into InDesign, and a preliminary layout is created. The layout features most of the elements that will be in the final layout, including all of the figures in their approximately correct location, all of the text, pull quotes blocked off approximately where they'll be in the final version, and so forth. A PDF of this initial layout (frequently referred to as a galley in the publishing world) is sent off to the author for review. While they're reviewing it, the editorial team also looks it over, performing a final proofread to fix any remaining grammatical or spelling mistakes, providing text for the pull quotes, eliminating or filling out widows (very short lines at the end of a paragraph), finalizing the article's summary box, and so forth.
Sometime during the editing cycle (usually after the dev edit is complete, but before we move to layout), members of the editorial and art teams meet to work through all of the figures in the article, in order to ensure that every figure is the best it can possibly be. This includes making sure screenshots and diagrams convey what they're meant to convey, that tables are as concise and useful as possible, and so on. We also meet to discuss titles for every article in the issue. We have very strict guidelines on the length and style of titles, and yet we want all titles to be relevant, interesting, and entertaining when possible. This can make for some thought-provoking and amusing meetings, especially when we're all tired and/or overflowing with caffeine. When we send the PDFs to the authors for review, we also send the titles we've come up with in order to solicit feedback or suggestions. The majority of authors respond favorably to the titles we've created, though it's not unusual to have one or two rejections in each issue. Frequently this is because the author feels we've misrepresented the content or that we've focused on something that they believe should not be the focus. Regardless, we're happy to work with the author to come up with something that they can be happy with, but that still fits our style restrictions.
Each author typically has a few days to review and respond with feedback to their PDFs. Any feedback they provide is integrated as best and as quickly as possible into the layout, some final reads are performed and last minute changes made by both editorial and art, and the article is shipped to the printer, along with the rest of the articles in the issue.
In general, we've managed to pipeline our process so that workload is relatively constant. However, ship weeks (which are typically more like three days rather than a whole week) frequently involve later nights as we push hard to get all articles for the issue finalized and out the door. Our deadlines are real deadlines: there is no such thing as delaying a print date, and we don't slip, period.
Once an issue has been sent to the printer, most of the editorial team considers the issue complete. However, the art team at that point still has some work to do. Mainly, they receive back from our pre-press vendor proofs that need to be verified. It's only when all of these proofs have been approved that we officially sign off on the issue and wait for the fruits of our labor to arrive in our subscriber's hands.
Of course, the print publication is only part of the cycle. We also publish every issue online, which involves additional work. Once an issue has been shipped to the printer, the InDesign files are handed off to our fearless Web producer/developer/designer Mike who handles publishing the articles online. Once the InDesign files have been converted into the XML format we use for all of our content, the files are sent off for localization so that we can launch the issue online simultaneously in all languages we provide, which currently counts 11 locales (English, French, Spanish, German, Italian, Russian, Portuguese, Korean, Japanese, Traditional Chinese, and Simplified Chinese). We also need to prepare all of the code that accompanies our articles. For MSDN Magazine, I scrub the code as necessary and hand it off to Mike, who arranges to have it signed, scanned, and propped to download.microsoft.com and linked to from our site. We also post it in a different format to enable our relatively new Code Explorer feature, where you can browse the files online rather than downloading the whole package. And in addition to publishing the articles individually online, Mike also prepares a downloadable CHM file of each issue so that you can take the an electronic version of the magazine on-the-go. Finally, the day comes when we publish the issue to the site, and with the exception of the corrections mentioned earlier, at this point we're done with an issue. By that time we've also moved on to several of the next few issues, some of which are in dev edit, some in copy edit, some in layout, and some still in the planning stages.
I've left out some details and intricacies along the way, but this should provide a good overview for how articles go from the mind of the author to the printed magazine you know and (hopefully) love.
-Stephen