VOICE Home Page: http://www.os2voice.org

[Newsletter Index] [Previous Page] [Next Page] [Features Index]

Here's how it works: You write an article and send it to editor@os2voice.org. Please be sure your article is a HTML file, plain ASCII text file, or any format viewable by Describe, Lotus WordPro or StarOffice, which accounts for just about everything other than IBM Works, Papyrus and Clearlook formats. We do prefer HTML though.

There is no requirement as to length, since this newsletter is only in HTML and INF format. It can be as long or as brief as necessary, so be thorough in your descriptions and commentaries. However, please remember that you are not writing your master thesis, so you don't have to begin at the very beginning à la "And first the earth cooled...". The reader will get bored very soon if you begin the review of a word processor with a nicely worked-out history of word processing software.

Your article will then be reviewed and run through a spell checker. If there are any non-spelling changes we think should be made, we will let you know and we can discuss them. We do not make any major changes without input and approval from the author. We will work on it with you to get it in shape. We are not professional editors, but we believe we have done some decent work on the newsletter.

As to professionalism of writing, please refrain from vulgar and abusive language, illegal subject matter, and slander/libel. Our aim is to encourage readership and author participation by presenting a tasteful, yet useful medium for OS/2 related information.

Content and structure

1. Your Byline: Include your name, email and a web site if you'd like. You can also give a brief plug for yourself/your business if you want but that would be tacked on to the bottom of the page.
2. Resources: Please list URLs of web sites you refer to or titles of books you have taken information from.
3. Graphics can help a lot with explaining how things work, but try to keep them to 256 colors or less (this is a requirement of the INF version), and the smaller the file size the better, as some people download the Newsletter to read off-line. Depending on the size you may want to consider using thumbnails in the text. Please add descriptions, e.g. "Fig.1: LAN interface setup dialog". Images can be in just about any format, but we prefer PNG, JPG, or GIF (use a package like PMView that has a valid licence for the LZW compression). Remember to put in your document where you want the images to go if you don't use HTML format.

If your article is a review, it generally should cover the following additional information, but don't feel locked into this:

1. Additionally: List any URLs for getting information about the device and any software used specifically with it, if any. Also give the manufacturer's suggested retail price and/or a general price range for it and possibly the vendor or vendors where it can be purchased.
2. Initial Impressions: Why did you choose this particular package? How did you go about deciding on it? What alternatives did you consider? What were your initial impressions about it when you took it out of the box?
3. Setup/Installation: Was it complete out of the box (or zip file), or did you have to purchase or find additional items like cables and drivers (this mostly applies to hardware)? Did you have to read the manual? Was there a manual, if so how good/helpful was it? Did you still have to boot to plain DOS or heaven forbid Windows9x to run any kind of setup or calibration software? What hardware are you using it with (major PC specs if applicable, ie CPU, RAM, HD) and what version of OS/2? Any minimum hardware/software requirements for this application? What kind of Support is provided? Did you have reason to ask for help, if so how was the response? Normally, installation itself shouldn't be talked about that much, since a well-working one is expected from every product. But if you had problems or you think that certain things have been solved in a very intelligent way, do comment on that.
4. How Does it Work: Give some details on how you use the application. No need to get into every detail, just the basics is fine. Many people seem to be temped to write something like a user's guide in this case. If you are just reviewing a product, don't write about which menu you have to select to invoke a feature. Better tell the reader how good that feature works. Graphic's are nice and help a lot in showing how a product works,
5. Conclusion/Final Thoughts: Are you satisfied with this product? Can you give a comparison to any similar product as far as quality and general usability? Would you make the same decision again? What do you see as it's strong and weak points? Did you have to contact the manufacturer or vendor for support? If so was it any good?

Formatting

• Things you want to emphasize should be bold, not in italics or in uppercase.
• Please write names of objects, like the font palette, and options in dialogs in italics, as well as values that are to be entered in dialogs.
• Filenames, paths and source code should be monospaced (<tt> and <pre> tags).
• Anything that should be entered at the command line should be monospaced and in the font color green. You may also want to put these into a seperate line.
• Mark warnings in red color.
• Keys should be marked as monospaced and with smaller-than/greater-than characters around them, e.g. <CTRL-ALT-DEL>.
• All URLs should be listed fully readable in the seperate resources section, e.g. as http://hobbes.nmsu.edu and not Hobbes. The latter method is preferred inside the article's body.
• Please do not use any specific font faces! Some editors seem to do this by default.
• Ensure that your HTML editor doesn't use absolute local links like C:\VOICE\vnewsf3.htm.

Thank you,

The VOICE Editors. Last Updated March 02, 2001