wiki specification (draft)

1, 2
avatar Rolando Dec 1. 2006. 1:55 pm #1
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

(http://www.flickr.com/photos/rolandwoldt/311314873/) so please take a look at it if you think I'm talking nonsense ;-)

Overall proposal

- there should be only one wiki per aC installation
- the owner company should see every wiki page
- a client or supplier company should only see the project wiki pages in which they are involved


Imagine now you are using the wiki as glossary and you are using one expression/abbreviation with two ore more meanings which means the wiki doesn't create a new wiki page for this expression

(version a: per project wiki)

- the wiki pages will get an automatic project name addition in the wiki page name
- when searching for that expression a supplier or owner company member will see two pages for that expression
- if a client likes to use the same content in another project he has to creat an new page in the second project - duplication of content :-(


(version b: overall wiki but non-editable sections on a wiki page)

- no duplication of content
- when trying to create a page for an existing expression that page should open, but the other project's content should not be editable. There should be an additional text area for the new explanation (for every project)
- a project area must be markable as private and thus only be seen by project related companies if there is sensitive data
- text areas which come from projects with no client/supplier company involvement must be hidden by default - this can result in duplicate exlanation areas for companies with access to both projects



Version B seems to be tougher to implement (or be impossible?), but would add more convenience for the user. An additional plus can be to see how the other project defines the same expression which could help your project.


In any case the wiki should be on the same feature hierarchy like the tasks / messages / milestones (as a tab). The implementation as a second application - like the 37s implementation of writeboards in basecamp - destroys the feeling of "one application - one project".

What do you think?
avatar Dec 1. 2006. 2:02 pm #2
Those are some good ideas Rolando -- I think version A is more practical, but version B would probably be more flexible in the long run.

I guess it depends how much work Ilija is prepared to put into a wiki area for aC - version A would be fairly easy to develop and integrate I'd imagine.
avatar Ilija Studen Staff Dec 1. 2006. 11:54 pm #3
Lets start from here: I like how wiki is integrated into Trac. Every long text field is basically a Wiki entry that can be marked up as a wiki page, link to other pages and so on. It makes things whole lot easier because its consistent - you know what to expect from every textarea in the system.

In my opinion, Wiki should be per project because it makes things whole lot easier (permissions, search etc) and because its easier to understand - you don't need to explain to people what pages are global, what are private, what are project related etc... Just follow conventions from the rest of the system and keep things consistent (if you know what a private message is you'll know what a private wiki page is).

And here is one thing that I think would make the difference - there is no wiki tab or separate wiki section. Block occupied with project description on project overview page should be used as entry point. Only additional page in the system would be index of wiki pages and we still need to see where to put it. Reason why I think it will be good is because Wikis are too geeky for regular users, but if you hide the fact that user is using a wiki things are more natural and easier to grasp. No new term, strange markup, stuff like that. If done right it will make all the difference, if not it will be worthless. That is why I take wiki issue pretty serious and would not like to rush it at all.
Follow @activecollab and activeCollab on Facebook.
avatar Dec 2. 2006. 2:21 am #4
I agree with you both about the practicability and consistency therefore I vote for a "per project" too (my first post was a discussion item to show the difficulties). Let's make it as easy as possible.

@Ilija: I agree about the goal of making it not too geeky (!) and beeing consitent in what you can expect as user.

What also must be clear is that you can put the complete poject documentation in aC (= the wiki). One of the main questions in my projects is "in which document can I find xyz" - this means the file section is great for formal deliverables and the versioning of that content but not so efficient in creating the content (assuming we are talking about text of course). A network and easy collaboration approach would be very helpful.
The end result can be put in a document and formatted acoording to the CI standards. Then you can post this version in the files section.

Therefore a "Documentation" section would be a good idea IMHO (to avoid the "wiki" term). The first page should be Ilija's proposed index page.

Ilija Studen:
If done right it will make all the difference, if not it will be worthless. That is why I take wiki issue pretty serious and would not like to rush it at all.

Cheers
Roland

PS: We implemented a wiki in our company (consulting with a strong SAP implementation focus) and it failed. The main reasons are not technical - that's dead easy to implement - but the "hen and egg" problem (why should I share my knowledge and what can I get from the wiki?) and the markup / edit mode.

One nice solution is the socialtext implementation (www.socialtext.com, there is a nice screencast at http://ross.typepad.com/blog/2006/09/socialtext_20.html), but they use a wysiwyg editor.
I also like their picture on the front page - it explains the purpose very clear. Maybe we can adopt and enhance this for aC?
avatar Dec 23. 2006. 1:53 pm #5
I just discovered StikiPad and they made a (hosted) wiki which acts in a nearly perfect way - in my taste. Not to geeky and very good looking which will lower the entrance barrier for new authors.

Please take a look at their screencast at: http://www.stikipad.com/theatre/

I know it is written in Ruby but all the interesting parts - except the wiki engine part - is in aC today!
avatar Ilija Studen Staff Dec 29. 2006. 5:44 am #6
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).

1. It will not be called Wiki but something like Pages or Documents. Are there any other plain English words that define "product of writing" 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)
2. Full versioning support.
3. You'll be able to group and tag pages. Create a group "Documentation" for instance and you'll get RSS and ability to reorder stuff in that group...
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.
5. Comments + Attachments
6. Search through all revisions.

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).

Comments? Additions?
Follow @activecollab and activeCollab on Facebook.
avatar Jan 1. 2007. 10:29 pm #7
- pages is a fine name

- book like hierarchy might be overkill; agreed.

- versioning is key; make it optional (save space, minor edit etc) but default to on

- perhaps use textile or dokuwiki markup. already written and rendering engine likely easy to get.

this'll be huge (can't wait to create cool client landing pages!

thx,
m
avatar Jan 2. 2007. 9:33 am #8
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.
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?*

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).
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).


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.

Therefore I vote for a book-like feature. Oh yeah, and only one namespace for the project.

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.

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.
This will require 3 features:
- page locking after finalization of the project documentation
- print out only of the page text (including high resolution graphics - 72 dpi graphics look bad in print)
- nice style sheets ;-)

What do you think?

PS: I like the "Pages" name, but there is an Apple product with the same name and that can confuse. A more generic name like "documents" or "documentation" will be better.
avatar viceroy321 Jan 5. 2007. 12:44 am #9
i would like an option to "publish" some of these "documents" or "pages", so they may be seen by non-aC users. could also double as a kind of very minimal blog-engine.
avatar Jan 5. 2007. 1:22 am #10
IMHO a "blogging engine" 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).

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.

There already was this discussion somewhere else in the forum. IMHO this is a v1.x feature.
or Go To Next Page
Requested user profile does not exist