<?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/"
		>
<channel>
	<title>Comments on: A Possible New Step in the Writing Process</title>
	<atom:link href="http://www.gryphonmountain.net/2009/09/a-possible-new-step-in-the-writing-process/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.gryphonmountain.net/2009/09/a-possible-new-step-in-the-writing-process/</link>
	<description>Technical Communication and Other Writing Topics (by Ben Minson)</description>
	<lastBuildDate>Thu,  9 Sep 2010 15:59:36 -0500</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Margaret</title>
		<link>http://www.gryphonmountain.net/2009/09/a-possible-new-step-in-the-writing-process/comment-page-1/#comment-34522</link>
		<dc:creator>Margaret</dc:creator>
		<pubDate>Thu, 03 Sep 2009 16:52:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.gryphonmountain.net/?p=731#comment-34522</guid>
		<description>I think we should write all user manuals, tutorials, help, or step-by-step procedures as close to a conversational style as possible. I try to write as if I were standing behind someone and personally walking them through the process. I also try to put in plenty of screens or fragments of screen shots so they can compare what they get after each step to confirm that they are in the right place.

For IT or technical types, I draft the docs the same way, but then extract each installation or configuration procedure to a checklist with a block for installer and system/network/ terminal/client  identification, and date and initial verification fields for each section, so that the checklist becomes a verification record that the installation was completed, when, and by whom. And it can easily be returned to for completion if the installer was interrupted during the process.</description>
		<content:encoded><![CDATA[<p>I think we should write all user manuals, tutorials, help, or step-by-step procedures as close to a conversational style as possible. I try to write as if I were standing behind someone and personally walking them through the process. I also try to put in plenty of screens or fragments of screen shots so they can compare what they get after each step to confirm that they are in the right place.</p>
<p>For IT or technical types, I draft the docs the same way, but then extract each installation or configuration procedure to a checklist with a block for installer and system/network/ terminal/client  identification, and date and initial verification fields for each section, so that the checklist becomes a verification record that the installation was completed, when, and by whom. And it can easily be returned to for completion if the installer was interrupted during the process.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gordon</title>
		<link>http://www.gryphonmountain.net/2009/09/a-possible-new-step-in-the-writing-process/comment-page-1/#comment-34494</link>
		<dc:creator>Gordon</dc:creator>
		<pubDate>Thu, 03 Sep 2009 08:17:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.gryphonmountain.net/?p=731#comment-34494</guid>
		<description>Interesting.

I&#039;ve challenged my team to write up a couple of short (1-2 page) overviews of distinct areas of the product, with a conversational slant. The aim is to get across some of that useful information that is a bit grey, and not the stuff we&#039;d normally have in the formal product documentation.

This might be a good way for them to focus their planning though.</description>
		<content:encoded><![CDATA[<p>Interesting.</p>
<p>I&#8217;ve challenged my team to write up a couple of short (1-2 page) overviews of distinct areas of the product, with a conversational slant. The aim is to get across some of that useful information that is a bit grey, and not the stuff we&#8217;d normally have in the formal product documentation.</p>
<p>This might be a good way for them to focus their planning though.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
