The most voted request on our feedback service is “Integrate a wiki in the dashboards”:
I think that what actually users mean is “integrate Wiki functionalities in Teamwork”, but this is one of the requests that can be interpreted in several different ways: it probably implies a feature set, and some of such features make sense for the Teamwork context, and some may not.
Some example features:
- Let any user have a portlet on her home page that is actually the home of a company Wiki
- Let people edit any Teamwork page layout of in a Wiki way
- Have for any object a history of changes on that object
- Use Wiki syntax for any content
- Pages are created by just creating links to them
A different, more radical interpretation could be “change completely the management philosophy and let there be no user rights and pages and contents be just contributed by users”. In fact there are even applications for issue management that actually are just a wiki. Well now, I think that it may be useful to try to clarify what is the usefulness of work management software. It must be something that makes you work better; it’s quick to insert the essential work data, and that done, it does a lot of work for you. Inserting work data in a Wiki just doesn’t give any specific support. A Wiki is meant as a tool to manage a documentation body contributed by several people; that is just not what work management is about; and using the wrong software for the just, will just increase confusion in your company, make people frustrated and make them waste more time. Wrong software, sorry.
Implementing a Wiki engine
This does not mean that the Wiki’s logic can’t inspire some really good ideas that can be included in any kind of software. This is the perspective that we’ve taken on the “Wiki integration” subject, and there are many subtle problems involved, like:
- If you want to write contents with links to objects, it would be nice to have a RESTful API in Teamwork in order to write links simply
- Should we use the TinyMCE editing which we started using in some places (and users are pushing for more), or switch to Wiki syntax in contents?
- Up to today documents are typically linked in Teamwork, but contents lives outside (and this is generally a wise choice), but with this extension it should become really nice to write contents in Teamwork for specific projects
Given the deep integration of the Wiki features and Teamwork’s, we are building our own Wiki engine; its persistence is Hibernate based, and there is none available that does that, so this may become of general interest.
One of the considerations that convinced us to write it from scratch is that several Wiki applications functionalities are already available in Teamwork, often more refined than those built in Wikis. Like full text search, subscriptions and e-mail integrations and recent pages.
If you’d like to suggest some particular feature of the Wiki integration, you can post it on the feedback service (yes, we do check it out).