Writing a technical feature for EDN

EDN is built upon communications between working electronics engineers. We welcome any correspondence from design, research or managing engineers, and especially encourage you to propose contributed articles. Here is a brief summary of what works for us and how to go about getting an article published in EDN.

The purpose of contributed articles

EDN's reason for existence is communications between engineers on the design problems they are facing. Often the most effective way for us to identify an emerging design challenge, to dissect how to analyze a challenge, or to describe a solution is to use the words of working engineers engaged with the challenge. Get it first-hand, in other words.

This is the purpose of our contributed-articles program. We hope to provide to our readers not only the kinds of formal papers that make the best keynotes and invited papers at technical conferences, but also the detailed papers that would highlight a technical session, and even the kinds of real-world conversations that happen in the halls between sessions. In an age when not everyone has time to attend conferences, to network with their technical peers, or even to be aware of who else in the global engineering community is working on a particular problem, we want to help engineers talk to each other about their challenges, thinking processes, ideas, and solutions.

We welcome this input from vendors' applications and design engineers just as much as from any other working engineers. We do not, however, have a place in this context for promotional material such as product descriptions or glowing, made-up use scenarios. That is marketing communications, not engineering communications, and belongs in other venues.

EDN's audience

EDN serves an audience of working engineers. This family includes design engineers; architects; members of technical staff; research engineers; evaluation, verification and test engineers; and technical managers. Many of the articles accepted by EDN will be published on the Web. Articles we judge most noteworthy-signaling new ways of thinking about a range of design issues-ormost broadly applicable across engineering communities will also be published in EDN's print edition, possibly with additional editing to make sure they are accessible to a wide audience.

What works and what doesn't

We know from long (and sometimes bitter) experience what generally works for EDN readers and what generally doesn't. Here is a quick summary.

EDN readers value articles that provide a clear statement of a design challenge and provide a specific means of approaching the problem, or a known solution. This information can be presented as a simple essay, as in a whitepaper, or in a case-study format, describing the chronology of one particular team's encounter with a challenge. Our readers also like articles that give a technical, even mathematical, analysis of a situation so that they can work out answers for themselves. Even articles that describe a problem without proposing a solution are valuable if they contribute to the engineering community's attempts to understand the challenge.

Some kinds of articles simply don't work for our audience. The prime example is the product pitch. A story that simply describes the features and benefits of a new product will not be read beyond the first few paragraphs. A closely related article type is what one of our editors calls the "and as if by magic" story. This purports to be an article of the problem-solution type, but in fact the definition of the problem has been carefully crafted to match the benefits of a particular product. So after a brief statement of the problem, the article becomes a features/benefits description.

Needless to say, articles that do not address challenges faced by working engineers cannot find an audience at EDN.

Style

EDN is not a technical conference nor an encyclopedia. We encourage writers to write for our audience as they would for other team members within their own design group, or for that matter in their engineering notebooks. We encourage active, rather than passive, verbs, simple sentences, and limiting technical terms to those that would be understood within the intended engineering audience.

That said, there is no need to write for a "general" engineering audience, and certainly not for lay readers. We try to spell out any acronyms that might be ambiguous, company-specific, or otherwise mysterious. We encourage enthusiasm and even humor when it does not obscure the technical content. Write as you would to a friend from engineering school.

Our process

The article process begins when you submit a proposal to Amy Norcross, amy.norcross@ubm.com. Note that we say proposal. This means an abstract, an outline, or simply a description of the article. We generally do not consider or accept completed manuscripts submitted without an approved proposal.

Amy will route the proposal to the appropriate editor, who will review it based on the above guidelines and her or his view of the vital questions facing engineers in the related field over the next few months. The editor will then reply with a set of suggestions for moving from the proposal to a draft, including a suggested timeline. In some cases, the editor may decline the article altogether at this stage.

You then respond to the editor either with a draft article, or by yourself declining, if it appears that what we need doesn't match up with what you want to write. The editor will review the draft and either accept it or request changes.

Once the draft is accepted, you will be sent a set of forms to complete, giving us full and exclusive worldwide rights to your article. This is necessary not only because Web publishing is inherently worldwide and perpetual, but because our sister publications in Europe and Asia print material that first appears in EDN. Your article will be scheduled for publication on the Web and possibly in print, at our discretion.

We will perform a final edit for style, not content, and send you a review copy. Sometimes this review copy arrives only a few days before we must put a print article on the page, so you may have relatively little time in which to review it. But once your review is completed, you're done.

Mechanical requirements

Articles are typically 2500 to 4500 words but can be of any length.

Please provide the article in Microsoft Word format. You may place illustrations/photos, tables, equations, and captions in their proper places within the body of this file. However, because Word does not always present images and other elements in the best light, you also must provide each illustration/photo, table, and equation as a separate file. Please review the following details:

• Text: In Word, do not use special formats such as paragraph indents or spacing. Keep all text in the "Normal" style, but feel free to vary font size in order to distinguish headlines or sub-headlines. Feel free to use boldface, italics, and the special characters available under Word's "Insert, Symbol" menu (Ω, µ, ±, ×, °, etc.).
• Equations: Please provide each equation in a separate .gif file.
• Tables: Please provide each table as a separate file in Microsoft Excel format.
• Figures: Please provide each figure as a separate file in .jpg, .tif, .eps, or .pdf format. Do not send PowerPoint slides. Figures must be high-resolution-nominally, a minimum resolution of 300 dpi with a width of at least 4 inches. Please reference each figure in the article text, and number the figures in the order in which they are referenced.
• Screen Shots: Avoid these, as they will be virtually unreadable in print.
• References: References may be included in the main text file. If they are cited in the text, please ensure that they are numbered in order of citation.
• Biography: Please provide a biography of no more than 100 words for each author. You may also provide a photo of each author (following the specifications for Figures, above), but it is not required.