Author Guidelines

Authors: Before submitting an article to Web Review, or after one has been assigned by an editor, please take a moment to look over these guidelines on our readership, our style, and how to submite articles. Thanks, -- Ed.

Web Review's Readers

Web Review's audience includes designers, developers, marketers, editors, and producers. Everyone specializes in something, but no one masters everything. Assume you're writing for an intelligent, Web-savvy reader, but one who is not a specialist in the field you're writing about. Define terms they may not know. Avoid jargon unless it's explained. Try to put context around what you're doing: before explaining details of a task, explain why you're doing it, and why you're doing it this way instead of another way.

Probe the Details

Don't just report on how a program, app or technology is supposed to work. Share your frustrations or suggestions for improvement.

Get Multiple Sources

Pick up the phone and talk to the developer and to users. The developers will offer insight on what was included and why, and what's planned for the next version. Users will make comparisons to other tools and will often tell you what's not quite right (including some things you may have missed).

Write tight for the Web

The less you write, the better. Say what you mean, and then get out. This is especially true on the Web, as opposed to print, where readers may linger over an article. Readers want explanation, examples and code —real things they can grok, and move on. A smile or two along the way helps, also.

Web Review articles are short. Columns may be 600 to 1,000 words. Features can run 1,200 to 2,000 words maximum. We try to avoid the 5,000 word chapter. It's too much to edit and produce on our weekly schedule, and few readers will read that much online.

Avoid unnecessary words

This is part of writing tightly. Writers (especially technical writers) often add words or use unnecessarily large words to make what they're writing seem more official, important or intelligent. Break the habit. Write like a tough guy. Editors and readers will love you.

• "A single table" can usually be "one table" or "a table."
• "This is the view I use for entering and editing data" becomes "I use this view to enter and edit data."
• "could conceivably be" means the same thing as "could be".
• Unnecessary phrases like, "Please notice that..." can usually be dropped.

Write in the Active Voice

It makes a more interesting read, it forces the author to own his or her actions, and it usually shortens the text.

"Now that the focus of the database is clearly defined and some research has been done on the existing databases, the next step is to actually design the data structures."

becomes...

"Now that we've defined the focus of the database, and we've done some research on existing databases, we can design the data structures."

Proofread your Work

After you finish your article, put it aside for a few hours or overnight. Then give it a careful read for typos and other mistakes. Make sure your meanings are clear. Your editor will appreciate it.

Submitting Articles

Submit articles in plain text, MS Word, or basic HTML. Avoid any formatting beyond tables, bullets and subheads (use h3). Avoid using HTML editors that add extraneous code (e.g., font settings before and after paragraphs). They just create more work for us, as we have to remove that coding. Don't use style sheets.

Email articles as attachments or in the body of the email to the assigning editor at least one week before publication.

Payment

Submit your invoice with the article. Payment is usually within 3-4 weeks of publication.