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 System i platform 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 at 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, 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 I have 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

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,500 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.

TechTip

TechTips address a specific problem or offer a new 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.

IMHO

The IMHO column is designed to give you a place to spout off about something you find particularly vexing or troublesome in the world of IT. Got a gripe? Can you state it in about 750 words? If so, then this is the place to vent. Or maybe you have something positive to say! Either way, this is the place to share your opinions with our readers.

Case Study/Product Review

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, after the author's bio, 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?A few brief sentences about your credentials. Most authors include their email address, but that's not required.

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.

Note that this is a Microsoft Word doc. We also accept Text Only. To download this document for use as a template, click here.

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 .bmp 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 and style it as Caption. Do not "anchor" your figures to any text.

Again, please avoid putting any type of figure within the first 250 words.

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 .png 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 .bmp 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, and inserted into this 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:

If your code is longer than a few lines and the reader needs to be able to refer to the code while reading your article, label that code as a figure and give it a caption, as shown in Figure 3.

Figure 3: This sample code figure is in Courier New, 10 point, and is styled as Preformatted.

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 compile instructions at the top of the source member to show how to create the file. 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.

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 book authors have created manuals to do just that! Put their research to work for you by pointing the reader to a book that explains the basics if necessary. If the book 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). For more information about how to use the Track Changes function, see below:

For Word 97 users: Tools-> Track Changes->Highlight Changes. Be sure Track Changes While Editing is on when you make your changes. To see the editors' changes, choose Highlight Changes On Screen.

For Word 2000 users: View->Toolbars->Reviewing (or Ctrl+Shift+E) to bring up the toolbar. 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.

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 This email address is being protected from spambots. You need JavaScript enabled to view it.. We look forward to working with you!

Victoria Mack is the executive editor of MC Press Online. She can be reached by email at This email address is being protected from spambots. You need JavaScript enabled to view it..

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

The Principles of Project Management, Part 1

COVID-19 and Working from Home

Internship Tales