But that just gets you a build reviewers still have to dig around to see what parts changed. That's fine in one sense - we can do a build from the branch, so reviewers can see what the documentation looks like. Some of our reviewers would prefer to look at the changes in the HTML output. This diff is very helpful for reviewing a PR, if you're comfortable reviewing by reading the raw XML. This means that at the end we have a git pull request (PR) that can show a diff between the branch and the main (master) branch. (Flare source is a very HTML-y XML with some Flare-specific additions.) We use git for source control and new work is done on branches. Simply put, when the multi-single-source dilemma is solved, everyone wins.We use Madcap Flare for a large documentation set, with HTML output. Just as importantly, it influences prospects and customers for all of the right reasons - which means better engagements, shorter sales cycles, larger deal sizes, and more profits. This is not just a clear benefit for technical writers and other internal content producers and users. Ultimately, rather than being held back by a single-source publishing paradigm that was designed for a old world business landscape that no longer exists, Zoomin’s dynamic delivery platform augmented by taxonomy enables companies to deliver a consistent message and brand story across all content, and through all touchpoints and channels.
Utilize a common taxonomy of metadata terms to use across the entire content set.Publish into a single dynamic delivery hub.As such, instead of trying - and almost certainly failing on a logistical, if not political level - to get all business units and teams to adopt a single format, and spending an enormous amount of time and money updating volumes of legacy content, companies: Zoomin embraces a variety of single-source formats, and uses taxonomy as the glue to make them come together as part of a single, cohesive ecosystem. Rather, they can step-up to a dynamic delivery platform such as Zoomin. Thankfully however, is it not where the story ends.Ĭompanies saddled with – and technical writers burdened by - an outdated single-source publishing approach do not have to hit the reset button, and re-invent their content production and distribution approach. They are facing a major business problem that will only grow more costly and complex as the future unfolds. And since great content plays a role at every stage of the buyer’s journey, this means that companies are not just wrestling with a difficult documentation issue.
Consequently, companies cannot meet their own standards – or their prospects’ and customers’ expectations - for consistency in branding and format, findability, navigation, accessibility and accuracy. Simply put, single-source publishing cannot handle - and was never designed to govern and manage - a disparate mix of documentation formats in a practical, efficient way. And while much of it may be in DITA, there is usually plenty of other stuff, such as markdown, legacy content (FrameMaker, Word, Madcap Flare, etc.), multiple XML structures, content obtained through corporate acquisitions, content written in systems like Salesforce and Confluence, and the list goes on. This is because content in multi-source publishing environments is created and used by different teams, business units and so on. However, when they are expected to apply this approach in a multi-source publishing environment, the concept breaks down – and the dream of streamlined efficiency and greater ease, often turns into a nightmare of extra work and added stress. For years, tech writers have successfully instituted single-source publishing.
0 kommentar(er)
