<?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: Vista Help Emphasizes Concepts in Effort to Create Power Users</title>
	<atom:link href="http://idratherbewriting.com/2007/06/04/vista-help-emphasizes-concepts-in-hopes-of-creating-power-users/feed/" rel="self" type="application/rss+xml" />
	<link>http://idratherbewriting.com/2007/06/04/vista-help-emphasizes-concepts-in-hopes-of-creating-power-users/</link>
	<description>The Latest Trends in Technical Communication</description>
	<lastBuildDate>Tue, 14 Feb 2012 08:22:46 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Tom</title>
		<link>http://idratherbewriting.com/2007/06/04/vista-help-emphasizes-concepts-in-hopes-of-creating-power-users/comment-page-1/#comment-34004</link>
		<dc:creator>Tom</dc:creator>
		<pubDate>Wed, 06 Jun 2007 01:24:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.idratherbewriting.com/2007/06/04/vista-help-emphasizes-concepts-in-hopes-of-creating-power-users/#comment-34004</guid>
		<description>roGER,

Thanks for the thoughts. I agree with what you say about talking to sales and marketing people. They&#039;re always looking for the right angle to pitch the products. 

Re the bit about simple tasks being essential, yes I also agree. There is a need for both in the help. 

I guess this leads to part of the problem of documentation. Beginners need novice help; power users need advanced help. You throw it all in the same file and it suddenly mushrooms into a giant file or document. Then the same users click the help and say eek, I can&#039;t find anything. 

How do you tend to manage the organization of beginner and advanced information?</description>
		<content:encoded><![CDATA[<p>roGER,</p>
<p>Thanks for the thoughts. I agree with what you say about talking to sales and marketing people. They&#8217;re always looking for the right angle to pitch the products. </p>
<p>Re the bit about simple tasks being essential, yes I also agree. There is a need for both in the help. </p>
<p>I guess this leads to part of the problem of documentation. Beginners need novice help; power users need advanced help. You throw it all in the same file and it suddenly mushrooms into a giant file or document. Then the same users click the help and say eek, I can&#8217;t find anything. </p>
<p>How do you tend to manage the organization of beginner and advanced information?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: roGER</title>
		<link>http://idratherbewriting.com/2007/06/04/vista-help-emphasizes-concepts-in-hopes-of-creating-power-users/comment-page-1/#comment-33926</link>
		<dc:creator>roGER</dc:creator>
		<pubDate>Tue, 05 Jun 2007 22:23:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.idratherbewriting.com/2007/06/04/vista-help-emphasizes-concepts-in-hopes-of-creating-power-users/#comment-33926</guid>
		<description>You make some good points on task description help vs a more overview orientated type of help that answers questions like &quot;Why and when should I do tasks X, Y, and Z?&quot;

Yes, it is often amusing that engineers in particular often have little or no knowledge about what the purpose of the product actually is. A moment&#039;s thought reveals they don&#039;t actually need to know this information, since their job consists of making sure a particular report populates correctly, or a particular field accesses a specific cell in a database.

I&#039;ve found that the best people to ask for this product-purpose kind of information are the sales and marketing departments. 

They are always much closer to the clients, and often were involved in the very early stages of the product concept. Many products are a result of a client asking for something, or research that indicates clients are dissatisfied with something or would like something that answers a specific need.

In theory (and practice) the project manager and product manager know this kind of information too, but on large projects they are often too busy and stressed to be able to give you detailed information, especially for follow up questions and issues that arise on a day to day basis.

It&#039;s also true that companies are often surprised at what clients do once they&#039;ve bought a product and explored its capabilities. 

Sadly there isn&#039;t much we can do to anticipate this, except recommend a review of the documentation say... six to 12 months after a product has reached the market.

You also mention that &quot;Describing simple tasks gets pretty dull.&quot;

Welcome to the major down side of the job!

Perhaps it&#039;s important to remember that describing simple tasks is dull but essential. Especially for the majority of users to whom the product is just a tool that should help them do their jobs, and crucially, not get in the way!</description>
		<content:encoded><![CDATA[<p>You make some good points on task description help vs a more overview orientated type of help that answers questions like &#8220;Why and when should I do tasks X, Y, and Z?&#8221;</p>
<p>Yes, it is often amusing that engineers in particular often have little or no knowledge about what the purpose of the product actually is. A moment&#8217;s thought reveals they don&#8217;t actually need to know this information, since their job consists of making sure a particular report populates correctly, or a particular field accesses a specific cell in a database.</p>
<p>I&#8217;ve found that the best people to ask for this product-purpose kind of information are the sales and marketing departments. </p>
<p>They are always much closer to the clients, and often were involved in the very early stages of the product concept. Many products are a result of a client asking for something, or research that indicates clients are dissatisfied with something or would like something that answers a specific need.</p>
<p>In theory (and practice) the project manager and product manager know this kind of information too, but on large projects they are often too busy and stressed to be able to give you detailed information, especially for follow up questions and issues that arise on a day to day basis.</p>
<p>It&#8217;s also true that companies are often surprised at what clients do once they&#8217;ve bought a product and explored its capabilities. </p>
<p>Sadly there isn&#8217;t much we can do to anticipate this, except recommend a review of the documentation say&#8230; six to 12 months after a product has reached the market.</p>
<p>You also mention that &#8220;Describing simple tasks gets pretty dull.&#8221;</p>
<p>Welcome to the major down side of the job!</p>
<p>Perhaps it&#8217;s important to remember that describing simple tasks is dull but essential. Especially for the majority of users to whom the product is just a tool that should help them do their jobs, and crucially, not get in the way!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

