Aleksandar • Vacić

iOS bits and pieces

Writing print articles

Few months ago, I started writing articles for the most influential computer magazine in Serbia, PC. I wanted to spread the word about modern web design, CSS-based, semantic markup and similar stuff.

Initial spark was annual Serbian Top50 list, traditionally chosen by PC staff at the end of the year. Of those 50 sites, none was nowhere near validity, semantics. They were (are) all technically outdated. The mag’s site itself was like that (built by me in 2002, I plead guilty) - I added DOCTYPE recently and corrected the mistakes I could.

First article I wrote (for March ‘04 issue) was purely a commentary on that finding, written in the single breath. When it was published, I realized large part of the article was edited to better fit the mag’s style…and soften my bashing a bit. Lesson learned.

Later articles deal with importance of markup validity, semantic markup, CSS etc. Each next article had less and less edited parts. The lesson I learned is that print articles are written over period of several days, even weeks.

The second article I wrote was done in 3 days. I let it be for two days. Then I read it again and realized that it’s poorly written. There was no clear flow of the content. I would talk about one thing, then mention something related, then expand the related part to whole paragraph until the point I completely lost the context. Someone reading that would probably be very confused what exactly I’m talking about.

So enter streamlining process.

Print publications are not blogs. Once it’s printed, there is no going back. You can’t return and correct mistakes or re-phrase sentences. Over the last few months, I developed the process of writing.

In the first phase, I simply collect resources. I write like a maniac, two or three paragraphs in a spree. Some of them are not really related to each other, but all related to the subject. This can last from 2 to 7 days or more (like in the case of CSS basics I’m currently writing).

In the second phase, I organize the parts so they have natural flow. I decide on the main theme and exclude parts not strictly related to it. All usually done in one or two days.

Then comes the hardest part. I read the whole piece and re-phrase parts, divide into chapters (err…sort of), connect them…Then I repeat this after a day or two. Then repeat again, and again…

On each reading I find parts sounding bad or don’t fitting-in with the rest of the article. After that is over, I ask friend(s) to read it, to gain different perspective. I’m lucky in this, as I have friends working for the web but mostly on the server-side. They understand what’s written, even though they have never used CSS-based design or semantic markup. Such feedback is very valuable and always result in subtle changes which I would not bother with, since I eat & breath with CSS, semantics, validation and rest of the crowd.

Only then it’s ready to be sent to the editor.

Writing articles is hard. Very time-consuming. But worthwhile and rewarding.