<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Boxes and Arrows: Comments by Jason  Grant</title>
    <link>http://www.boxesandarrows.com/person/31151</link>
    <pubDate>Tue, 11 Aug 2009 23:49:29 GMT</pubDate>
    <description>Comments by Jason  Grant</description>
    <item>
      <description>&lt;p&gt;Let&amp;#8217;s outline some downsides now as well, since from this article it looks like a Wiki is a be all and end all solution:&lt;/p&gt;

	&lt;p&gt;1. Wikis are not used widely even by developers &lt;br /&gt;2. Wikis require enormous discipline to keep tidy and consistent looking&lt;br /&gt;3. Wikis can encourage creation of too much data (just like any other social networking tool), and in documentation you want relevant, specific, useful material only &lt;br /&gt;4. Wikis are &lt;span class="caps"&gt;NOT&lt;/span&gt; collaboration tools &amp;#8211; crucial point to outline &lt;br /&gt;5. In practice information on Wikis goes &amp;#8216;out of hand&amp;#8217; and soon people either stop using them or everyone uses the wiki in the way they like, creating a junk resource &lt;br /&gt;6. The fact that the wiki is &amp;#8216;printable&amp;#8217; isn&amp;#8217;t an advantage. More or less everything that is online is printable, but as soon as you print something you have admitted your defeat to the &amp;#8216;collaborative solution&amp;#8217; you have in place, as paper is not collaborative for non-co-located team members &lt;br /&gt;7. Wiki documents are also usually not that easy to re-style up, meaning that what has been committed into a Wiki usually stays looking and feeling that way (and that way usually isn&amp;#8217;t a nice way) &lt;br /&gt;8. Most people do not put in place a proper IA for a Wiki, meaning that the structure &amp;#8216;emerges&amp;#8217; and this &amp;#8216;IA by committee&amp;#8217; process can be somewhat messy and produced poor IA at the end &lt;br /&gt;9. In practice, someone has to be a &amp;#8216;Wiki gardener&amp;#8217; and if you have a team of 5 developers, where one of them is gardening for a big part of his work life, that guy is not going to be happy bunny and it is a waste of resource anyway&lt;/p&gt;

	&lt;p&gt;I could go on &amp;#8230;&lt;/p&gt;

	&lt;p&gt;Thanks&lt;br /&gt;Jason &lt;br /&gt;&lt;a href="http://www.flexewebs.com/semantix" rel="nofollow"&gt;www.flexewebs.com/semantix&lt;/a&gt;&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/using-wikis-to#content_39400</link>
      <guid>http://www.boxesandarrows.com/view/using-wikis-to#content_39400</guid>
      <pubDate>Tue, 11 Aug 2009 23:49:29 GMT</pubDate>
      <author>Jason  Grant</author>
    </item>
    <item>
      <description>&lt;p&gt;I&amp;#8217;m so glad you have written this article! It&amp;#8217;s been one of the most annoying aspects of my work so far and something I have pointed out in every project I have been involved in so far. Using real content is crucial in my opinion as soon as possible and design should not be signed off without the real content in place.&lt;/p&gt;

	&lt;p&gt;The best design agencies I have worked with so far have wanted the content and prototype to be in place and have only then done the visual design later on. And that usually produces a very good quality product at the end.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/the-content#content_40476</link>
      <guid>http://www.boxesandarrows.com/view/the-content#content_40476</guid>
      <pubDate>Fri, 07 Aug 2009 11:35:21 GMT</pubDate>
      <author>Jason  Grant</author>
    </item>
    <item>
      <description>&lt;p&gt;We have two sets of circumstances here by the sounds of it:&lt;/p&gt;

	&lt;p&gt;1. Well established, process driven, Agile, technically savvy teams who care about what they do and stick to a process which they want to improve at all times&lt;/p&gt;

	&lt;p&gt;2. Teams which are more ad-hoc and constantly change, have questionable quality team members are disparate and so on.&lt;/p&gt;

	&lt;p&gt;In case 1, any tool you use for documentation is likely to work nicely. In case 2, anything you try is more than likely to fail.&lt;/p&gt;

	&lt;p&gt;Anyone disagree with this? Wiki or no wiki, it&amp;#8217;s basically just a tool. The real value is in the process and/or approach as well as people.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/using-wikis-to#content_40477</link>
      <guid>http://www.boxesandarrows.com/view/using-wikis-to#content_40477</guid>
      <pubDate>Tue, 11 Aug 2009 23:46:27 GMT</pubDate>
      <author>Jason  Grant</author>
    </item>
  </channel>
</rss>

