<?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: Usability and Maintainability: Instructions They Can Follow</title>
	<atom:link href="http://www.gryphonmountain.net/2009/01/usability-and-maintainability-instructions-they-can-follow/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.gryphonmountain.net/2009/01/usability-and-maintainability-instructions-they-can-follow/</link>
	<description>Technical Communication and Other Writing Topics, by Ben Minson</description>
	<lastBuildDate>Wed, 11 Jan 2012 04:05:49 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Mike Unwalla</title>
		<link>http://www.gryphonmountain.net/2009/01/usability-and-maintainability-instructions-they-can-follow/#comment-223</link>
		<dc:creator>Mike Unwalla</dc:creator>
		<pubDate>Fri, 16 Jan 2009 09:55:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.gryphonmountain.net/?p=273#comment-223</guid>
		<description>Ben, thank you for clarifying.

&quot;When something takes twenty-five or thirty steps to document, maybe the design needs to be looked at to see if it can be simplified somehow.&quot;

Yes, I agree.</description>
		<content:encoded><![CDATA[<p>Ben, thank you for clarifying.</p>
<p>&#8220;When something takes twenty-five or thirty steps to document, maybe the design needs to be looked at to see if it can be simplified somehow.&#8221;</p>
<p>Yes, I agree.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ben</title>
		<link>http://www.gryphonmountain.net/2009/01/usability-and-maintainability-instructions-they-can-follow/#comment-222</link>
		<dc:creator>Ben</dc:creator>
		<pubDate>Fri, 16 Jan 2009 00:20:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.gryphonmountain.net/?p=273#comment-222</guid>
		<description>I suppose what I said came across sounding like hard and fast rules! Even if they were rules, you&#039;ve reminded me that there are always exceptions. Every situation deserves its own consideration for what&#039;s best. So you&#039;re absolutely right: There are situations where it&#039;s not possible to break things up. I even said myself that sometimes I purposely don&#039;t break up a bulky paragraph because it just doesn&#039;t make sense to. However, I think a fourteen-step procedure isn&#039;t too bad.

Let me give an example of what kind of long procedures I&#039;m talking about, though. In one project, we have a feature where the user can create an Excel file of data and then use the spreadsheet as a source for mail merge output in Word. That could have been one extremely long procedure to slog through if I did it as one process. But I broke it up into three tasks:  (1) setting up a document to reuse so that the user wouldn&#039;t have to do it from scratch every time; (2) generating the Excel document in our application; and (3) using the spreadsheet to create the specific output from the reusable document or template. (Fortunately, this process was redesigned and is being developed so that it is much simpler and contained entirely within our application.)

It&#039;s possible that when something takes twenty-five or thirty steps to document, maybe the design needs to be looked at to see if it can be simplified somehow.</description>
		<content:encoded><![CDATA[<p>I suppose what I said came across sounding like hard and fast rules! Even if they were rules, you&#8217;ve reminded me that there are always exceptions. Every situation deserves its own consideration for what&#8217;s best. So you&#8217;re absolutely right: There are situations where it&#8217;s not possible to break things up. I even said myself that sometimes I purposely don&#8217;t break up a bulky paragraph because it just doesn&#8217;t make sense to. However, I think a fourteen-step procedure isn&#8217;t too bad.</p>
<p>Let me give an example of what kind of long procedures I&#8217;m talking about, though. In one project, we have a feature where the user can create an Excel file of data and then use the spreadsheet as a source for mail merge output in Word. That could have been one extremely long procedure to slog through if I did it as one process. But I broke it up into three tasks:  (1) setting up a document to reuse so that the user wouldn&#8217;t have to do it from scratch every time; (2) generating the Excel document in our application; and (3) using the spreadsheet to create the specific output from the reusable document or template. (Fortunately, this process was redesigned and is being developed so that it is much simpler and contained entirely within our application.)</p>
<p>It&#8217;s possible that when something takes twenty-five or thirty steps to document, maybe the design needs to be looked at to see if it can be simplified somehow.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Unwalla</title>
		<link>http://www.gryphonmountain.net/2009/01/usability-and-maintainability-instructions-they-can-follow/#comment-221</link>
		<dc:creator>Mike Unwalla</dc:creator>
		<pubDate>Thu, 15 Jan 2009 09:55:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.gryphonmountain.net/?p=273#comment-221</guid>
		<description>&quot;What do you do when you have a lot of material to regurgitate on the user? Use short paragraphs and more headings. Break long procedures into smaller sets of instructions. I’d rather be led through a process with three main tasks of ten steps each than one long process of thirty steps.&quot;

Sometimes, you cannot divide one long procedure into many smaller procedures. For example, one software product contained an installation wizard that had 14 screens. A user had to do all 14 steps in sequence, or abandon the installation. Each screen needed an explanation. There was no way that I could divide the procedure into smaller procedures.</description>
		<content:encoded><![CDATA[<p>&#8220;What do you do when you have a lot of material to regurgitate on the user? Use short paragraphs and more headings. Break long procedures into smaller sets of instructions. I’d rather be led through a process with three main tasks of ten steps each than one long process of thirty steps.&#8221;</p>
<p>Sometimes, you cannot divide one long procedure into many smaller procedures. For example, one software product contained an installation wizard that had 14 screens. A user had to do all 14 steps in sequence, or abandon the installation. Each screen needed an explanation. There was no way that I could divide the procedure into smaller procedures.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

