<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:series="http://unfoldingneurons.com/"
		>
<channel>
	<title>Comments on: Principles for Organizing Print Material [Organizing Content #21]</title>
	<atom:link href="http://idratherbewriting.com/2010/07/30/principles-for-organizing-print-material-organizing-content-21/feed/" rel="self" type="application/rss+xml" />
	<link>http://idratherbewriting.com/2010/07/30/principles-for-organizing-print-material-organizing-content-21/</link>
	<description>The Latest Trends in Technical Communication</description>
	<lastBuildDate>Sun, 27 May 2012 09:07:25 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: Sarah Biddle</title>
		<link>http://idratherbewriting.com/2010/07/30/principles-for-organizing-print-material-organizing-content-21/comment-page-1/#comment-166651</link>
		<dc:creator>Sarah Biddle</dc:creator>
		<pubDate>Mon, 25 Oct 2010 13:26:17 +0000</pubDate>
		<guid isPermaLink="false">http://idratherbewriting.com/?p=7115#comment-166651</guid>
		<description>That&#039;s the &#039;problem&#039; of single-sourcing: it hides the intrinsic differences between the media you use as output. It makes you focus solely on content and less on form. Sometimes I wonder whether single-sourcing offers much benefit. Is it smart to force language into rigid XML-tags?</description>
		<content:encoded><![CDATA[<p>That&#8217;s the &#8216;problem&#8217; of single-sourcing: it hides the intrinsic differences between the media you use as output. It makes you focus solely on content and less on form. Sometimes I wonder whether single-sourcing offers much benefit. Is it smart to force language into rigid XML-tags?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott</title>
		<link>http://idratherbewriting.com/2010/07/30/principles-for-organizing-print-material-organizing-content-21/comment-page-1/#comment-157603</link>
		<dc:creator>Scott</dc:creator>
		<pubDate>Tue, 10 Aug 2010 04:31:56 +0000</pubDate>
		<guid isPermaLink="false">http://idratherbewriting.com/?p=7115#comment-157603</guid>
		<description>Kathy, you make an interesting point. I think what some of us are trying to say is that users&#039; expectations ARE currently that a printed guide will be short enough to consume in one or two sittings, and that more comprehensive reference material can be accessed elsewhere, for instance through the HTML help you talked about (where they are not required or expected to read every page front to back).

And for all intents and purposes, PDF = print. Yes, it&#039;s an electronic file format, but it is a format that is laid out for printing on standard pages and cannot include video etc., so it is basically a print format whether the user decides to use physical paper or not.</description>
		<content:encoded><![CDATA[<p>Kathy, you make an interesting point. I think what some of us are trying to say is that users&#8217; expectations ARE currently that a printed guide will be short enough to consume in one or two sittings, and that more comprehensive reference material can be accessed elsewhere, for instance through the HTML help you talked about (where they are not required or expected to read every page front to back).</p>
<p>And for all intents and purposes, PDF = print. Yes, it&#8217;s an electronic file format, but it is a format that is laid out for printing on standard pages and cannot include video etc., so it is basically a print format whether the user decides to use physical paper or not.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kathy Wellisch</title>
		<link>http://idratherbewriting.com/2010/07/30/principles-for-organizing-print-material-organizing-content-21/comment-page-1/#comment-157581</link>
		<dc:creator>Kathy Wellisch</dc:creator>
		<pubDate>Mon, 09 Aug 2010 20:07:57 +0000</pubDate>
		<guid isPermaLink="false">http://idratherbewriting.com/?p=7115#comment-157581</guid>
		<description>Perhaps one of you could clarify your views for me, because I disagree that “Different media have different purposes.”  I think that regardless of the output format, the purpose is the same:  to provide the information the user is looking for as quickly and easily as possible.  (Of course I recognize limitations to that – quick starts and reference guides have their place. However, these are discrete and time-sensitive topics.  I’m assuming that you are referring to “the help” in general.) 
It seems implicit in your statements that the user must be looking for different information when he looks in either one or the other, but I think that is a faulty assumption.  Why would I expect more – or less – information depending on where I looked?
Why not use an html page to provide conceptual narrative? Use it to create hierarchy and context.  Why should this be specific to a print version? 
By changing the information contained in the print help (vs. the online help), it seems like you are redefining what a manual is without necessarily telling the user that you’ve done it. You’re changing the delivery of information without changing users’ expectations. I don’t necessarily have a problem with shorter printed help, but the user needs to know up front that it’s not supposed to be comprehensive (and where to go for more). 
My own disclaimer:  We never distribute in print, so it’s not an area where I have much experience. We distribute in pdf and html/xml.  Nor do I have much experience with DITA, so perhaps my understanding of the structure you are using is faulty. I’d appreciate any clarification, though.</description>
		<content:encoded><![CDATA[<p>Perhaps one of you could clarify your views for me, because I disagree that “Different media have different purposes.”  I think that regardless of the output format, the purpose is the same:  to provide the information the user is looking for as quickly and easily as possible.  (Of course I recognize limitations to that – quick starts and reference guides have their place. However, these are discrete and time-sensitive topics.  I’m assuming that you are referring to “the help” in general.)<br />
It seems implicit in your statements that the user must be looking for different information when he looks in either one or the other, but I think that is a faulty assumption.  Why would I expect more – or less – information depending on where I looked?<br />
Why not use an html page to provide conceptual narrative? Use it to create hierarchy and context.  Why should this be specific to a print version?<br />
By changing the information contained in the print help (vs. the online help), it seems like you are redefining what a manual is without necessarily telling the user that you’ve done it. You’re changing the delivery of information without changing users’ expectations. I don’t necessarily have a problem with shorter printed help, but the user needs to know up front that it’s not supposed to be comprehensive (and where to go for more).<br />
My own disclaimer:  We never distribute in print, so it’s not an area where I have much experience. We distribute in pdf and html/xml.  Nor do I have much experience with DITA, so perhaps my understanding of the structure you are using is faulty. I’d appreciate any clarification, though.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tom Johnson</title>
		<link>http://idratherbewriting.com/2010/07/30/principles-for-organizing-print-material-organizing-content-21/comment-page-1/#comment-156925</link>
		<dc:creator>Tom Johnson</dc:creator>
		<pubDate>Tue, 03 Aug 2010 16:29:19 +0000</pubDate>
		<guid isPermaLink="false">http://idratherbewriting.com/?p=7115#comment-156925</guid>
		<description>Thanks for your comment, John. I do agree that you can provide more findability with help topics through related topics and other types of relationships. But ultimately, if the help file is large, online help files are non-sequential, non-linear reading experiences. They don&#039;t lend themselves to a logical arrangement other than general folders to try to group similar topics in.</description>
		<content:encoded><![CDATA[<p>Thanks for your comment, John. I do agree that you can provide more findability with help topics through related topics and other types of relationships. But ultimately, if the help file is large, online help files are non-sequential, non-linear reading experiences. They don&#8217;t lend themselves to a logical arrangement other than general folders to try to group similar topics in.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John</title>
		<link>http://idratherbewriting.com/2010/07/30/principles-for-organizing-print-material-organizing-content-21/comment-page-1/#comment-156918</link>
		<dc:creator>John</dc:creator>
		<pubDate>Tue, 03 Aug 2010 15:22:01 +0000</pubDate>
		<guid isPermaLink="false">http://idratherbewriting.com/?p=7115#comment-156918</guid>
		<description>Some interesting points here, but I have to fundamentally disagree with one of your statements. You said, &quot;With online help, you often add a jumble of topics into folders and assume that users will search for answers rather than move in a sequential way through the topics.&quot; WHY? That is surely an incredibly lazy thing to do. Even with online help, topics can be grouped in a logical way to help the user see the relationship between them, especially for related functions. Sure, the user will still search and graze, but if they look at the topic grouping after finding a topic they need, they can see related items without having to guess what words you might have used in your writing.</description>
		<content:encoded><![CDATA[<p>Some interesting points here, but I have to fundamentally disagree with one of your statements. You said, &#8220;With online help, you often add a jumble of topics into folders and assume that users will search for answers rather than move in a sequential way through the topics.&#8221; WHY? That is surely an incredibly lazy thing to do. Even with online help, topics can be grouped in a logical way to help the user see the relationship between them, especially for related functions. Sure, the user will still search and graze, but if they look at the topic grouping after finding a topic they need, they can see related items without having to guess what words you might have used in your writing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Betty</title>
		<link>http://idratherbewriting.com/2010/07/30/principles-for-organizing-print-material-organizing-content-21/comment-page-1/#comment-156861</link>
		<dc:creator>Betty</dc:creator>
		<pubDate>Mon, 02 Aug 2010 22:47:13 +0000</pubDate>
		<guid isPermaLink="false">http://idratherbewriting.com/?p=7115#comment-156861</guid>
		<description>I really appreciate your observations also. I think in getting rid of printable user documentation, we&#039;ve done a disservice to the learning process. I know for myself that I need overview, big picture context when learning something new and complex, and I prefer to read offline when learning. As you say, the Getting Started Guide could just be another PDF online, but the flow would take you from overview concepts to basic tasks and then point to the detailed tasks in the online help. A printable book-like format with chapters or sections is much better for this than online help. It reminds me of an ebook, and people love to read them.</description>
		<content:encoded><![CDATA[<p>I really appreciate your observations also. I think in getting rid of printable user documentation, we&#8217;ve done a disservice to the learning process. I know for myself that I need overview, big picture context when learning something new and complex, and I prefer to read offline when learning. As you say, the Getting Started Guide could just be another PDF online, but the flow would take you from overview concepts to basic tasks and then point to the detailed tasks in the online help. A printable book-like format with chapters or sections is much better for this than online help. It reminds me of an ebook, and people love to read them.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott</title>
		<link>http://idratherbewriting.com/2010/07/30/principles-for-organizing-print-material-organizing-content-21/comment-page-1/#comment-156824</link>
		<dc:creator>Scott</dc:creator>
		<pubDate>Mon, 02 Aug 2010 15:07:26 +0000</pubDate>
		<guid isPermaLink="false">http://idratherbewriting.com/?p=7115#comment-156824</guid>
		<description>I think the question of how to organize a print manual can be answered by deciding whether it makes more sense to write a REFERENCE document, or a GUIDE document. 

A printed guide (more of a conceptual, introductory document) should definitely be shorter, flow coherently between sections, and have an easy-to-grasp table of contents. 

A printed reference document, however, such as a troubleshooting manual or listing of all available reports/features/code tables etc., doesn&#039;t need to flow as easily and it can be as huge as necessary because both author and reader realize that the reader is going to jump to the relevant section, read a small portion, and put it down.

So in that sense I don&#039;t think all print documents need to be short, just the ones that you&#039;re expecting someone to read through cover to cover.</description>
		<content:encoded><![CDATA[<p>I think the question of how to organize a print manual can be answered by deciding whether it makes more sense to write a REFERENCE document, or a GUIDE document. </p>
<p>A printed guide (more of a conceptual, introductory document) should definitely be shorter, flow coherently between sections, and have an easy-to-grasp table of contents. </p>
<p>A printed reference document, however, such as a troubleshooting manual or listing of all available reports/features/code tables etc., doesn&#8217;t need to flow as easily and it can be as huge as necessary because both author and reader realize that the reader is going to jump to the relevant section, read a small portion, and put it down.</p>
<p>So in that sense I don&#8217;t think all print documents need to be short, just the ones that you&#8217;re expecting someone to read through cover to cover.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tom Johnson</title>
		<link>http://idratherbewriting.com/2010/07/30/principles-for-organizing-print-material-organizing-content-21/comment-page-1/#comment-156707</link>
		<dc:creator>Tom Johnson</dc:creator>
		<pubDate>Sun, 01 Aug 2010 01:20:04 +0000</pubDate>
		<guid isPermaLink="false">http://idratherbewriting.com/?p=7115#comment-156707</guid>
		<description>Interesting idea. I hadn&#039;t thought of the idea of a natural flow of content. Thanks for the insight.</description>
		<content:encoded><![CDATA[<p>Interesting idea. I hadn&#8217;t thought of the idea of a natural flow of content. Thanks for the insight.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: When you need help, where do you go first? &#171; Write Trends</title>
		<link>http://idratherbewriting.com/2010/07/30/principles-for-organizing-print-material-organizing-content-21/comment-page-1/#comment-156609</link>
		<dc:creator>When you need help, where do you go first? &#171; Write Trends</dc:creator>
		<pubDate>Fri, 30 Jul 2010 20:31:18 +0000</pubDate>
		<guid isPermaLink="false">http://idratherbewriting.com/?p=7115#comment-156609</guid>
		<description>[...] Patty @ 4:31 pm   A thought-provoking tech-comm discussion is taking place right now over at Tom Johnson&#8217;s blog and got me thinking (told you, it was thought-provoking)&#8230;  how many of us actually use [...]</description>
		<content:encoded><![CDATA[<p>[...] Patty @ 4:31 pm   A thought-provoking tech-comm discussion is taking place right now over at Tom Johnson&#8217;s blog and got me thinking (told you, it was thought-provoking)&#8230;  how many of us actually use [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Larry Kunz</title>
		<link>http://idratherbewriting.com/2010/07/30/principles-for-organizing-print-material-organizing-content-21/comment-page-1/#comment-156607</link>
		<dc:creator>Larry Kunz</dc:creator>
		<pubDate>Fri, 30 Jul 2010 20:14:14 +0000</pubDate>
		<guid isPermaLink="false">http://idratherbewriting.com/?p=7115#comment-156607</guid>
		<description>Tom, I think -- check that, I know -- that I&#039;m biased in favor of indexes. So I have to admit that you&#039;re right: For a short book, an index isn&#039;t going to be useful. People will browse the TOC or, like the young lady in &lt;a href=&quot;http://intercom.stc.org/2010/06/preparing-for-the-next-generation/&quot; rel=&quot;nofollow&quot;&gt;Alan Porter&#039;s recent &lt;i&gt;Intecom&lt;/i&gt; article&lt;/a&gt;, they&#039;ll just skim through the book.

So the emphasis shifts from overt organization to something more subtle: creating a &quot;flow&quot; that anticipates the way in which readers will approach the material.</description>
		<content:encoded><![CDATA[<p>Tom, I think &#8212; check that, I know &#8212; that I&#8217;m biased in favor of indexes. So I have to admit that you&#8217;re right: For a short book, an index isn&#8217;t going to be useful. People will browse the TOC or, like the young lady in <a href="http://intercom.stc.org/2010/06/preparing-for-the-next-generation/" rel="nofollow">Alan Porter&#8217;s recent <i>Intecom</i> article</a>, they&#8217;ll just skim through the book.</p>
<p>So the emphasis shifts from overt organization to something more subtle: creating a &#8220;flow&#8221; that anticipates the way in which readers will approach the material.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

