This week’s edition of the Communications from DMN podcast has been posted. This week, we discuss using Basecamp to collaborate on and manage a project. We also present our Pick of the Week: the EServer Technical Communication Library.
The results are in… and we’re feeling the love from our initial podcast. Scott and I are thrilled (and suprised?!) that listeners from North America, Europe, the Middle East, and Asia were able to catch the first attempt at our new weekly podcast, Communications from DMN. Thank you for checking us out!
As they say, the best is yet to come. If you’ve checked out our podcast, we’d love to hear your comments and suggestions as we’re still very much in the “baby steps” phase. We welcome your feedback at firstname.lastname@example.org.
The article “Putting the Writer Back into Technical Writing” is an interesting treatise on the role of technical writing, and on how good writers can improve documentation. Often, I find that the role of good writing is undervalued in technical writing.
However, being a good writer doesn’t mean that you’ll be an effective technical writer. You really need to balance the skills of a writer/researcher/editor with the technical knowledge required to do the job.
One of the more popular tools for generating online help is Quadralay’sWebWorks ePublisher Pro. The product is solid, but it has a fairly steep learning curve. But now there’s something to help both the fledgling and experienced ePublisher Pro user: the WebWorks wiki.
Even though the wiki has only been around for about a week (as of this writing), it boasts an extensive FAQ section and growing reference portion. On top of that, there are screen demos of the product. The tips are a bit thin at the moment, though.
Like any other wiki, users can add and edit pages (registration required). So, if you have any tips, WebWorks tricks, techniques or templates you can share them with other users.
The first edition of our podcast, Communications from DMN, is now available. This edition introduces our podcast and what you can expect to hear in the coming weeks. In future podcasts, we’ll be presenting tips, information, and reviews of software, books, and Web sites that we find interesting and useful, and hope you will too. Tune in. You might just learn something.
The job of a technical writer is to make the complex easy to understand. Far too often, though, this doesn’t happen. Take the subject of this blog entry at Signal vs. Noise.
The entry discusses the description of a conference called “Simplicity: The Art of Complexity.” The description is far from simple. In fact, it’s complex almost to the point of incoherence. Take this excerpt for example:
Simplicity begins, of course, with usability. The wish for user-friendly devices and programs is fervent and widespread.We will realize how justified it is when we inspect the plethora of shabbily designed user interfaces that hit the retail shelves in ever-shorter marketing cycles. So even as the writers of advertising- copy are busy ballyhooing the latest results of their company’s purported fixation on user experience and user-centered design, the reality that we, the ones who have actually purchased these applications, are familiar with is, sadly, a different one. How very often we wish that industrial designers would pay more frequent courtesy calls on media artists and soak up a bit of the ambient inspiration during their visits!
Either the entire description was badly translated, or it was written by someone whose native language isn’t English. If it was written by a native speaker, then that person should be sacked. Or, at the very least, sent to a remedial writing course.