<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.1" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Authoring &#038; IA</title>
	<link>http://maadmob.net/donna/blog/2002/authoring-ia</link>
	<description>Information architecture, interaction design and much more</description>
	<pubDate>Sat, 11 Oct 2008 02:37:04 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.1</generator>
		<item>
		<title>By: David Locke</title>
		<link>http://maadmob.net/donna/blog/2002/authoring-ia#comment-103</link>
		<dc:creator>David Locke</dc:creator>
		<pubDate>Wed, 19 Nov 2003 05:57:09 +0000</pubDate>
		<guid>http://maadmob.net/donna/blog/2002/authoring-ia#comment-103</guid>
		<description>Structured, non-linear text is an alien form for almost everyone. I got in trouble by writing it years ago when the expectation was linear. What constitutes good structured writing is seen by writers as poor writing.

Then, there are the issues around the treatment platform. Marcom writers write to treatment platforms. Technical writers do, but they don't realize that technical writing is a treatment platform.

In realizing a treatment platform, design a form that will capture the text in the correct amount. Give the text field a name that is descriptive of the content. Each text field should have its own CSS as well. As an example:

Name of Use (as V+ing):
Motivation for use (Single Sentence):
Preconditions for use (In paragraph form):
Introduce task (Sentence..., do the following:)
Steps (preceed each with &lt;li&gt;):

Then, put a field adjacent to the data entry fields for meta-data entry.

Writing and indexing are different skills and different jobs. Some writers have indexed others have not. Having a list of the controlled vocabulary terms helps here, as would a preconfigured collection of index terms with heirarchy and see alsos shown. Then, the technical writer would only have to select the appropiate index terms from the existing index entries. So open a browser that navigates to the appropriate index term.

Have an indexer, editor, or IA reveiw the results. Then, print out a report and redline the indexing errors, so the writer learns the system. &lt;/li&gt;
</description>
		<content:encoded><![CDATA[<p>Structured, non-linear text is an alien form for almost everyone. I got in trouble by writing it years ago when the expectation was linear. What constitutes good structured writing is seen by writers as poor writing.</p>
<p>Then, there are the issues around the treatment platform. Marcom writers write to treatment platforms. Technical writers do, but they don&#8217;t realize that technical writing is a treatment platform.</p>
<p>In realizing a treatment platform, design a form that will capture the text in the correct amount. Give the text field a name that is descriptive of the content. Each text field should have its own CSS as well. As an example:</p>
<p>Name of Use (as V+ing):<br />
Motivation for use (Single Sentence):<br />
Preconditions for use (In paragraph form):<br />
Introduce task (Sentence&#8230;, do the following:)<br />
Steps (preceed each with
<li>):</p>
<p>Then, put a field adjacent to the data entry fields for meta-data entry.</p>
<p>Writing and indexing are different skills and different jobs. Some writers have indexed others have not. Having a list of the controlled vocabulary terms helps here, as would a preconfigured collection of index terms with heirarchy and see alsos shown. Then, the technical writer would only have to select the appropiate index terms from the existing index entries. So open a browser that navigates to the appropriate index term.</p>
<p>Have an indexer, editor, or IA reveiw the results. Then, print out a report and redline the indexing errors, so the writer learns the system. </li>
]]></content:encoded>
	</item>
	<item>
		<title>By: DonnaM</title>
		<link>http://maadmob.net/donna/blog/2002/authoring-ia#comment-102</link>
		<dc:creator>DonnaM</dc:creator>
		<pubDate>Wed, 18 Dec 2002 21:38:23 +0000</pubDate>
		<guid>http://maadmob.net/donna/blog/2002/authoring-ia#comment-102</guid>
		<description>This is how we will do it as well - experts to do the indexing and crosslinking.
</description>
		<content:encoded><![CDATA[<p>This is how we will do it as well - experts to do the indexing and crosslinking.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: PeterV</title>
		<link>http://maadmob.net/donna/blog/2002/authoring-ia#comment-101</link>
		<dc:creator>PeterV</dc:creator>
		<pubDate>Wed, 18 Dec 2002 18:01:56 +0000</pubDate>
		<guid>http://maadmob.net/donna/blog/2002/authoring-ia#comment-101</guid>
		<description>One way of dealing with this is to let authors do non-ambigous metadata tagging (date, ...), and have a separate person do the additional tagging (maybe even after publication). Because I agree, authors can usually not be expected to do advanced metadata categorization.

In the world of books, most authors don't do the index because it is known that authors generally aren't good indexers.
</description>
		<content:encoded><![CDATA[<p>One way of dealing with this is to let authors do non-ambigous metadata tagging (date, &#8230;), and have a separate person do the additional tagging (maybe even after publication). Because I agree, authors can usually not be expected to do advanced metadata categorization.</p>
<p>In the world of books, most authors don&#8217;t do the index because it is known that authors generally aren&#8217;t good indexers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Keith</title>
		<link>http://maadmob.net/donna/blog/2002/authoring-ia#comment-100</link>
		<dc:creator>Keith</dc:creator>
		<pubDate>Thu, 12 Dec 2002 18:59:39 +0000</pubDate>
		<guid>http://maadmob.net/donna/blog/2002/authoring-ia#comment-100</guid>
		<description>I think you touched upon a very sticky issue that those of us who have to work in the real world come across quite often.  I know I've had the exact same problem you describe on multiple occasions.

I work for a hospital, so you can see how the IA for our intranet as well as our external site is a very challenging prospect.

One of the things we've come up with to handle this very problem is the idea of having a related item or similar item menu attached to many of the content pages.  We then go with our best guess of where something fits in the IA and cross-link to it.  For example for directions to a clinic, does that information live with the other clinic info, or under "directions"???  No clear cut answer there.

The trick in that is, like you said, the maintenance of that related items menu.  We can assign metadata to help with this (one of the things I've been looking into is XFML) but then who decides what get assigned to what content.  For now, I'm not sure that piece of it can be placed into the hands of the content author.  So then the Web team is forced to touch these pages and determine this data and cross linking.  Defeating part of the purpose of distributed authorship.  A sticky, sticky problem.

That problem, and the poor authoring interface of our CMS James is talking about above - are a couple of the deciding factors in going mostly static and kicking our CMS to the curb for our external site.  Distributed authorship just didn't make sense in the long run there.

In lots of cases I think there needs to be a human interface (IA, Web editor, producer, what have you) when dealing with these sites that offer up such complex information, diverse audiences and all of that.  I mean, the bottom line (IMHO) is the site should be usable by the reader/user and I don't think lots of times the people who own the content are not skilled enough to make the correct decisions.  They need help, someone to marry the content with the IA and the design AND the users goals - no CMS will solve some of those issues, and frankly I'm not sure if they should.

Anyway - I could go on and on.  In essence I agree with you and I think these types of questions need to be thought about.
</description>
		<content:encoded><![CDATA[<p>I think you touched upon a very sticky issue that those of us who have to work in the real world come across quite often.  I know I&#8217;ve had the exact same problem you describe on multiple occasions.</p>
<p>I work for a hospital, so you can see how the IA for our intranet as well as our external site is a very challenging prospect.</p>
<p>One of the things we&#8217;ve come up with to handle this very problem is the idea of having a related item or similar item menu attached to many of the content pages.  We then go with our best guess of where something fits in the IA and cross-link to it.  For example for directions to a clinic, does that information live with the other clinic info, or under &#8220;directions&#8221;???  No clear cut answer there.</p>
<p>The trick in that is, like you said, the maintenance of that related items menu.  We can assign metadata to help with this (one of the things I&#8217;ve been looking into is XFML) but then who decides what get assigned to what content.  For now, I&#8217;m not sure that piece of it can be placed into the hands of the content author.  So then the Web team is forced to touch these pages and determine this data and cross linking.  Defeating part of the purpose of distributed authorship.  A sticky, sticky problem.</p>
<p>That problem, and the poor authoring interface of our CMS James is talking about above - are a couple of the deciding factors in going mostly static and kicking our CMS to the curb for our external site.  Distributed authorship just didn&#8217;t make sense in the long run there.</p>
<p>In lots of cases I think there needs to be a human interface (IA, Web editor, producer, what have you) when dealing with these sites that offer up such complex information, diverse audiences and all of that.  I mean, the bottom line (IMHO) is the site should be usable by the reader/user and I don&#8217;t think lots of times the people who own the content are not skilled enough to make the correct decisions.  They need help, someone to marry the content with the IA and the design AND the users goals - no CMS will solve some of those issues, and frankly I&#8217;m not sure if they should.</p>
<p>Anyway - I could go on and on.  In essence I agree with you and I think these types of questions need to be thought about.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Robertson</title>
		<link>http://maadmob.net/donna/blog/2002/authoring-ia#comment-99</link>
		<dc:creator>James Robertson</dc:creator>
		<pubDate>Thu, 12 Dec 2002 04:19:26 +0000</pubDate>
		<guid>http://maadmob.net/donna/blog/2002/authoring-ia#comment-99</guid>
		<description>I agree absolutely.

The authoring side of a content management system is what I am really passionate about, having written systems that specialise in dealing with this aspect.

One lesson I have learnt (the hard way) is that the "cognitive load" on the authors is really significant. For example, in one project, the authors were all professional techwriters, a skilled bunch.

There was a requirement for "content reuse", so I provided a range of features. The interface was very easy to use, but still, there were great problems.

These stemmed back to the difficulty the authors had in visualising how the end product was going to appear, and how all the information fitted together.

When I deployed the software into another site, I took a lot of these features out...

What frustrates me, though, is that most commercial CMSs have a really poor authoring interface, which is just not suited to the sort of requirements you have listed. I think it can be done, but no-one is trying...

James
</description>
		<content:encoded><![CDATA[<p>I agree absolutely.</p>
<p>The authoring side of a content management system is what I am really passionate about, having written systems that specialise in dealing with this aspect.</p>
<p>One lesson I have learnt (the hard way) is that the &#8220;cognitive load&#8221; on the authors is really significant. For example, in one project, the authors were all professional techwriters, a skilled bunch.</p>
<p>There was a requirement for &#8220;content reuse&#8221;, so I provided a range of features. The interface was very easy to use, but still, there were great problems.</p>
<p>These stemmed back to the difficulty the authors had in visualising how the end product was going to appear, and how all the information fitted together.</p>
<p>When I deployed the software into another site, I took a lot of these features out&#8230;</p>
<p>What frustrates me, though, is that most commercial CMSs have a really poor authoring interface, which is just not suited to the sort of requirements you have listed. I think it can be done, but no-one is trying&#8230;</p>
<p>James</p>
]]></content:encoded>
	</item>
</channel>
</rss>
