PC Community Newsletter Writer's Guide

Thank you for writing for the PC Community newsletter. This guide is intended to make the process easier by setting forth some guidelines to help you express your ideas.

In editing the newsletter, the editor keeps an eye on the purpose of the user group. PC Community's purpose is to allow users of computers and related technology to get together and exchange information. As the uses of computers broaden, so does our group. SIGs are formed to serve special areas of interest to the members, and the information that is exchanged there is the main business of PCC. Similarly, the main business of the newsletter is the dissemination of information. This may be in the form of a paragraph or two about a piece of hardware or software that you are using, or may be expanded into a full size article.

You need not write a full length article to present a good idea. Many ideas that people can find useful can be presented in a single paragraph, and will reach hundreds of people through the newsletter. This is perhaps the best purpose of the newsletter. Articles, letters, comments, and snippets are all welcome. Remember, the newsletter is put together for you, the member. Accordingly, the more members that submit their ideas for publication, the more useful it is to everyone.

Goals of the Editor

As editor, I attempt to display your ideas in the best possible light. This makes you look good, and in turn, reflects favorably on the newsletter, PC Community, and possibly the editor. The editor’s job is to achieve a consistency in style and appearance of the newsletter from month to month. Consistency in formatting is provided by style sheets in Adobe PageMaker, which is used to produce the newsletter, and which is responsible for some of the mechanical conventions that are listed below. It guarantees, for example, a consistent style for the appearance of each page and for the fonts used in different parts of the headings and text.

If you compare articles by different authors, you will see their individual personalities peeking through. While seeking consistency in style, the editor tries not to lose the individuality of the writer. Sometimes, though, minor corrections are necessary for the sake of clarity or consistency. Most of these are conventions of dates, times, use of capitalization, and so forth that make the publication more readable. Editing is editing, though, and occasionally it will be necessary to make changes in construction or alter material for space considerations. This will usually be done by first consulting the author, though editing is still editing and the editor will reserve the final say.

The Publication Process

Adobe PageMaker is used to put the publication together, so it dictates certain mechanics in your submission. This is not trivial, as PageMaker's way of doing business is different from virtually every word processor, and correcting these mechanics before PageMaker sees your item consumes an inordinate amount of time. Generally, editing is done in PageMaker's Story Editor, where the item is reviewed and spell checked. Graphics are usually adjusted with Paint Shop Pro before being imported by PageMaker. When layout is complete, masters are printed and reproduction is done by a commercial copier.

Word Count

The newsletter accommodates about 700 words per page, which is the way the editor views it. Items may be longer or shorter, but if you want to do some helpful planning, edit your submission with these figures in mind.

Submitting Snippets

Lest you get the idea that all this writing and submitting stuff is going to be stuffy, let me encourage you to dash off your ideas, great and small, in a single paragraph and send them to me via e-mail. If you send me a text file as an attachment, the only thing that I ask is that it is in plain text, not word processor format. Kindly observe as many of the conventions in this guide as you can, but that is not as important for snippets as it is for a 2000 word article. The important thing is that you dash it off and send it to me.

Submitting Columns

Regular columns occupy about 250 words for each column in the publication. Columns presently range from 250 words to 1000 words depending on authors and subjects. If you write a regular column, it does not need to be the same size each time, but may change with the subject. You may expect it to be changed by the editors according to demands on space, so news information should be presented in small paragraphs outlining each news item. Every effort will be made to keep topical columns intact, but they are subject to revision to meet demands on space. Please use the file naming and other conventions listed below before submitting. If you desire to write a column, contact the editors for evaluation.

Submitting Reviews

Reviews of software, books, and hardware are encouraged. A book review should be at least 500 words in length to convey enough information to be useful to readers. It is expected that reviews of complex software and hardware will run between 1000 and 2000 words.

Information on the product should include the following, placed at the end of the article: Emphasize features that are exceptional, unusual or lacking for that type of product, and relate your experiences with installation, normal use, problems, and your overall satisfaction with the product. Don't forget to mention local availability, and your experience with technical support. Please observe the conventions listed elsewhere in this Guide, and don't forget to run your spell checker on your item before submitting it.

Articles

Feature articles should be 500 to 2000 words in length. They may be longer, but are subject to revision by the editors according to available space.

Subject matter is open to anything relating to computers, peripherals, PDAs, networking, and other technological subjects that you think a technology user might be interested in. Reviews of computer hardware and software are particularly encouraged in line with the purpose of the users group, but any item relating to computers will be considered if it proves interesting. Before embarking on a major piece of writing, consult the editor first.

A product review might be organized like this:

• Title
• One paragraph overview, containing the principle features and system requirements of the product.
• Body text - try to address the following issues, approximately in this order:
  
  • What does this product do? (don't laugh - it's not always obvious from the product's name.)
    
  • Who is the target audience for this product? Why did you get it?
    
  • Installation experience, if installation required. Did it go as you expected? Did you run into any surprises? Were the instructions useful or not? Any comments about technical support required to get going are germane here.
    
  • How does it work? Does it work the way it's supposed to? Does it accomplish what you expected? Is the interface good or bad? (does the interface make sense to you? Be specific about what does and what doesn't.)
    
  • Do you still think it's useful after you've used it for awhile? (After the novelty wears off.)
    
  • List the product's three best strengths or features. List the product's three worst weaknesses or features. This is often a good way to get yourself to start talking about the product. Remember, we are trying to get you to tell us what it's really like to use the product - good and bad. This is not supposed to be a testimonial; it's supposed to be a real world view on the usability and desirability of the product. Speak your mind.
    
  • Summary - how do you feel about the product in the end? Do you recommend it over other similar products? Why? Explain your reasons to us.
• Product information:
• The product's full name
• Vendor's name
• Vendor's address
• Vendor's URL
• The product's price, MSRP or Web pricing
Be sure to run your spell checker on your item before submitting it. Your grammar checker should be used to avoid gross grammatical errors, though don't hesitate to reject its suggestions when you are trying to present an idea in a specific context.

General Conventions

You may compose using your usual word processor, but Please submit your item in either ANSI or ASCII format (That's "plain text", "DOS text", or "Windows ANSI" in most word processors.) I do not wish to seem narrow about this, but it is not possible for me to maintain a copy of every word processor out there to do editing. PageMaker will swallow almost any file format, but that requires extra work reformatting the entire article to make the appearance consistent with the rest of the newsletter.

Text conventions

Certain conventions in text spacing are necessitated by PageMaker. If you have been using computer text editors for some time, you may have developed certain habits that run contrary to PageMaker's expectations. You do not have to change the way that you compose, but once you are finished writing, it is requested that you go through your item and look for the following items:

• All text should be submitted left justified or unjustified. In particular, do not right justify or full justify text. Do not center title, headlines sub-headlines or bylines; left justify them. Same goes for signatures, commentaries and product information at the end of the item. In short, left justify everything.
  
• Use one space between sentences rather than two. After composing your text, use Find and Replace to search for the occurrence of double space and convert them to single spaces.
  
• Use one carriage return after each paragraph instead of two. PageMaker interprets a carriage return as the end of the paragraph, and inserts a blank line of its own. If you compose with double carriage returns between paragraphs (as I do), use Find and Replace to change them to single carriage returns after you finish your item.
  
• Do not hyphenate words at the end of lines. Turn off hyphenation and let your word processor word wrap. Use hyphens only when required in a specific context. We need to let PageMaker perform hyphenation where it wants for appearance of the text.
  
• Do not place anything in all caps (LIKE THIS) except filenames. If your purpose is to place emphasis, use italics. Indicate where you want italics in your submission by bracketing the text with "<I>" and "</I>". (ex. "The DataDiddle database is <I>really</I> slow...")
  
• Boldface is used only for exceptional circumstances. The most common usage is in articles about programming where reserved words are usually boldfaced to avoid confusion. Do not use boldface for emphasis. Use italics as described previously. However, if boldface is intended, bracket the text with "<B>" and "</B>". (ex. "In C, the main body code is indicated by <B>main</B>.)

Style Conventions

• Headlines, subheads, and bylines should not use all caps. Use first letter caps for all words except conjunctions, prepositions, and articles. (ex. "WordWarp for Windows Is a Great Way to Use 150 Megabytes of Disk Space") The byline should contain only the author's name and not the word "by" or a copyright notice. Those should go with the signature at the end of the item.
  
• Acronyms - Computerdom is full of buzzwords and acronyms, but remember that your audience is full of people who have probably never seen things like DRAM and GUI before. The first use of an acronym should be accompanied by a parenthetical explanation. (ex. "The computer's capability will be determined largely by its CPU (Central Processing Unit).") Pluralize acronyms thus: URLs, GPFs without an apostrophe. (ex. "Windows GPFs, while endangered, are far from extinct.") Use the apostrophe only when you are implying possession. (ex. "the BBS's hard disk took the day off without notification.")
  
• Commands and Filenames - DOS (or other system) commands are one of the few exceptions to the no caps rule. (ex. DIR and DIR/W) Filenames should be fully capitalized. (ex. WINWARP.EXE) Filenames should be referred to without their extension only after they have been presented with their extension.
  
• Be careful about unusual capitalization and characters in a vendor's name or product name. Common examples are "Microsoft" (one word, small "s"), "WordPerfect" (one word, capitalization), “iMac” (unusual capitalization). Word processors have most of these industry specific names built into their spell checkers these days, so be sure to use your spell checker on these.

Miscellaneous conventions

• Contractions - For consistency, Please adhere to the following terms and usage:
  
• KB for kilobyte, as in 512 KB cache RAM. (Note the space between “512" and “KB”.)
  
• MB for megabyte, as in 512 MB of RAM. (Again, note the space.)
  
• MHz for megahertz, as in 50 MHZ. (Note the capitalization.)
  
• GHz for gigahertz.(Note the capitalization.)
  
• When referring to CPU speed, it is usual to hyphenate the number when used as an adjective (ex. "200-MHZ Pentium"), while the CPU as a noun is usually referred to as a "Pentium 200".
  
• Dates - I don't wish to get too formal about this, but dates should usually be in month- date-year format. (ex. 09-20-03 or September 20th, 2003) Avoid military format. Avoid database format. Julian dates should not be used unless you don't want anyone to show up on the date in question.
  
• Times - Times are preferred in the 12 hour clock: hours, colon, minutes, followed by a space, then A.M. or P.M. as capitalized and punctuated here. (ex. 12:00 A.M., 12:00 P.M.)
  
• Phone Numbers - This is arbitrary, but phone numbers should be in the format 123-456- 7890. This makes them easier to read when they are place inside of parentheses and used in conjunction with other formatting conventions. Please include area codes with all phone numbers. Our members live in 5 or so different area codes.
  
• Sizes - Physical sizes should be expressed as numbers and decimal fractions. (ex. "Floppies come in 5.25" and 3.5" form factors.")
  
• Use "bps" (bits per second) to indicate modem speeds. The term "baud" is technically incorrect for rates above 2400 bps.

Submission

Items may be submitted by e-mail directly to the editor. Items should be submitted in DOS text (ASCII) format or Windows ANSI format, as an attachment. If you are submitting a short item in the body of an e-mail, Please do not send the message as HTML. It creates more work because the text has to be extracted and the extra carriage returns stripped off. If your item contains graphics, Please submit a separate copy of each graphic and be sure that each format has its proper filename extension (GIF, TIF, JPG, etc.). Bundle the graphics and the text in a .ZIP file and e-mail the single .ZIP file as an attachment.

Additionally, files may be submitted on floppy disk or CD-ROM. CD-ROM is preferred if there are several images included with your article.

Okay, it's your turn...

Jan Fagerholm

PC Community, P.O. Box 55513, Hayward, CA 94545-0513
Copyright 2008