Write for Eye on Objects!

Hatteras Software Publications is seeking articles for the Eye on Objects magazine that provide information to our readers which is not easily found elsewhere. These articles should help our readers solve their real-world VisualAge-related or general OO-related development issues and should come from personal experiences on OO projects. Our audience's experience level is from novice to expert. Most are corporate developers and a growing number are independent developers.

Contents

We need articles that focus on
How to submit
What happens to your submission
The writing and editing process
Some pointers
Article length
Preparing your document
Program code
Graphics and output samples
Submitting your article
Getting paid
Where to send articles

We need articles that focus on:

VisualAge Functionality
Smalltalk, C++, Java, COBOL Tips, Tricks and Traps
Software Components
Development tools
Java Applets
Advanced Object-Orientation Development
Distributed Object Computing
Web Development
Multimedia Programming
Product and Book Reviews
Object Databases
CORBA, ORBs, IIOP
Security

We need articles to help other developers. Ask yourself: what have you learned that would benefit others like yourself? Are there things you have run across that were hard to solve? We also need objective reviews and articles about third-party products or approaches to providing business solutions. We are open to suggestions on other types of articles as well.

Note that you can also submit product news, announcements, etc. We will try to include as many as possible and do not charge for this. Please limit individual news items to 150 words.


How to submit:

You can submit full articles or article proposals in writing to our mailing address. However, sending them via e-mail will give you faster response. Send to: Mark Lorenz, Managing Editor (mark@hatteras.com). When you send us an article or proposal, please include the following information:

Article Description
Write a brief explanation of the article. Include the reasons you think our readers would want to read your article. Also, tell us why you are qualified to write the article. Keep the article proposal to under 3 paragraphs.

Outline
For proposals, create an outline of your article. A well-developed outline will list the topics you want to cover as well as the sequence in which you will present them. The outline helps us determine whether your idea can be turned into a complete article.

Estimated Length
For proposals, please estimate the length of your article in words or pages.

Background Information
Include a short biography of yourself. Tell us what qualifies you to write the article and any other useful information. Even if we don't need your article at the time, your qualifications may fit another article we need developed later.

Contact Information
Please include your name, phone numbers, tax ID (or Social Security Number), e-mail and snail mail addresses on all your submissions.

Format
Send us your article or proposal as a Word for Windows document or an RTF file. We can convert almost any format, but these formats are best. If necessary, we can also take your article or proposal via US mail. Remember, e-mail gets the fastest response.


What Happens to Your Submission

We usually have several people evaluate ideas both for editorial and technical content. This may take as much as 45 days. Until you have established a track record with us, we will usually accept your article on spec. This means that once you have submitted the final article to us, we may or may not publish it. We may reject the article because of many reasons: the writing is not of publishable quality or the article does not fit the original proposal.

If we accept your article or proposal, we will contact you via e-mail or phone. For proposals, we will specify a length and give you a deadline for submitting the final draft.


The Writing and Editing Process

You should try to weave the theme of helping VisualAge and OO developers solve their programming problems into your article. Your article should state the problem, then a solution summary, and then the details of the article. Discuss any limitations your solution may have so readers are not caught by surprise.

If you send us a rough draft, we can send you feedback about content, approach, and style. When you send the rough draft, make sure you note at the top of the document that it is a draft and that you want feedback. Otherwise, we will assume it is the final draft.

If the article needs more work, we will send it back ASAP with comments. Please act on these comments immediately so you will not fall out of our current editing cycle. It can be a challenge to go through the editing and rewriting process in time to meet editorial deadlines. However, our only goal is to provide the reader with the best articles possible and to make sure the quality of our magazine is the best in the industry.


Some Pointers

Get to the point
Do not be vague. Structure your articles well. Make sure the article follows a logical progression from summary to detail. Each point should be supported. One technique is to create an outline first and then fill in the details.

Check your facts
If your facts are wrong, our readers will know, and you will hear about it. We do run our articles though a technical editing process to assure that facts are correct. However, if we find one technical error, it will make us look at the article much more closely.

Write about something new or different
We do not want to replace the VisualAge documentation or training classes. We like new approaches. Our readers want valuable information they can put to use on their project immediately. Answer the journalist's questions: Who, What, Where, Why, When, and How.

Avoid extremes
Don't be super formal. Write in a familiar, friendly, energetic style. Write simply and don't use overly complicated or easily misunderstood words. On the other hand, don't be too casual. Remember that we have an international readership and some readers may not know what a slang term means. One technique is to read your article out loud. If it sounds bad while you read it, change it.

Use active verbs
Stay away from passive verbs (e.g. "Solutions were found." "Code was written..."). Use personal pronouns to involve the reader. Say "you," not "they". Do not say "we" when you mean "I."

Make sure your pronouns refer to something
Make sure words like it, this, they, and these refer to something concrete. Many times pronouns could refer to multiple items, and the reader may not know which item you meant.


Article Length

When we assign an article, we will agree on an article length. We count words with Word for Windows 6.0. However, screen shots, code examples, and illustrations will skew the word count. Remember that the word count is only an estimate, and you will not be penalized if you are slightly under or over the count.

Please don't send us an article that is much shorter or longer than the length we agreed upon. Such extreme differences mean that we may have to find another article to help fill the space; longer articles mean that we may have to cut something - perhaps your article! If you find that you are going to be short or long, please let us know as early as possible.


Preparing your Document

Our official format is Microsoft Word for Windows 6.0. If you don't use Word for Windows, tell us your format. We can convert most formats during editing, but sometimes conversions cause problems.

Use one font size and type. Our standard font is 12 point Times New Roman that comes with Windows. Don't worry about formatting your document - that is our job. We just need the text.

Don't include text formatting such as bold, italic, underline, centering, justification, etc. An exception is code - use 12 point Arial for any code, class names, etc that appears in the article or in a diagram. The rest of the text formatting is our job. We generally don't put things in bold. We will use italics or underlining if needed. If you think we should format something in a certain style, please include that with your comments.

Please follow these typographic and punctuation rules.

* Please, only one space after sentences. The old rule of 2 spaces is only for monospaced fonts.
* Don't indent your paragraphs with spaces or tabs.
* Use 1 carriage return for a paragraph.
* Comments should be inserted by putting three question marks, your initials, and then your comment. For example: ???JH - Please make sure that the code indentation is kept!
* Put suggested headlines, captions, and subheads on a line by themselves.
* Please spell-check your article before sending it to us. Also a grammar checker can help spot passive voice and poor sentence structure.

Program Code

Use code snippets to illustrate points in the article. Include full routines if they apply and will be useful to the reader.

Keep code lines to 50 characters
Format your lines to fit in 52 characters. This is very important!

Indent carefully
Don't indent your outermost code. Indent inner code 2 to 3 spaces per level. DO NOT use spaces to indent: use tabs.

Code Font
Use 12 point Arial for any code, class names, etc that appears in the article or in a diagram.

Run your code
Please make sure it works before you send it to us. Otherwise, you'll get all the mail we receive.


Graphics and Output Samples

Please use graphics to help readers understand your ideas: include screen shots, diagrams, charts, etc. Include screen shots and close-ups to help illustrate your points. The readers will like these.

* To take screen shots, just use the Windows clipboard and Paintbrush.

* Use gray screen colors for your screen shots. We prefer screen shots taken with white backgrounds. Otherwise the colors turn to gray or black and are harder to reproduce.

* Name your screen shots as follows: The first 4 letters of your last name, a dash, and a sequence number. For example, if your name is Joe Hatteras, name your graphics: HATT-1.CGI, HATT-2.CGI, etc.

* Put captions for your screen shots in the text as follows: INSERT HATT-1.CGI - Figure 1: Using JavaConnect


Submitting Your Article

When we accept your proposal, we will give you a deadline. If you miss the deadline, your article may not be published. Because of strict editing cycles and schedules, we must have your article by the deadline to ensure that we can use it.

The standard deadline is the 1st of the month for the cover date one month later. For example, an article submitted on February 1 could be published in the March 1st issue. Because of editorial and production reasons, we reserve the right to move your article to another issue if needed.

Some Guidelines to Consider When Submitting an Article

* The article deadline refers to the final draft of your article: A final draft means that it is complete and finished as far as you're concerned. We will edit it further for grammar, style, and technical accuracy. We may ask for further changes, but major rewrites will not be possible because of time considerations. However, you may a submit rough draft prior to the final if you'd like us to review it and get suggestions back to you. Make sure all rough drafts have the words: ROUGH DRAFT at the top of the first page in bold print.

* Submit your article on electronic media. We cannot take the time to retype your article into our systems. You must either e-mail us the article or send us a disk with the files needed. The disk should be formatted for MS-DOS and contain all supporting files and documents needed.

* Separate your article, graphics, and sample outputs into separate files. This goes for screen shots as well.

* Include your personal contact numbers, comments, suggestions, and other pertinent information at the top of your article.

* Include your author biography at the end of your article. We will try to print 3 or 4 lines.

* Please ZIP your files with PKZip, WinZip, or InfoZip. This saves e-mail transmission time and puts all your files into one master compressed file.


Getting paid

These are our pay rates. Payment will be made within 30 days after your submission is published.

Program Tip:
Eye on Objects T-shirt. $25-$50 for lengthy items.

Product or Book Review:
$50 for a single product/book; $150 for a multiple competitive product or book review (minimum three products/books). You get to keep any products you review unless the vendor wants them returned.

Technical Article:
$150

Special Feature:
Negotiated.


Where to send articles

Email to:
Mark Lorenz, Managing Editor, mark@hatteras.com

Snail mail to:
Mark Lorenz
Managing Editor
Hatteras Software
208 Lochside Drive
Cary, NC 27511

Home Page