<?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: Quick Reference Guides: Short and Sweet Documentation</title>
	<atom:link href="http://www.idratherbewriting.com/2009/04/10/quick-reference-guides-short-and-sweet-documentation/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.idratherbewriting.com/2009/04/10/quick-reference-guides-short-and-sweet-documentation/</link>
	<description>Technical Communication Blog / Technical Writing Blog</description>
	<lastBuildDate>Tue, 16 Mar 2010 04:56:16 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: The Proximity Effect &#124; Simplifying Complexity</title>
		<link>http://www.idratherbewriting.com/2009/04/10/quick-reference-guides-short-and-sweet-documentation/comment-page-1/#comment-140129</link>
		<dc:creator>The Proximity Effect &#124; Simplifying Complexity</dc:creator>
		<pubDate>Mon, 18 May 2009 22:06:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.idratherbewriting.com/?p=3331#comment-140129</guid>
		<description>[...] Fellow writer Tom Johnson has written several excellent posts on the value of quick reference guides as a concise job aid. He has also given great advice on best practices for developing them. If you need to create quick reference guides, I highly recommend Tom&#8217;s recent post, titled Quick Reference Guides: Short and Sweet Documentation. [...]</description>
		<content:encoded><![CDATA[<p>[...] Fellow writer Tom Johnson has written several excellent posts on the value of quick reference guides as a concise job aid. He has also given great advice on best practices for developing them. If you need to create quick reference guides, I highly recommend Tom&#8217;s recent post, titled Quick Reference Guides: Short and Sweet Documentation. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: &#160; The Twitter Book and tech comm&#160;by&#160;Communications from DMN</title>
		<link>http://www.idratherbewriting.com/2009/04/10/quick-reference-guides-short-and-sweet-documentation/comment-page-1/#comment-140054</link>
		<dc:creator>&#160; The Twitter Book and tech comm&#160;by&#160;Communications from DMN</dc:creator>
		<pubDate>Thu, 14 May 2009 09:06:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.idratherbewriting.com/?p=3331#comment-140054</guid>
		<description>[...] not all documentation. This approach is great for quick reference guides or visual references for a set of features of an [...]</description>
		<content:encoded><![CDATA[<p>[...] not all documentation. This approach is great for quick reference guides or visual references for a set of features of an [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ownrisk's me2DAY</title>
		<link>http://www.idratherbewriting.com/2009/04/10/quick-reference-guides-short-and-sweet-documentation/comment-page-1/#comment-139830</link>
		<dc:creator>ownrisk's me2DAY</dc:creator>
		<pubDate>Wed, 29 Apr 2009 08:50:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.idratherbewriting.com/?p=3331#comment-139830</guid>
		<description>&lt;strong&gt;ownrisk의 생각...&lt;/strong&gt;

Quick Reference Guides: Short and Sweet Documentation  - Tom Johnson...</description>
		<content:encoded><![CDATA[<p><strong>ownrisk의 생각&#8230;</strong></p>
<p>Quick Reference Guides: Short and Sweet Documentation  &#8211; Tom Johnson&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tom</title>
		<link>http://www.idratherbewriting.com/2009/04/10/quick-reference-guides-short-and-sweet-documentation/comment-page-1/#comment-139580</link>
		<dc:creator>Tom</dc:creator>
		<pubDate>Mon, 20 Apr 2009 02:47:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.idratherbewriting.com/?p=3331#comment-139580</guid>
		<description>Evod, thanks for the compliment on this post. I appreciate your feedback.</description>
		<content:encoded><![CDATA[<p>Evod, thanks for the compliment on this post. I appreciate your feedback.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Friday Links &#171; Bridging the Gap</title>
		<link>http://www.idratherbewriting.com/2009/04/10/quick-reference-guides-short-and-sweet-documentation/comment-page-1/#comment-139519</link>
		<dc:creator>Friday Links &#171; Bridging the Gap</dc:creator>
		<pubDate>Fri, 17 Apr 2009 06:33:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.idratherbewriting.com/?p=3331#comment-139519</guid>
		<description>[...] I&#8217;d Rather Be Writing has a fantastic write-up of their presentation on Quick Reference Guides. [...]</description>
		<content:encoded><![CDATA[<p>[...] I&#8217;d Rather Be Writing has a fantastic write-up of their presentation on Quick Reference Guides. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Evod Prokov</title>
		<link>http://www.idratherbewriting.com/2009/04/10/quick-reference-guides-short-and-sweet-documentation/comment-page-1/#comment-139402</link>
		<dc:creator>Evod Prokov</dc:creator>
		<pubDate>Tue, 14 Apr 2009 23:04:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.idratherbewriting.com/?p=3331#comment-139402</guid>
		<description>I&#039;ve been writing guides/tutorials for quite some time now, and I think this is the best &quot;Guide to write Guides&quot; I&#039;ve seen.

 THANX!!!</description>
		<content:encoded><![CDATA[<p>I&#8217;ve been writing guides/tutorials for quite some time now, and I think this is the best &#8220;Guide to write Guides&#8221; I&#8217;ve seen.</p>
<p> THANX!!!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul Gallagher</title>
		<link>http://www.idratherbewriting.com/2009/04/10/quick-reference-guides-short-and-sweet-documentation/comment-page-1/#comment-139368</link>
		<dc:creator>Paul Gallagher</dc:creator>
		<pubDate>Tue, 14 Apr 2009 00:07:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.idratherbewriting.com/?p=3331#comment-139368</guid>
		<description>Great article Tom, Ben. A good reminder to always stop and think about packaging and delivery in the quest for getting your message across.

Another use I have found for the &quot;reference guide&quot; format is in sales, specifically large &quot;technical solution sales&quot;.

Tender documents, proposals and associated clarifications can add up to a sizable stack of paper. A severe case of the &quot;almighty thud&quot; syndrome, worse still for the poor client faced with many vendors. 

I&#039;ve used the reference guide technique a few times to try to cut through the noise, and each has been a phenomenal success. I&#039;ve produced a laminated reference card to be distributed and used at the formal presentation stage. 

The best example was for a multi-million deal to build market monitoring systems for a regulator. Our reference card in that case was double-sided A4, and we devoted half the space to just describing the problem and the domain. After winning the deal, I heard informally that our graphical representation of the market model and all its complexities had totally won them over. The client had even been using the chart internally as a reference to guide their own discussions.

I use the technique sparingly, since they can take a lot of work to produce and simply get your story down to that 1 or 2 pages in a way that is still meaningful and substantive. And not every situation is appropriate: I think best where the problem domain or the solutions are unavoidably complex, and you know the complexity is muddying the water for all involved.

But when you do it right, it can be a very powerful tool.</description>
		<content:encoded><![CDATA[<p>Great article Tom, Ben. A good reminder to always stop and think about packaging and delivery in the quest for getting your message across.</p>
<p>Another use I have found for the &#8220;reference guide&#8221; format is in sales, specifically large &#8220;technical solution sales&#8221;.</p>
<p>Tender documents, proposals and associated clarifications can add up to a sizable stack of paper. A severe case of the &#8220;almighty thud&#8221; syndrome, worse still for the poor client faced with many vendors. </p>
<p>I&#8217;ve used the reference guide technique a few times to try to cut through the noise, and each has been a phenomenal success. I&#8217;ve produced a laminated reference card to be distributed and used at the formal presentation stage. </p>
<p>The best example was for a multi-million deal to build market monitoring systems for a regulator. Our reference card in that case was double-sided A4, and we devoted half the space to just describing the problem and the domain. After winning the deal, I heard informally that our graphical representation of the market model and all its complexities had totally won them over. The client had even been using the chart internally as a reference to guide their own discussions.</p>
<p>I use the technique sparingly, since they can take a lot of work to produce and simply get your story down to that 1 or 2 pages in a way that is still meaningful and substantive. And not every situation is appropriate: I think best where the problem domain or the solutions are unavoidably complex, and you know the complexity is muddying the water for all involved.</p>
<p>But when you do it right, it can be a very powerful tool.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Skibell</title>
		<link>http://www.idratherbewriting.com/2009/04/10/quick-reference-guides-short-and-sweet-documentation/comment-page-1/#comment-139347</link>
		<dc:creator>Scott Skibell</dc:creator>
		<pubDate>Mon, 13 Apr 2009 10:26:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.idratherbewriting.com/?p=3331#comment-139347</guid>
		<description>Color is also an important consideration. 

For example, think of USA Today. We all know what the blue, green, purple, and red colors represent. This becomes important as you create a series of job aids for a particular project.

Another great example is over at http://quamut.com/ They&#039;ve got great layouts and use color to represent different categories. I encourage you to print out a couple of their free examples. 

Another great post, Tom. Thanks.</description>
		<content:encoded><![CDATA[<p>Color is also an important consideration. </p>
<p>For example, think of USA Today. We all know what the blue, green, purple, and red colors represent. This becomes important as you create a series of job aids for a particular project.</p>
<p>Another great example is over at <a href="http://quamut.com/" rel="nofollow">http://quamut.com/</a> They&#8217;ve got great layouts and use color to represent different categories. I encourage you to print out a couple of their free examples. </p>
<p>Another great post, Tom. Thanks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul Sholar</title>
		<link>http://www.idratherbewriting.com/2009/04/10/quick-reference-guides-short-and-sweet-documentation/comment-page-1/#comment-139343</link>
		<dc:creator>Paul Sholar</dc:creator>
		<pubDate>Mon, 13 Apr 2009 02:28:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.idratherbewriting.com/?p=3331#comment-139343</guid>
		<description>Some additional considerations:

* Analyze the organization (information design) of the topics you want to present as one-pagers. Notice whether the topics&#039; pieces can be presented effectively using the same layout. 

* Use text attributes, shading, and color as features to visually tag the different kinds of information on the page, to give the reader visual hints about what is being presented in each panel. If you must create variant layouts for some topics, re-use those features across varying layouts.

* If there will be more than one such one-pager, decide whether they will refer to each other and how, and how each refers to the main body of the product&#039;s documentation.

* A design-intensive one-pager can be a challenge to read online if the reader&#039;s screen is not properly sized. Layouts that emphasize left-right visual relationships might fare better than above-below visual relationships. The latter is a usability issue for many web pages, where the reader must constantly scroll up/down to make sense of what is being presented.</description>
		<content:encoded><![CDATA[<p>Some additional considerations:</p>
<p>* Analyze the organization (information design) of the topics you want to present as one-pagers. Notice whether the topics&#8217; pieces can be presented effectively using the same layout. </p>
<p>* Use text attributes, shading, and color as features to visually tag the different kinds of information on the page, to give the reader visual hints about what is being presented in each panel. If you must create variant layouts for some topics, re-use those features across varying layouts.</p>
<p>* If there will be more than one such one-pager, decide whether they will refer to each other and how, and how each refers to the main body of the product&#8217;s documentation.</p>
<p>* A design-intensive one-pager can be a challenge to read online if the reader&#8217;s screen is not properly sized. Layouts that emphasize left-right visual relationships might fare better than above-below visual relationships. The latter is a usability issue for many web pages, where the reader must constantly scroll up/down to make sense of what is being presented.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
