Author Guidelines: How to Write an MC Press Article
Written by Victoria Mack
Have you ever thought about writing for the MC Press Online publications? If you have, your desire to share your expertise reflects a commitment to advancements in the IT industry.
The MC Press Online publications give IT professionals the perfect opportunity to assist in educating their peers. Our readership consists of midrange IT professionals whose interests and vocations involve the IBM Power Systems platform (formerly AS/400, iSeries, System i, IBM i) and the technologies that run on it. They appreciate the practical education and information they receive from our feature articles, technical tips, and product coverage.
These guidelines are designed to help you through every step of the publication process—all the way from selecting your topic to publication.
Choosing a Topic
If you have knowledge to share, we can guide you through the processes of developing your topic and then writing about it. There are basically two ways in which a topic becomes an article. First, we may choose a topic and then seek out a qualified author. Second, we are always happy to consider any article topic you'd like to suggest. Simply email us by clicking here. Provide us with a brief synopsis of the material you'd like to cover, telling us why this information is relevant. We'll review your proposal and offer feedback, which may include either approving the topic as presented or recommending modification.
Types of Articles
MC Press publishes several types of articles. Each has its own distinctive style, but certain traits are common to most. In any type of article, you may hyperlink bits of text to a relevant Web page or email address, as shown several times in this document. Also, many article types require some sort of figure, whether it be code or a graphical enhancement such as a screen shot or illustration.
A feature article uses a tutorial style to teach the reader about a specific process or technology. The typical word count should be in the range of 1,500 to 2,000 words (ask your editor what the word count should be for your article). This range is not carved in stone, but it's a good guideline. Some topics can be easily covered in less. Others require more, but we fear losing readers when we give them articles that they can't easily digest in one sitting. If you feel that your topic will require much more than 2,000 words, please discuss possible solutions with your editor.
To start your article, introduce the capability. When did it become available, and what it is designed to accomplish? Identify the benefits that readers will realize when they implement the capability. You may also discuss other applications of the capability and any advantages or drawbacks it has in comparison to other techniques.
Your feature article may require code, images, or both. Feel free to use screen shots or illustrations to assist the reader, but don't feel obligated to show every screen. Include only those images that will enhance understanding the most. Generally, six or seven images is the maximum.
Feature articles vary greatly in the elements they're composed of. For one example of a feature that contains many of the possible elements for inclusion, click here.
TechTips and Partner TechTips
TechTips address a specific problem or describe a technique, and they are very popular with our readers. TechTips generally range from 400 to 750 words. Again, this range is only a suggestion; your tip may vary a little. Start by explaining the significance of the problem or technique. Then, present your solution. You may include code and/or a screen shot or two if necessary. For an example of a TechTip, click here.
Partner TechTips are similar to editorial TechTips, but they're vendor-written advertorial. The maximum word count for a Partner TechTip is 750 words. Here's an example.
Case Studies/Product Reviews
Both case studies and product reviews are advertorial that highlight the benefits of a vendor's product. A case study examines the results of an installation for a customer. It usually starts by identifying a problem a customer had and then goes on to explain why this vendor's product was the best solution to the problem. A product review details the features of a particular product.
In both cases, the titles are to be like this example: "Case Study (or Product Review): Bytware's [name of product]." Then, write a deck that indicates something about the case study or product review (e.g., "This Java-based solution provides fast, low-cost iSeries GUI access and native SCS printing over the Web."). Word count varies, so check with your editor. You may also include a screen shot or two if they are relevant to the article. Click here to see an example.
The Elements of an Article
Once we've approved your article idea, we'll provide you with a deadline for delivery of your draft. Please do not miss your deadline. We schedule publication dates months in advance, and a missed deadline presents large problems!
When you submit your draft, it should be complete and should include all required elements in this order:
- A title of no more than about 10 words
- A deck—A catchy, descriptive sentence of up to 25 words to entice the reader into the article
- Your byline (e.g., Written by Victoria Mack)
- The complete text of the article, including figures.
- Your bio—First, you need to register on the MC Press website (top right of the home page). Once that's done, send us your bio, which can be up to 200 words and can link to anything you'd like. Along with it, include the email address and URL that you'd like published as well as a digital headshot in jpg, gif, or png format with the dimensions of 116x116 pixels. Your bio needs to be submitted only the first time you write an article, as the bio is generated separately and then automatically attached to all of your articles. Note that it's best to say you've been in a position since 1998, for example, rather than for 10 years so that the bio doesn't become outdated.
The layout of these guidelines mimics how an article should appear when submitted for publication. Here are a few pointers:
- Within the entire document, all elements are left-justified.
- The text of the document is styled as Normal (Arial, 10 point).
- The headings are styled in the way we need them to be styled for publication. The title is a Heading 1. The subheads are Heading 2, and the sub-subheads are bold font.
- Later in this document, I'll explain how to format figures. Please don't use any formatting other than what we recommend, as we will have to alter it during processing.
- Articles are to be submitted as either Microsoft Word doc or RTF.
Your topic may require figures. Figures consist of screen shots, illustrations of your own making, and code. Save screen shots or illustrations as jpg, png, or gif files and then insert them directly into the text of your document where they are appropriate. Refer to each one as a consecutively numbered figure (Figure 1, Figure 2, etc.), and mention it within the text preceding the figure (e.g., "...as shown in Figure 1."). Then, provide a complete-sentence caption in the text below the image (e.g., "Figure 6: This closed-lock icon identifies which security-related system values cannot be changed.") Do not use the caption property of an image. Simply put the caption in as text below the image. Do not "anchor" your figures to any text. When you submit your Word document for editing, please also submit each image as a separate jpg, png, or gif file, using file names that begin with the date of publication, follow with your last name, and include no spaces (e.g., 121109MackFigure1.jpg).
Please avoid putting any type of figure within the first 100 words of your article.
When saving screen shots as images, maximize the screen (full view) before saving it. A screen that is saved at full view yields the best results when reproduced for publication (as shown in Figure 1).
Figure 1: This sample screen shot was saved as a jpg file.
Create your illustrations and save them as jpg, png, or gif files. Ensure that any unnecessary white space around the top, bottom, and sides of the image is eliminated. Figure 2 is an example of an illustration.
Figure 2: This sample illustration was drawn by an author, saved as an image, inserted into this document, and sent to the editor along with the Word document.
Your article may require code, which should be styled as Courier New, 10 point. It should be left-justified, with no leading blanks (except for purposes of alignment) and with no trailing blanks. Do not exceed 70 characters per line.
If the code is just a few lines for example purposes, state in the preceding text what the code is for and then insert it directly into the text of the document, like so:
D CalcElapsed PR 14 6
D FromDate D VALUE DATFMT(*ISO)
D ToDate D VALUE DATFMT(*ISO)
D FromTime T VALUE
D ToTime T VALUE
D Format 1A VALUE
If your code is longer than a few lines and the reader needs to be able to refer back to the code later in the article, label that code as a figure and give it a caption, as shown in Figure 3.
* Compile Command
* Create Commands: CRTRPGMOD MODULE(library/CALCELAPSD)
D Elapsed S 14 6
D Elapsd2 S 15 0
D FrTimeSt S 30A
D ToTimeSt S 30A
D ZeroTime S Z
D EndStmp S Z
P CalcElapsed B EXPORT
D CalcElapsed PI 14 6
D FromDate D VALUE DATFMT(*ISO)
D ToDate D VALUE DATFMT(*ISO)
D FromTime T VALUE
D ToTime T VALUE
D Format 1A VALUE
FrTimeSt = %Char(FromDate) + '-' + %Char(FromTime) + '.00000';
ToTimeSt = %Char(ToDate) + '-' + %Char(ToTime) + '.00000';
EndStmp=ZeroTime + %Seconds(Elapsd2);
P CalcElapsed E
Figure 3: This sample code figure is in Courier New, 10 point.
If your code is for download only (meaning the reader doesn't need to see it to follow along with the text—for example, a utility), save your code as a .txt file, zip it, and mention in the text that the code is downloadable from the MC Press Web site. Send the zip file along with your Word doc. Be sure to include any compile instructions at the top of a source member. We will hyperlink your zipped code files to that text reference, as shown here.
Tables are to be created using Word's Tables feature. Once you've inserted your table, choose to show all borders (a.k.a. gridlines). Unlike figures, tables don't require captions. For tables, use a table header instead, as shown in the example below.
Graphical Elements to Assist Reader Comprehension
Hyperlinks and Footnotes
Your article may benefit from embedding hyperlinks into your text in order to point readers to useful information on the Web. These links should be embedded within the appropriate text, not shown as a URL.
Avoid using footnotes if at all possible. Use hyperlinks instead.
The Writing and Publication Process
Once we've approved your topic, we may ask you to provide an outline of the article. For the outline, style is not a concern; just organize the points you want to make in a hierarchical format and include an introductory paragraph that summarizes the content of the article. Even if we don't request an outline, it is often to your benefit to create one for yourself to ensure that you cover all the points you intend to cover. Then, if you're having difficulty getting started writing, begin expanding on those points. You'll have an article in no time!
Please keep in mind that, although you're writing for programmers at all levels, you don't need to explain everything from ground zero. Many authors have written manuals or other articles to do just that! Put their research to work for you by pointing the reader to a book or article that explains the basics if necessary. If the reference is available online, please put in a hyperlink to it.
Once you've finished writing the article, review your work. Try to eliminate paragraphs, sentences, and figures that do not strengthen or enhance your main idea. By trimming excess material, you create a focused, powerful piece of communication.
When you feel confident that your article is complete, you are ready to submit your draft. Your draft will be reviewed by the editorial staff in a process that typically takes from one to four weeks. Generally, you will see your draft only once again after you've submitted it. After editing, it will be returned to you for review.
Microsoft Word offers a feature called "Track Changes" that maintains a history of modifications to a document. Using the Track Changes feature of Word, you can review exactly what's been done to your article since you first submitted it. (Some authors, however, choose not to review each edit; they prefer to simply read through the current version.) You may also see embedded comments for your attention. Those comments will typically ask for clarification of some sort. You can address these comments by modifying the text in the document directly, leaving Track Changes on so that we can see what's been done. If an editor's comment requires a response comment of your own, please do not respond within the original comment. Instead, create a new comment. Once you've reviewed the document and made any necessary modifications, save it as a new version and return it to your editor (typically, the edited version sent to you will be V2, so you will save your revised version as V3).
Once your article has been published, be sure to check the forum associated with your article for feedback. Occasionally, readers have interesting alternatives to suggest or questions about some detail in the article. To have forums postings emailed to you directly, go to your article on the Web site and subscribe to the discussion. Note that you cannot subscribe to a forums discussion until one has been started. You're encouraged to start the discussion yourself by posting a message inviting readers to comment.
Freelance authors receive payment for articles approximately four to six weeks after publication. MC Press Online articles pay $.20 per word for published text. Code pays $.25 per line, excluding blank lines and lines with just one character. Illustrations and screen shots pay $10 each. Each type of article has a maximum pay rate. Be sure to ask your editor what the maximum pay is for the article you want to submit. (Note: Vendor-written articles receive no monetary compensation.)
We require a signed author release prior to publication of your first article. If your editor didn't provide one, please be sure to ask for one.
If you have any questions about how you can become a part of the MC Press Online team, please feel free to email Executive Editor Victoria Mack. We look forward to working with you!