Welcome to the ITauthor Podcast. If you haven't been here before, this is a technical writing podcast, aimed at technical communicators or anyone interested in software documentation. The latest podcasts are on this page. You can listen to the podcasts here and now by clicking the play button on the audio player at the top of the show notes for each podcasts, or you can subscribe to the podcast feed or the email list. All of the previous podcasts are available on the Podcast Archive page. Please feel free to leave a comment or ask a question. Thanks for visiting!
Looking for a better way of reviewing a WebHelp system recently brought it home to me how good Adobe Acrobat's shared review functionality is. I want something that does pretty much exactly the same thing but for Web pages. However, it seems like no such thing exists.
In this podcast I describe why Acrobat shared review is so good and why the closest things I could find (WebNotes and SharedCopy) just don't do what I'm looking for.
This video shows how to configure and create a shared review in Acrobat Pro. Because it goes through the configuration steps for setting things up, it makes it all look much more time-consuming than it actually is. Once you've set this up, generating the shared review is simple. We used the same internal server approach demonstrated here (using a WebDav folder on the server) and it works really well for us.
Test Manager Richard Paterson joins Graham Campbell and me over lunchtime sandwiches in a rather noisy office to talk about software testing.
Technical writers in a software development department often feel like third-class citizens, with programmers as the top-dogs and testers being granted second-class status. This engenders a certain camaraderie between fellow poor relations, testers and tech writers, filling, as they do, roles that are sometimes viewed as subordinate or auxiliary to the majority party within the development department. The work of testers and tech writers often starts at around the same time, and both roles can be subject to "ship early" pressure to keep the time available to them to a minimum.
But like tech writers, testers - rightly - believe that what they do is a crucial, if undervalued, function for the creation of quality software products.
Amongst other things, I ask Richard:
What is software testing?
Why do we need testers? (Can't programmers just test their own code?)
What's the difference between: unit tests, integration tests, regression tests, functional tests, user acceptance tests, lean testing ...?
How do testers and programmers get on? (Don't programmers get really irritated by testers finding bugs in software the programmer thought was working fine?)
Why can't we introduce automated testing and save on all the money we're paying all those testers?
Are technical writers as useful to testers as testers are to technical writers?
Who'd be a tester?
Got any thoughts on the matter? Leave a comment below.
Ever wondered how news and blog posts appear in Google Reader or how podcasts get onto your iPod? It's largely thanks to something called RSS.
What does RSS stand for? Who invented it? What happened along the way? This podcast tells the story of RSS, from its earliest beginnings in 1995, through the births of XML, blogging and then podcasting, to the present day.
For the full script of this podcast, with lots of lovely pictures, look no further than: http://www.itauthor.com/2010/03/16/a-history-of-rss/ This page also has a full list of references for all the quotes and clips I used.
No sooner had I recorded this podcast than it was out of date. Right at the end I describe Tim Bray as leaving Sun Microsystems. He has since taken the position of "Developer Advocate" at Google. I also said that the last Daily Source Code appeared in February 2009. That was true at the time but yesterday Adam Curry resurrected it with DSC822.
The music I play at the beginning and end of the show is by Amplifico. You can hear more of their music at Podshow.
For this edition of the ITauthor podcast, I just turned the microphone on and started talking. So if ums and ahs annoy you, this podcast probably isn't for you!
I ruminate over whether it's acceptable to use unscripted, unpolished screencasts in published documentation. Does it matter if you stumble over your words once or twice, um and ah, and have to correct your typing as you go along? Does the unscripted approach add an element of authenticity and make the whole thing more realistic and believable?
I also talk about the functionality I've been adding to our Madcap Flare projects to provide alternatives to the built-in glossary popups and expanding sections.