Write for MC Press

Wednesday, 13 June 2007

Author Guidelines: How to Write an MC Press Article

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, and System 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 through our author survey (which we strongly encourage you to fill out today!). 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, either approving the topic as presented or recommending modification.

Please note that MC Press Online publishes only original articles that have not been previously published elsewhere.

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 in the 1,200 to 2,500 word range (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,500 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 300 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 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. At the end of the article, include a company logo and the company contact information (street address, email address, telephone number, and Web address). 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 10 words
A deck—A catchy, descriptive sentence of up to 25 words to entice the reader into the article
Your byline (e.g., by Victoria Mack)
The complete text of the article, including figures. (Please avoid putting any code or graphics in the first 250 words.)
Your bio—Your bio can be up to 200 words. Along with it, include the email address and URL that you'd like published as well as a digital headshot in jpg format with the dimensions of 116x115 pixels. Your bio needs to be submitted only the first time you write an aticle, 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 (Times New Roman, 12 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 Heading 3. You should not need more than two levels of subheads. If you do, please use 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 a Microsoft Word doc or an RTF.

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, .png, or .gif files (using the Paint feature of Word) and then insert them directly into the text of your document where they are appropriate (from the toolbar, use either Insert Object or Insert Picture; do not use Insert Image). 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.

Please avoid putting any type of figure within the first 250 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 .gif file. (Click images to enlarge.)

For more information about methods of capturing screen shots, see "Screen Capture Software for Windows." Illustrations Create your illustrations in PowerPoint or Word, paste them into Paint, and save them as .jpg, .png, or .gif files. Using the features of Paint, 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.

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 that text reference, as shown in this paragraph. Tables Tables are to be created using Word's Tables and Borders features (View->Toolbars). Once you've inserted your table, from the All Borders menu, choose to show all borders (a.k.a. gridlines). Unlike figures, tables don't require captions. For tables, use a table header instead.

Graphical Elements to Assist Reader Comprehension

Figure

Table

Requires caption

Requires header

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 (highlight the text and then Insert->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 version sent to you will be V2, so you will save it as V3).

To use the Track Changes function, bring up the Reviewing toolbar by going to View->Toolbars->Reviewing (or Ctrl+Shift+E). Be sure Track Changes (the second icon from the right) is highlighted when you make changes. To see the editors' changes, choose Final Showing Markup from the Display For Review dropdown box on the far left. In the dropdown box to the right of that ("Show"), select the boxes to show comments, insertions, and deletions.

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.

Compensation

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.)

In order for us to pay you, you must fill out the author's survey so that we have all the required information. We also 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. Once you receive it by email, simply print it, sign it, and fax it to 682.831.0701.

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 Executive Editor Victoria Mack or Senior Editor Chris Smith. We look forward to working with you!

Last Updated ( Wednesday, 16 July 2008 )

[ Back ]