Writing a technical feature for EDN

November 14, 2012

EDN Network 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 to spotlight what you've accomplished and contribute to the knowledge ecosystem.

In fact, your contributions are so highly valued that we added a new category to the annual ACE Awards called the "Jim Williams Contributor of the Year Award" which goes to, "the engineer who has contributed most significantly to the advancement of knowledge in the field of engineering and design through their own bylined feature articles or on-going technical and educational blogs."

The award is named after Jim Williams of Linear Technology, who passed away in 2011 and who remains an example to all of what contributing and giving back to the engineering profession is all about. The winner is selected by EDN's own community and editors and is announced at The Embedded Systems Conference during the ACE Awards.

So, here is a brief summary of what works and how to go about getting an article published on 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. All of the articles accepted by EDN will be published online, within one of our Design Centers, possibly with additional editing to make sure they are accessible to a wide audience.

What works and what doesn't
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, or in a case-study format, describing the chronology of one particular team's encounter with a challenge, and one or more possible solutions they may have come up with. 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.


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 Editor-in-chief Michael Dunn. Note that we say proposal. This means an abstract, an outline, or simply a description of the article. We'll consider a completed manuscript if you state that it hasn't been submitted elsewhere.

Michael will review the proposal and/or route it to the appropriate editor, who will review it based on the above guidelines and their view of the questions facing engineers in the related field. 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 an agreement form to complete, giving us full and exclusive worldwide rights to your article in perpetuity, though generally we will agree to reuse by you after a specified period of time.

We reserve the right to edit the article as required, and will send you a review copy on request.

Mechanical requirements
Articles are typically 1,000 to 4,500 words but can be of any length. (For pieces beyond 2,500 words, we suggest breaking it into a series.)

We also welcome guest blogs, which are often shorter and lighter than full articles. And if you have more ideas to share, you may even become a regular paid blogger on the site.

Please provide the article in Microsoft Word, Open Document, or plaintext 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 as a separate file. Please review the following details:
  • Text: In Word, do not use any special document formatting or styles beyond the basic defaults. Feel free to use boldface (e.g., subsection headings), italics, sub/superscripts (e.g., VF is correct, not the lazy Vf), lists, and Unicode characters (Ω, µ, ±, ×, °, etc.). Be consistent in your writing and terminology.
  • Equations: Simple equations should be written in text mode. More complex ones can use the equation mode of Word or Libre/OpenOffice, or can be submitted in MathML.
  • Figures: Please provide each figure as a separate file in JPEG, PNG, GIF, TIFF, EPS, or PDF format. Use appropriate formats (e.g., GIF or PNG for schematics and other line art, not JPEG!). Reference each figure in the article text, and number the figures in the order in which they are referenced. If you are not the image creator, be sure to attribute the source in your caption, and include a statement to us confirming all images have been cleared for use. Images must be high quality, and at least 1,000 pixels wide if not vector art.
  • 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.
  • Profile: The author(s) of the article will need to be registered at EDN.com and update their public profile page as they would like it to appear, since readers will be sent to that profile for "about the author" information. Include your user name with your submission so we can easily find the correct profile.


Also see:


Loading comments...

Write a Comment

To comment please Log In