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 This email address is being protected from spambots. You need JavaScript enabled to view it.. 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.

Feature Articles

A feature article uses a tutorial style to teach the reader about a specific process or technology. The typical word count should be approximately 1,500 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 the assigned word count, please discuss possible solutions with your editor.

To start your article, introduce the capability. For example, 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 500 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 highlights 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 should include both the vendor name and product name. 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 (typically, one month in advance of the planned publication date). 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 about 12 words
• A deck—A catchy, descriptive sentence of up to 30 words to entice the reader into the article
• Your byline (e.g., Written by Victoria Mack)
• The complete article, including text and figures.
• Your bio—Your first step is 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. You may include an email address and/or URL. Also send a digital headshot in jpg format with the dimensions of 116x116 pixels and compressed for web. 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 2004, 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 level 1 subheads are styled in bold, and level 2 subheads (aka sub-subheads) are bold plus italics.
• 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 Microsoft Word docs.

Figures

Your topic may require figures. Figures consist of screen shots, illustrations of your own making, and code.

Save screen shots or illustrations as jpg files, 970 pixels wide, and compressed for web. It’s very important to follow these instructions for formatting image files. A free downloadable tool called Caesium Image Compressor can easily help you get the job done if you don’t have a different tool you’re already using for images.

When you submit your Word document for editing, please also submit each image as a separate file, using file names that begin with the author’s last name and include no spaces (e.g., MackFigure1.jpg). Also insert the images 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 full-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.

Please avoid putting any type of figure within the first 200 words of your article.

Screen Shots

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, inserted into this document, and sent to the editor as a separate file along with the Word document.  

Illustrations

Create your illustrations and save them as jpg files according to the instructions above. 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 a jpg file, inserted into this document, and sent to the editor as a separate file along with the Word document.  

Code

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.

HDATFMT(*ISO) NOMAIN 

*=============================================================== 

* Compile Command 

* 

* Create Commands: CRTRPGMOD MODULE(library/CALCELAPSD) 

* SRCFILE(library/QRPGLESRC) 

* 

*=============================================================== 

D/COPY QRPGLESRC,calcelappr 

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 

/Free 

FrTimeSt = %Char(FromDate) + '-' + %Char(FromTime) + '.00000'; 

ToTimeSt = %Char(ToDate) + '-' + %Char(ToTime) + '.00000'; 

Select; 

When Format='D'; 

Elapsed=%Diff(%TimeStamp(ToTimeSt: *ISO): 

%TimeStamp(FrTimeSt:*ISO): *SECONDS)/86400; 

When Format='H'; 

Elapsed=%Diff(%TimeStamp(ToTimeSt: *ISO): 

%TimeStamp(FrTimeSt:*ISO): *SECONDS)/3600; 

When Format='L'; 

Elapsd2=%Diff(%TimeStamp(ToTimeSt: *ISO): 

%TimeStamp(FrTimeSt:*ISO): *SECONDS); 

ZeroTime=*Loval; 

EndStmp=ZeroTime + %Seconds(Elapsd2); 

Elapsed=(%Subdt(EndStmp:*YEARS)-1)*10000; 

Elapsed=Elapsed+(%Subdt(EndStmp:*MONTHS)-1)*100; 

Elapsed=Elapsed+(%Subdt(EndStmp:*DAYS)-1); 

Elapsed=Elapsed+%Subdt(EndStmp:*HOURS)*.01; 

Elapsed=Elapsed+%Subdt(EndStmp:*MINUTES)*.0001; 

Elapsed=Elapsed+%Subdt(EndStmp:*SECONDS)*.000001; 

EndSl; 

Return Elapsed; 

/End-Free 

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 your text reference.

Tables

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.

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 edited 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 online comments associated with your article for feedback. Occasionally, readers have interesting alternatives to suggest or questions about some detail in the article. To have readers’ posted comments emailed to you directly, go to your article on the Web site and subscribe to the discussion.

Compensation

Some authors will receive payment for articles approximately four to six weeks after publication. MC Press Online articles pay $.20 per published word. 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 your article. (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.

Any Questions?

If you have any questions about how you can become a part of the MC Press Online team, please feel free to email This email address is being protected from spambots. You need JavaScript enabled to view it.. We look forward to working with you!

Victoria Mack has been an editor and author for MC Press Online (formerly Midrange Computing) since 1994 and has held the position of Executive Editor since 2001. Victoria is also a freelance editor, author, and educator.  

Also Read

Getting Started with Ansible on IBM i

Maximize the power of your lines of defense against cyber-attacks with IBM Storage FlashSystem and IBM Storage Defender

Building the human firewall: Navigating behavioral change in security awareness and culture