I have two comments on this.

1. One I do not subscribe to the one information architecture to rule them all. A deliverable should be based on a business case. The business case is inevitably going to depend on your audience and what your audience needs. And I do not buy that topic based authoring is going to be a suitable answer for everyone in every situation. I see topic based authoring as a popular, common, and useful depending on the business case and the audience.

However, there are many, many complex topics that require topic-to-topic dependencies and use hieracrchy to provide the user a guided learning experience. I believe we call this a book.

My prediction is that instead of topic based authoring replacing books, we will need to do topic based authoring in addition to book based authoring. The topic based authoring will be the first contact that end users have with documentation, and will be used to guide writers in determining what topics actually need book level treatment.

In other words tech writers get the worst of both worlds as it were. We will have wedding day publishing and day to day publishing too.

2. Frequently, you must work in the environment that you cannot control. This means dealing with a distribution platform that makes topic based authoring virtually impossible. In my case, I must distribute all documentation through salesforce.com and my company will NOT use any other mechanism to do this for a variety of business reasons. SF.com is an evil, horrible, unbelievable awful distribution mechanism for any type of documentation. The search mechanism is atrocious and they don’t supported hierachical folder structure.

In that kind of environment, PDFs is the best you can do. I suspect that this issue will be addressed once legacy technology dies off in the next 15 to 20 years but until then I bet PDFs will be the primary deliverable for a lot of enterprise environments. I am not saying that’s a good thing; but moreso just making an observation.

Simon is right . Please let us know more details about the issue you encountered with the application help, for example what operating system you are using and if you remember what you tried to search.
Actually the online help is the same thing as the application help, it is just a different rendering of the underlying DITA map that we have for our user guide so basically the difference is in what the target output format offers.

Regards,
George

A nice feature of oXygen is that it keeps you on the straight and narrow. In Text mode it constantly validates your markup so that any mistakes are immediately apparent, and in Author mode it prevents most mistakes altogether. After a while you get a sense of how the elements are related, what works, and what doesn’t work.

Since you’re located in the Raleigh-Durham area you might be interested in the RTP Dita Users Group, which meets on the fourth Wednesday of each month for networking and a presentation about a DITA-related topic. You can attend the meeting in person or by webinar. Check out the Yahoo group for more information, or just give me a shout.

I agree this change is both difficult and necessary. The change does not start at the tools level. It starts with information design. Even though more and more people are learning to write in topics, they are still creating topics that have hard dependencies on other topics, and still mapping and managing those dependencies largely by hand.

Even if we addressed the comparatively trivial tools issue of being able to publish the last blessed version of a topic while work is in progress on the next version, we would still be stuck in wedding-day publishing as long as it remained necessary to manage the dependencies of each topic to ensure the successful publishing of the whole.

The fundamental problem I see here is that writers are accustomed to expressing the relationships between subjects as the relationships between topics. Thus the understanding of the structure of a system or its workflow is expressed by an organization of topics (or the organization of a book).

The solution I advocate will come as no surprise: Every Page is Page One topics. Every Page is Page One topics express subject-to-subject relationships (usually through links) but they do not have topic-to-topic dependencies. There is no previous, next, or parent topic. Each Every Page is Page One topic and be published when it is ready, without the fear of breaking topic-to-topic relationships.

The web, of course, is full of Every Page is Page One topics. User of WordPress and Drupal will frequently be writing blog posts or web pages, which tend to be Every Page is Page One by nature.

But while it is easy enough to create one-off Every Page is Page One topics, writers faced with producing a large body of related information on a product or process have a hard time figuring out how to express this information in a way that preserves and expresses the relatedness of the subject matter without expressing the relatedness of the subject through the relationships of the topics.

Until we learn to do this, we will have a hard time moving away from wedding-day style publishing. To Daniel’s point, the generation raised on blogs, tweets, and Facebook may very naturally figure out how to express these relationships in ways that are compatible with an Every Page is Page One information design. EPPO is, after all, the default information design of the Web. But can we afford to wait for generational change to address the problem? I don’t think so.

That said, the business reasons for moving away from batch publishing are compelling, so the industry will get there. Eventually.

Here’s an amazing local vendor: http://www.acupcakebar.com/ (I chose the pictures for visual appeal and Creative Commons license—no idea where those vendors are!)

Our clients are started to demand just-in-time publishing. Or, more accurately, their business need is to shorten the delay between product shipment and documentation delivery.

The major problem I see is that most techcomm tools don’t support incremental publishing. We’re building a lot of custom “stuff.”