<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: The Big Picture</title>
	<atom:link href="http://www.onemanwrites.co.uk/2008/02/12/the-big-picture/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.onemanwrites.co.uk/2008/02/12/the-big-picture/</link>
	<description>musings on technical communications</description>
	<pubDate>Tue, 07 Oct 2008 03:02:32 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.1</generator>
		<item>
		<title>By: The all-knowing technical writer &#171; Technical Communication 2.0</title>
		<link>http://www.onemanwrites.co.uk/2008/02/12/the-big-picture/#comment-2546</link>
		<dc:creator>The all-knowing technical writer &#171; Technical Communication 2.0</dc:creator>
		<pubDate>Thu, 13 Mar 2008 16:49:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.onemanwrites.co.uk/2008/02/12/the-big-picture/#comment-2546</guid>
		<description>[...] part is that you must rid yourself of your beloved deliverable, a dilemma discussed also by Gordon McLean. Your content must be suitable for various publishing channels (that your team has defined). You [...]</description>
		<content:encoded><![CDATA[<p>[...] part is that you must rid yourself of your beloved deliverable, a dilemma discussed also by Gordon McLean. Your content must be suitable for various publishing channels (that your team has defined). You [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tanja</title>
		<link>http://www.onemanwrites.co.uk/2008/02/12/the-big-picture/#comment-2499</link>
		<dc:creator>Tanja</dc:creator>
		<pubDate>Sat, 08 Mar 2008 07:00:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.onemanwrites.co.uk/2008/02/12/the-big-picture/#comment-2499</guid>
		<description>I hear you. Lately, I have been thinking about similar issues myself. What to do when talking about "deliverables" is not enough anymore?

If a team defines itself via its deliverables, it risks being forever labeled "the team that does user guides" or "the team that does helps". Even worse, the team risks limiting itself by the print guide thinking you descibed. Even when they would be or could be doing so much more. It can be safer, and more accurate, to explain that you are creating content that is used in various ways.

What are those various ways then? There are so many aspects to consider. 

- Tangible deliverables. Some of the content you create still gets compiled into printed user guides, PDF files for the web site, a help file, or something else that you can still call a deliverable.
- But what is the rest? Just content, compiled together based on topics or content types, for example. If your content appears here and there everywhere on a web site, you cannot necessarily call that a deliverable in the traditional sense. It is also possible to produce separate content types, such as tips, shortcuts, or Q&#38;As that can be used in multiple ways.
- Publishing channel: Web, mobile, help...
- Publishing format: PDF, HTML, XML, any help file format...

I'm trying to eventually find a short and snappy way of describing all this :-)</description>
		<content:encoded><![CDATA[<p>I hear you. Lately, I have been thinking about similar issues myself. What to do when talking about &#8220;deliverables&#8221; is not enough anymore?</p>
<p>If a team defines itself via its deliverables, it risks being forever labeled &#8220;the team that does user guides&#8221; or &#8220;the team that does helps&#8221;. Even worse, the team risks limiting itself by the print guide thinking you descibed. Even when they would be or could be doing so much more. It can be safer, and more accurate, to explain that you are creating content that is used in various ways.</p>
<p>What are those various ways then? There are so many aspects to consider. </p>
<p>- Tangible deliverables. Some of the content you create still gets compiled into printed user guides, PDF files for the web site, a help file, or something else that you can still call a deliverable.<br />
- But what is the rest? Just content, compiled together based on topics or content types, for example. If your content appears here and there everywhere on a web site, you cannot necessarily call that a deliverable in the traditional sense. It is also possible to produce separate content types, such as tips, shortcuts, or Q&amp;As that can be used in multiple ways.<br />
- Publishing channel: Web, mobile, help&#8230;<br />
- Publishing format: PDF, HTML, XML, any help file format&#8230;</p>
<p>I&#8217;m trying to eventually find a short and snappy way of describing all this :-)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gordon McLean</title>
		<link>http://www.onemanwrites.co.uk/2008/02/12/the-big-picture/#comment-2495</link>
		<dc:creator>Gordon McLean</dc:creator>
		<pubDate>Fri, 07 Mar 2008 23:23:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.onemanwrites.co.uk/2008/02/12/the-big-picture/#comment-2495</guid>
		<description>Good on you Marcus, always deliver what the audience want!</description>
		<content:encoded><![CDATA[<p>Good on you Marcus, always deliver what the audience want!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marcus</title>
		<link>http://www.onemanwrites.co.uk/2008/02/12/the-big-picture/#comment-2494</link>
		<dc:creator>Marcus</dc:creator>
		<pubDate>Fri, 07 Mar 2008 21:31:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.onemanwrites.co.uk/2008/02/12/the-big-picture/#comment-2494</guid>
		<description>That was interesting to read. I'm currently switching from writing book-centric documentation to DITA and find it diffcult at times to keep that old book/chapter thinking out of my head...

As for "Deliverables are dead"; we recently conducted a survey amongst our main audience and asked them which format and presentation type they like best for the documentation (we have PDF, HTML with Java or JavaScript navigation, JavaHelp and CHMs) and about 90% of them voted for the good old PDFs.

With that in mind we decided to continue using FrameMaker, because of its excellent PDF output, although it's probably not the best tool for DITA.</description>
		<content:encoded><![CDATA[<p>That was interesting to read. I&#8217;m currently switching from writing book-centric documentation to DITA and find it diffcult at times to keep that old book/chapter thinking out of my head&#8230;</p>
<p>As for &#8220;Deliverables are dead&#8221;; we recently conducted a survey amongst our main audience and asked them which format and presentation type they like best for the documentation (we have PDF, HTML with Java or JavaScript navigation, JavaHelp and CHMs) and about 90% of them voted for the good old PDFs.</p>
<p>With that in mind we decided to continue using FrameMaker, because of its excellent PDF output, although it&#8217;s probably not the best tool for DITA.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kat</title>
		<link>http://www.onemanwrites.co.uk/2008/02/12/the-big-picture/#comment-2218</link>
		<dc:creator>Kat</dc:creator>
		<pubDate>Wed, 13 Feb 2008 07:41:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.onemanwrites.co.uk/2008/02/12/the-big-picture/#comment-2218</guid>
		<description>This sounds really exciting! Give us more news....</description>
		<content:encoded><![CDATA[<p>This sounds really exciting! Give us more news&#8230;.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
