<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
  <title>aC forum: wiki specification (draft)</title>
  <link>http://www.activecollab.com/forums/topic/1113/</link>
  <description>Recent posts on topic: wiki specification (draft)</description>
  <dc:language>en-us</dc:language>
  <pubDate>Wed, 17 Mar 2010 14:43:55 CDT</pubDate>
  
  <item>
    <link>http://www.activecollab.com/forums/post/9337/#post9337</link>
    <guid>http://www.activecollab.com/forums/post/9337/#post9337</guid>
    <title>Post #15 by laurentsj</title>
    <dc:creator>laurentsj</dc:creator>
    <description><![CDATA[<p>I'm not getting much feedback on the wiki, so I'll use the &quot;pages&quot; for project specific wikis, and will create a project named &quot;wiki&quot; for all permanent wiki information.</p>]]></description>
    <pubDate>Sat, 06 Oct 2007 07:53:33 CDT</pubDate>
  </item>
  <item>
    <link>http://www.activecollab.com/forums/post/9329/#post9329</link>
    <guid>http://www.activecollab.com/forums/post/9329/#post9329</guid>
    <title>Post #14 by laurentsj</title>
    <dc:creator>laurentsj</dc:creator>
    <description><![CDATA[<p><div class="postQuote"><blockquote><div class="quoteAuthor">Rolando:</div>As promised I return with my ideas about the way a wiki should be used in aC. For clarification I posted a picture in the aC Flickr group <br />
<br />
(http://www.flickr.com/photos/rolandwoldt/311314873/) so please take a look at it if you think I'm talking nonsense ;-)<br />
<br />
Overall proposal<br />
<br />
- there should be only one wiki per aC installation<br />
<br />
What do you think?</blockquote></div> <br />
<br />
The graph does make sense.<br />
<br />
Now that we've got AC1.0 out, I would place the wiki as one of the top feature request.     <br />
<br />
But i'm not sure it should be restricted to one wiki.<br />
<br />
<br />
Im my situation, i would have two versions:<br />
<br />
A backend wiki for the development team and contractors<br />
A front-end reference wiki / knowledge base / online documentation for clients.   <br />
<br />
Futhermore, i did also request in another thread to have the option to duplicate and move milestones/tasks/papers/discussions inside part of the wiki.<br />
<br />
Another way of looking at it is to simply create one project that we make permanent and name &quot;Wiki&quot;, and allow tasks/milestones/files/papers/discussions to be copied and moved across projects.<br />
<br />
In fact, this would be an ideal feature, killing two birds with one stone.<br />
<br />
<br />
<br />
</p>]]></description>
    <pubDate>Sat, 06 Oct 2007 06:29:30 CDT</pubDate>
  </item>
  <item>
    <link>http://www.activecollab.com/forums/post/7236/#post7236</link>
    <guid>http://www.activecollab.com/forums/post/7236/#post7236</guid>
    <title>Post #13 by ffman</title>
    <dc:creator>ffman</dc:creator>
    <description><![CDATA[<p>I prefer MediaWiki with http://en.wikipedia.org/wiki/WP:WIKED wiked, but that is jsut waht I am used to from wikipedia.<br />
The nice thing about MW is it is easily scalable across multiple servers, and looks professinal. I like wikisyntax, it is pretty easy to use, but WYSIWYG like WikEd would be best IMO. Publishing pages and mass &quot;namespace wide printing&quot; would be awesome.</p>]]></description>
    <pubDate>Tue, 20 Mar 2007 18:27:55 CDT</pubDate>
  </item>
  <item>
    <link>http://www.activecollab.com/forums/post/6990/#post6990</link>
    <guid>http://www.activecollab.com/forums/post/6990/#post6990</guid>
    <title>Post #12 by quux</title>
    <dc:creator>quux</dc:creator>
    <description><![CDATA[<p>I am very happy to see that wiki will be included in aC ... and I'd just like to throw my vote behind a few things (+ for positive vote, - for negative vote):<br />
<br />
+++ on no wikisyntax. wikiwyg or fckeditor or xinha or similar wysiwyg editing, please ohmigod *please* don't force users to learn textile, markdown, or whatever other wikisyntax du jour. <br />
+ for one wiki per project, with permissions determined by the project permissions<br />
+ one person mentioned stikipad. I have not used it, but they have a very nice feature - saves a draft every ten seconds so edits are not lost on browser freeze, timed logout, etc.<br />
+ for 'make a wikibook' or something similar<br />
+ for separate comments space on wiki pages<br />
<br />
- on calling it something other than 'wiki'. That was a geeky term in times past but it is gaining more and more acceptance. Don't worry too much about this; if the editing is easy, people will not be intimidated.<br />
<br />
Good integration of a wiki, and the ability to host my own copy of the system, will make me want to pay for aC!<br />
</p>]]></description>
    <pubDate>Sat, 03 Mar 2007 18:41:54 CST</pubDate>
  </item>
  <item>
    <link>http://www.activecollab.com/forums/post/6608/#post6608</link>
    <guid>http://www.activecollab.com/forums/post/6608/#post6608</guid>
    <title>Post #11 by twiggin</title>
    <dc:creator>twiggin</dc:creator>
    <description><![CDATA[<p>&gt;Are there any other plain English words that define &quot;product of writing&quot; that are understandable to everyone?<br />
<br />
If &quot;Pages&quot; is taken by Apple, what about &quot;Prose?&quot;  &quot;Documents&quot; seems a little too close to the exiting &quot;Files&quot; tab.</p>]]></description>
    <pubDate>Mon, 12 Feb 2007 15:05:05 CST</pubDate>
  </item>
  <item>
    <link>http://www.activecollab.com/forums/post/5753/#post5753</link>
    <guid>http://www.activecollab.com/forums/post/5753/#post5753</guid>
    <title>Post #10 by Rolando</title>
    <dc:creator>Rolando</dc:creator>
    <description><![CDATA[<p>IMHO a &quot;blogging engine&quot; is out of scope for a project management tool - even if wikis are capable of this (like the mentioned DokuWiki with some plug-ins). More traditional ways of communication in an organization might be more effective and less disrupting (for the client organization).<br />
<br />
What is interesting is the question of the project documentation at the end of the project. Not every client will be able or is allowed to install a server just for the documentation purposes - they need another way to access the project documentation. A CD with files and static HTMLs seems to be appropriate. <br />
<br />
There already was this discussion somewhere else in the forum. IMHO this is a v1.x feature.</p>]]></description>
    <pubDate>Fri, 05 Jan 2007 01:22:05 CST</pubDate>
  </item>
  <item>
    <link>http://www.activecollab.com/forums/post/5750/#post5750</link>
    <guid>http://www.activecollab.com/forums/post/5750/#post5750</guid>
    <title>Post #9 by viceroy321</title>
    <dc:creator>viceroy321</dc:creator>
    <description><![CDATA[<p>i would like an option to &quot;publish&quot; some of these &quot;documents&quot; or &quot;pages&quot;, so they may be seen by non-aC users. could also double as a kind of very minimal blog-engine.</p>]]></description>
    <pubDate>Fri, 05 Jan 2007 00:44:20 CST</pubDate>
  </item>
  <item>
    <link>http://www.activecollab.com/forums/post/5702/#post5702</link>
    <guid>http://www.activecollab.com/forums/post/5702/#post5702</guid>
    <title>Post #8 by Rolando</title>
    <dc:creator>Rolando</dc:creator>
    <description><![CDATA[<p>I support Textile or DokuWiki syntax. I recently set up a DokuWiki installation and was positively suprised who logically this wiki is (not only the syntax). It is worth a look.<br />
What I really like is that DokuWiki found a - not perfect but better than in other wiki software - way to solve  the 2 main problems when using a wiki: *where am I?* and *where should I go?*<br />
<br />
I really like the way DokuWiki shows two breadcrumps to show the hierarchical path (in that namespace) and the last 10 visited wiki pages (trace). <br />
On the other problem due to its file storage approach DokuWiki can automatically create a navigation based on the folder structure (ok you need the indexmenu plug-in for this, but the installation is a breeze / http://wiki.splitbrain.org/plugin:indexmenu?s=indexmenu).<br />
<br />
<br />
What is IMHO important for the Wiki is that you are able to structure your content - most of my clients are not very tech savvy and the namespace/category approach is a) not very intuitive and b) not very user friendly implemented in popular wikis (e.g. wikipedia). We need a more user friendly implementation like dedicated fields for tags or for stucturizing possibilities.<br />
<br />
Therefore I vote for a book-like feature. Oh yeah, and only one namespace for the project.<br />
<br />
One more thing - I think the possibility to print out (as PDF) some - hundred - pages from the wiki as project documentation would be a killer feature which will help to convince the (client) users to use the wiki at all. <br />
<br />
My clients in the public sector demand this kind of documentation at the end of a project (they do have a central library where every project documentation will be stored and they need docs and/or pdfs). Today I produce this in an office suite but it would be cool to just tag the relevant wiki pages and produce a good looking book.<br />
This will require 3 features:<br />
- page locking after finalization of the project documentation<br />
- print out only of the page text (including high resolution graphics - 72 dpi graphics look bad in print)<br />
- nice style sheets ;-)<br />
<br />
What do you think?<br />
<br />
PS: I like the &quot;Pages&quot; name, but there is an Apple product with the same name and that can confuse. A more generic name like &quot;documents&quot; or &quot;documentation&quot; will be better.</p>]]></description>
    <pubDate>Tue, 02 Jan 2007 09:33:24 CST</pubDate>
  </item>
  <item>
    <link>http://www.activecollab.com/forums/post/5696/#post5696</link>
    <guid>http://www.activecollab.com/forums/post/5696/#post5696</guid>
    <title>Post #7 by marqpdx</title>
    <dc:creator>marqpdx</dc:creator>
    <description><![CDATA[<p>- pages is a fine name<br />
<br />
- book like hierarchy might be overkill; agreed.<br />
<br />
- versioning is key; make it optional (save space, minor edit etc) but default to on<br />
<br />
- perhaps use textile or dokuwiki markup. already written and rendering engine likely easy to get.<br />
<br />
this'll be huge (can't wait to create cool client landing pages!<br />
<br />
thx,<br />
m<br />
</p>]]></description>
    <pubDate>Mon, 01 Jan 2007 22:29:28 CST</pubDate>
  </item>
  <item>
    <link>http://www.activecollab.com/forums/post/5632/#post5632</link>
    <guid>http://www.activecollab.com/forums/post/5632/#post5632</guid>
    <title>Post #6 by Ilija Studen</title>
    <dc:creator>Ilija Studen</dc:creator>
    <description><![CDATA[<p>Here are some of my notes about wiki section (don't know when it will be added, but I'm thinking about it a lot).<br />
<br />
1. It will not be called Wiki but something like Pages or Documents. Are there any other plain English words that define &quot;product of writing&quot; that are understandable to everyone? IMO, Wiki does not mean much to most people and to other it usually brings bad associations (ugly syntax, geeky stuff etc)<br />
2. Full versioning support.<br />
3. You'll be able to group and tag pages. Create a group &quot;Documentation&quot; for instance and you'll get RSS and ability to reorder stuff in that group...<br />
4. You'll be able to define parent pages so you can structure them in book like fashion if you want. I'm still thinking about leaving this one out because it sounds too much like overkill.<br />
5. Comments + Attachments<br />
6. Search through all revisions.<br />
<br />
There are some other ideas that I'm playing with, mostly related with editing (thing I hate the most about Wikis are ugly syntax and hackish editing process - the whole thing should be way more natural and easier).<br />
<br />
Comments? Additions?</p>]]></description>
    <pubDate>Fri, 29 Dec 2006 05:44:51 CST</pubDate>
  </item>
</channel>
</rss>