<feed xmlns="http://www.w3.org/2005/Atom" xmlns:foaf="http://xmlns.com/foaf/0.1/"><title>norman.walsh.name: Comments on /2007/02/05/painting</title><link rel="alternate" type="text/html" href="http://norman.walsh.name/2007/02/05/painting"/><id>http://norman.walsh.name/2007/02/05/painting/comments.atom</id><updated>2012-02-13T09:23:51.781683Z</updated><entry><title>Comment 1 on /2007/02/05/painting</title><link rel="alternate" type="text/html" href="http://norman.walsh.name/2007/02/05/painting#comment0001"/><id>http://norman.walsh.name/2010/09/25/oauth#comment0001</id><published>2007-02-06T00:06:47Z</published><updated>2007-02-06T00:06:47Z</updated><author><name>Eric</name><foaf:mbox_sha1sum>da39a3ee5e6b4b0d3255bfef95601890afd80709</foaf:mbox_sha1sum></author><content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
    <p>The on problem with topic based writing I have noticed is reuse can often times be more difficult than just rewriting the content. This could partly be because of a lack of well written topics, but I do wonder if writers are better off with tools that facilitate reuse without forcing a writing style. For example, using a topic based library for searching and using snippets, yet creating new content from scratch. There are obvious issues with this as well, but if your library is essentially something like indexed FrameMaker files and you use by-reference includes, it can be a very efficient system that doesn't reduce readability. With that said, it is obviously different for everyone's situation.</p>
  </div></content></entry><entry><title>Comment 2 on /2007/02/05/painting</title><link rel="alternate" type="text/html" href="http://norman.walsh.name/2007/02/05/painting#comment0002"/><id>http://norman.walsh.name/2010/09/25/oauth#comment0002</id><published>2007-02-06T14:45:29Z</published><updated>2007-02-06T14:45:29Z</updated><author><name>Damian Cugley</name><foaf:mbox_sha1sum>da39a3ee5e6b4b0d3255bfef95601890afd80709</foaf:mbox_sha1sum></author><content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
    <p>A better picture for illustrating topic-oriented writing might be one of David Hockney's portraits made from dozens of polaroids.  Each photo is fine in itself, but they inevitably all have slightly skewed perspectives and bits of redundant overlap that makes for an interesting multifaceted portrait that also shows how you can't get the effect of a continuous picture (narrative) by assembling context-free fragments.</p>
  </div></content></entry><entry><title>Comment 3 on /2007/02/05/painting</title><link rel="alternate" type="text/html" href="http://norman.walsh.name/2007/02/05/painting#comment0003"/><id>http://norman.walsh.name/2010/09/25/oauth#comment0003</id><published>2007-02-06T19:40:06Z</published><updated>2007-02-06T19:40:06Z</updated><author><name>Jeff Atwood</name><foaf:mbox_sha1sum>da39a3ee5e6b4b0d3255bfef95601890afd80709</foaf:mbox_sha1sum></author><content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
    <p>"at the end of the day". Ugh.
</p>
    <p>
Sorry, pet peeve of mine.</p>
  </div></content></entry><entry><title>Comment 4 on /2007/02/05/painting</title><link rel="alternate" type="text/html" href="http://norman.walsh.name/2007/02/05/painting#comment0004"/><id>http://norman.walsh.name/2010/09/25/oauth#comment0004</id><published>2007-02-06T19:43:31Z</published><updated>2007-02-06T19:43:31Z</updated><author><name>Norman Walsh</name><foaf:mbox_sha1sum>da39a3ee5e6b4b0d3255bfef95601890afd80709</foaf:mbox_sha1sum></author><content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
    <p>Uhm. Your peeve is what, exactly? You just don't like the phrase?</p>
  </div></content></entry><entry><title>Comment 5 on /2007/02/05/painting</title><link rel="alternate" type="text/html" href="http://norman.walsh.name/2007/02/05/painting#comment0005"/><id>http://norman.walsh.name/2010/09/25/oauth#comment0005</id><published>2007-02-07T14:40:07Z</published><updated>2007-02-07T14:40:07Z</updated><author><name>Sarah O'Keefe</name><foaf:mbox_sha1sum>da39a3ee5e6b4b0d3255bfef95601890afd80709</foaf:mbox_sha1sum></author><content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
    <p>See my blog entry on this at <a rel="nofollow" href="http://www.scriptorium.com/palimpsest/2007/02/authoring-styles-and-art.html">Palimpsest</a></p>
  </div></content></entry><entry><title>Comment 6 on /2007/02/05/painting</title><link rel="alternate" type="text/html" href="http://norman.walsh.name/2007/02/05/painting#comment0006"/><id>http://norman.walsh.name/2010/09/25/oauth#comment0006</id><published>2007-02-14T19:57:01Z</published><updated>2007-02-14T19:57:01Z</updated><author><name>Doug Burgess</name><foaf:mbox_sha1sum>da39a3ee5e6b4b0d3255bfef95601890afd80709</foaf:mbox_sha1sum></author><content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
    <p>Interesting post Norm...</p>

<p>The DITA community seems to be in the same place that the public-sector educational technology community was 6 or 7 years ago, with respect to so-called 'learning objects'.</p> 

<p>The lego-block metaphor of reusability without revision, in all contexts, was very seductive for administrators and funding bodies, who envisioned academics happily pulling learning objects out of repositories and aggregating them into courses, with no rewriting or editing required.</p> 

<p>This was an absurd promise to make, as most academics make liberal use of narrative style in their content, and the results of aggregation were often an incoherent mess.</p>

<p>DITA certainly works well for certain types of tech-writing, and I'm applying it to training materials in my own workplace, but the notions of topic-orientation and reusability have been heavily over-marketed, indeed they've been elevated to the status of dogmas. And this emphasis shifts focus away from some of DITA's other strengths: e.g. rapid specialization of content models, rapid configuration of editing tools, and rapid development of publishing outputs.</p>
  </div></content></entry><entry><title>Comment 7 on /2007/02/05/painting</title><link rel="alternate" type="text/html" href="http://norman.walsh.name/2007/02/05/painting#comment0007"/><id>http://norman.walsh.name/2010/09/25/oauth#comment0007</id><published>2007-04-10T02:12:56Z</published><updated>2007-04-10T02:12:56Z</updated><author><name>denisb</name><foaf:mbox_sha1sum>da39a3ee5e6b4b0d3255bfef95601890afd80709</foaf:mbox_sha1sum></author><content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
    <p>I used DITA at IBM for a while. Not long enough to claim power user status, by any stretch. But enough to get frustrated that I was spending more time managing little pieces of information than writing them. In fairness, I should mention that we were also using a high-end content management system with DITA. Anyway, it was a revelation, because I had drunk the sgml/xml kool-aid about reuse and was enthused to learn about DITA. 
</p>
    <p>
My current opinion is that some amount of reuse is undoubtedly a good thing, but snatching a lot of little snippets out of the ether and assembling them into topics makes more sense for web catalogs and airplane assembly manuals than for readers who are trying to learn or understand complex systems. I like Norm's use of the term "narrative" to describe what can get lost in the shuffle when reuse becomes an end in itself.</p>
  </div></content></entry><entry><title>Comment 8 on /2007/02/05/painting</title><link rel="alternate" type="text/html" href="http://norman.walsh.name/2007/02/05/painting#comment0008"/><id>http://norman.walsh.name/2010/09/25/oauth#comment0008</id><published>2007-06-06T22:35:07Z</published><updated>2007-06-06T22:35:07Z</updated><author><name>JP</name><foaf:mbox_sha1sum>da39a3ee5e6b4b0d3255bfef95601890afd80709</foaf:mbox_sha1sum></author><content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
    <p>Definitions, please. When you say Topics-- Do you mean feature-centric documentation? That's horrible stuff. The real challenge is to figure out what the end-user expects to do with the product...that requires you to have some domain knowledge beyond the product you are documenting.
</p>
    <p>
For example: that printer. People will want to print from their pc, make copies of printed documents, use different paper sizes and types, interrupt or cancel a print run, etc. A good table of contents (navigation) lets the user ignore the background noise created by a linear narrative. However, "topics" that have names like: the paper cartridge, the document feeder, the collater bin, etc. are just as noisy.
</p>
    <p>
I think links that force you to jump around are user-hostile. Just put it all in one logical place with collapsing/expanding subtitles. I think most people would rather scroll than jump when they need help - they don't want to lose their place while they're searching...</p>
  </div></content></entry><entry><title>Comment 9 on /2007/02/05/painting</title><link rel="alternate" type="text/html" href="http://norman.walsh.name/2007/02/05/painting#comment0009"/><id>http://norman.walsh.name/2010/09/25/oauth#comment0009</id><published>2009-10-14T12:51:06Z</published><updated>2009-10-14T12:51:06Z</updated><author><name>Marton Kadar</name><foaf:mbox_sha1sum>da39a3ee5e6b4b0d3255bfef95601890afd80709</foaf:mbox_sha1sum></author><content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
    <p>Your example of dividing the canvas into squares is not very realistic, which of course helps you prove some point better.
</p>
    <p>
I would change the story like this:
</p>
    <p>
The aim is to have a "live" painting of our town on a pub wall.
We have the pub owner, a painter himself, and some of his painter friends.
</p>
    <p>
The owner is good at composition, one friend is obsessed with the sky, another has painted a lot of houses and streetscapes, the third likes trees and hills.
</p>
    <p>
So the owner draws some outlines on the canvas:
Here we will have houses and a church. To the right there will be a hillside with some woods. Up there the sky with the moon and stars.
The canvas might then even be cut in pieces, not squares, but along the lines of the composition. Zippers are attached to the cut edges. The friends get to work and fill out their pieces.
</p>
    <p>
Then they gather again for a beer (or more) and try to fit the pieces together.
They all see where they need to do some refinements, as they are all painters, but the owner, both becasue he is the owner after all and because he is best at
composition, gets to accept and zip back together the pieces.
</p>
    <p>
In the winter the woods shed the leaves and go greyish brown instead of the summer green. So it is time to unzip the part with the hillside and change the coloring. Then it is zipped back to where it belongs.
</p>
    <p>
A few years later the church gets struck and burnt to ashes by lightning. So it is time to unzip the part with the houses and paint the houses behind the church to where the church itself used to stand. Then it is zipped back to bere it belongs.
But wait! says the owner, the church tower covered part of the hillside, so now we have a hole there... so need to adjust another piece as well to keep them fitting together.
</p>
    <p>
End of the story? well no, the story keeps going on and on forever, at least until the pub owner dies.
</p>
    <p>
So I would say it is possible to create good topic oriented writing, if you have a good editor and good writers, who all take their time to also read the chapters of others and have the full picture in mind while working on their own chapters.</p>
  </div></content></entry></feed>

