Guidelines for Submissions to the VOICE Newsletter
Last Updated February 24, 2004
- Content and structure
- Formatting and HTML coding
First and foremost, please do not hesitate to ask if you have questions regarding these
submission guidelines. We would rather work with you to ensure quality than to turn you away by
being either too vague or too specific.
The VOICE Newsletter is a project that is completely based on volunteer work, which applies
to authors, publishers, editors, and translators alike. Nobody gets paid other than by
possible sponsoring by our readers.
Here is how it works: You write an article and send it to email@example.com. If it consists of more than one file,
please pack them with Info-ZIP. 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 or plain
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 (something that you should
also have done before sending the article). 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. While a casual writing style ("writing as you would
talk") can be acceptable or make sense in some cases - as a stylistic device, in editorials
or glosses - we strongly encourage you to choose a more professional approach in general (this
does not mean that you cannot be funny). Our aim is to encourage readership and author participation
by presenting a tasteful, yet useful medium for OS/2 related information.
Therefor VOICE reserves the right to reject any submitted article for
Sorry, but alas we cannot spare you the following. It is required for our and your own
By submitting an article for the VOICE Newsletter you grant VOICE the irrevocable and perpetual
right to translate, publish, store, and distribute the article (defined as text, included images
and code) via any media without any compensation. You also grant VOICE the right to apply
modifications to the translation if required for better comprehensibility. Otherwise you retain
the full copyright. By submitting an article you also assure that it is free from copyrights of
third parties, or that these third parties agree to the terms mentioned above, and that you are
liable for any possible copyright infringements in your article (text, images, or code).
If you are not sure, whether your idea for an article is suitable for the Newsletter, have a
look at the following list of general kinds of articles:
- Reviews of hard- and software including citing and evaluation of facts regarding
installation, features, stability, and support.
- Comparative reviews of hard- and software products of the same kind, e.g. graphics adapters
or office suits, including comparisons of properties like e.g. finish, installation, features,
stability, and support. Teaming up with one or more other authors is advised due to the huge
- In-depth guides covering installation, configuration and optimization of complex or hard to
use products (so-called HowTos), e.g. OS/2 itself, Emacs, or TeX.
- Essays and comments regarding things that are going on in the world of (OS/2)
- Presentations of OS/2-related projects and web sites like Odin, Netlabs, or OS2.org.
- Tips & tricks
- Introductions to programming in certain languages like, for instance, Ada95 or Python, or
to special parts of programming with an eye on OS/2 specifics, e.g. PM/WPS or multimedia
programming. (You may want to submit those to EDM/2,
- Collections of information resources regarding a specific topic.
Here are some concrete suggestions for topics that we think are of particular interest:
- Astronomy: Nightvision, PmAs, XEphem for XFree86/OS2
- Office: Accounting applications, LyX for XFree86/OS2 (a LaTeX GUI), Mesa 2, Papyrus
- Filemanagers: A big comparative review of e.g. F, FC/2, FileStar/2, EF Commander, Connect/2
etc., as well as a single review of e.g. the free F.
- Databases: Comparative and single reviews of Approach, DB2, DBExpert, MySQL, PostgreSQL
- Editors: Comparative and single reviews of Emacs, Enhanced EE, EPM, FED, FTE, MED
- E-mail clients: Comparative review of MR/2 ICE, PMMail, Polarbar Mailer, Emerald Mail,
Gnus/Emacs, Pine, Snee/Vsoup, Yarn/Vsoup. Also single reviews of the less known packages are
- Development: Free Pascal, GNAT, OpenWatcom, Virtual Pascal
- Graphics/DTP: DrawIt!, Embellish, GIMP, GMT, Gnuplot, Maul, Photo>Graphics, PhotoTiger,
- FTP clients: Comparative/single reviews of NcFTP, NFTP, emtec FTP, F, Handy FTP
- Newsreaders for OS/2: both comparative and single reviews of both PM and text mode
applications. A few candidates: ProNews/2, Gnus/Emacs (w/ Changi?), Slrn/Slrnpull/Changi,
- Multimedia: OS/2's weak point, so every package could be interesting. E.g. MP3 players
like PM123 or z!.
- Networking/Internet: Links browser, FTP servers (Hethmon Brothers, Peter Moylan), mail
servers (Hethmon, IPS, Weasel, Zero Toaster, ZxMail), HTTP servers (Apache, IPS, SRE, Xitami, Web/2)
- Games: Lincity for XFree86/OS2, Shisen/2, Stellar Frontier, emulators like VICE/2, MAME,
- Tools: ePDF, Ghostscript/GSView, Junk Spy 2, PMPDF
- X11: reviews of ported X applications
- Workshop desktop publishing with Maul Publisher
- Using Mozilla's new junk mail feature
- Connecting to and using databases with REXX
- Installing and using ported X11 applications
- Getting certain types of hardware to run on OS/2 (determining which drivers are required,
which parameters have to be used, etc.)
- Creating PDFs on OS/2 (using Ghostscript 8 and GSView, PMPDF, or ePDF, as well as
- Extending EPM with macros
- Reading news and mail with Gnus/Emacs
- Reading news with Srln and slrnpull or Changi
- Reading news and mail with Snee and Vsoup
- Reading news and mail with Yarn and Vsoup or Souper
- No-cost IDE with gcc and Emacs
- GIMP or Photo>Graphics workshop
- PM programming with Ada95 (GNAT)
- Interviews with people from the OS/2 world (developers, event organizers, etc.), e.g.
Kendall Bennett, Daniela Engert, Jason A. Gow, Adrian Gschwend, Kim Haverblad, Mike Kaply,
Christian Langanke, Sander van Leeuwen, Ulrich Möller, Rich Walsh
Content and structure
The following should give you a rough idea of what to include in your article:
- 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.
- Resources: Please list URLs of web sites you refer to or titles of books you have
taken information from.
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). Note that the different formats are
also suitable for different purposes. JPEG is likely to result in washed out fonts in
screenshots of dialogs, for instance. 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, you should definitely read Esther Schindler's article
How to write a product review
from the November 2000 issue of Extended Attributes. Anyway, it generally should cover the
following additional information, but don't feel locked into this:
- Introduction: What is the problem the software aims to solve? 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?
- 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 Windows 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, 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.
- What is it capable of and how does it Work: What does the manufacturer claim
that the product can do? Does it hold to this promise? Is it better or worse than comparable
products? Are you missing a feature which is essential for solving the problem?
Give some details on how you use the application. No need to get into every detail, just
the basics is fine. Be aware that your way of doing things isn't necessarily the same
as our readers'. Many people seem to be tempted to write something
like a user's guide in this case. If you are 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. Graphics and figures are nice and help a lot in showing how a product works.
- 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? Is it a good value?
Would you make the same decision again, or advise others to buy it? What do you see as it's
main strong and weak points? Did you have to contact the manufacturer or vendor for support?
If so was it any good?
- Resources: 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
If your article is a How-To, i.e. it explains how to achieve certain things with certain
applications, tool, etc., please mind the following:
- Restate what the problem was and what the steps and tools you
used to solve it were.
- Try to bring the steps into a chronological order and leave out
things that aren't related, since they might just confuse the reader.
- Begin the article with a short description of the problem, maybe a
statement about why you think it is worth the hassle, and perhaps a
short lookout on how it can be solved.
- List the required tools (if not too much this can also be done at
the very point in the process they are used at, perhaps at the
beginning of each chapter). Do these tools require any other things? If
complex preparations are required to use the tools, describe them
before beginning with the description of the problem-solving itself.
- Is any extra-knowledge required to solve the problem that is not
directly related to the steps? Describe it prior to dealing with the
problem-solving itself. Don't insert chunks of it in between like e.g.
"And, by the way, xizzy works by doing blah."
- List the steps which are required to solve the problem.
- If there are different approaches and they take longer to deal
with, create a separate chapter for each one. Don't mix alternatives in
one paragraph so the reader doesn't get confused.
- Always take into account that the reader probably knows a lot less
than you. Don't take power-user knowdledge for granted. So be detailed,
but don't explain basics that aren't required for the reader to be able
to reproduce the steps (and understand them).
- Don't list information that isn't really related to a specific step
in that step's chapter/paragraph. If it could come in handy though,
donate a seperate chapter to it after the problem-solving process.
- Troubleshooting information, i.e. how to determine what went wrong
where, would be nice, if the issue is a complex one.
- List sources where interested readers can obtain further information
which deals with the background, digs deeper, etc.
Formatting and HTML coding
Formatting the text in certain ways can increase readability a lot. Please ensure that your
article conforms to the following to keep the Newsletter's interface consistent.
- You do not need to rebuild the Newsletter design with header, footer, and boxes. This is
automatically taken care of by PPWizard scripts. Just provide the layout which you want to use
inside the article's body, and the data regarding yourself, program data, links, etc. Have
a look at these templates.
- Please do not use CSS for formatting at this point! If you use Mozilla Composer to
edit your article, ensure that the option Use CSS styles instead of HTML elements and
attributes in the Composer of Mozilla's preferences is not
- Please do not use any specific font faces or sizes! Some editors seem to do this by
default. Using a smaller font size for descriptions of images/figures is acceptable
- If you would like to make use of tables, keep them simple: Please don't include images
in tables and avoid nested tables, since both kinds are not supported by IPF and make
generating the INF version of the Newsletter very complicated. Usage of colors is acceptable
- Things you want to emphasize should be bold, not in italics or in
- 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>, <code>,
and <pre> HTML 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
Mark warnings in red color, preferably like this:
CAUTION: Never use this feature to...
- Keys should be marked as monospaced and with angle brackets around them, e.g.
- All URLs should be listed fully readable in the seperate references section, e.g. as
http://hobbes.nmsu.edu and not Hobbes. The latter method is preferred inside the article's
- Ensure that your HTML editor doesn't use absolute local links like
- How to write a product review
by Esther Schindler
- The essential steps to writing an effective product review, by Esther Schindler, extended attributes, November 2000
- HTML Tidy
- A freeware tool for checking and formatting HTML code. It is also capable of correcting
- WWW Consortium
- The WWW Consortium offers extensive informationen on the HTML standards defined by itself,
an online validator for web pages, and more.
Again, if you have any questions regarding the submission itself or how to write an article,
feel free to ask.
The VOICE Editors.
< Previous Page | Newsletter Index | Next Page >
VOICE Home Page: http://www.os2voice.org