For a long, long, long, long, long time Crucial has operated a custom made web based internal knowledge base / documentation area which has fallen well out of date. Though web based and coded in PHP we have since out grown its simplicity.
Our team regularly felt the pain of trying to locate, update or add information.
Finally we hit a point where we had to take action, so we put the word out to our team to come up with some possible third party options to replace our internal kb area.
We received replies with a number of suitable options.
At this point we realized that we really needed to sit down and come up with our requirements. We could then use the requirements to help compare the solutions and make a final decision.
The team bumped heads and came up with a relativity straight forward list of features and requirements.
Our replacement wiki needed,
- Excellent search functionality.
- Permissions at a per page basis.
- Easy to use layout.
- To be easy to find information in.
- Search uploaded documents (nice to have)
- Ability to upload files such as PDF, Images, Zips.
- Ability to move pages, articles around and change names.
- Ability set descriptive titles / names.
-
WSIWYG editor for creating pages / documents.
- Version Control for a document / page.
- Able to structure information and modify layout of system.
- Local install (not a hosted solution)
Some of those options were quite basic, but essential to how we wanted to run our wiki.
We then went through the process of comparing all the viable Wiki solutions against our list of requirements.
- Tiki Wiki
TikiWiki ticked a lot of the boxes that made up our criteria. Good search, permissions, upload files, version control, and the expected WSIWYG editor. However what turned us off this solution was the look and feel.We strongly believe the wiki should be easy on the eyes, and the layout should be a breeze to work with. Many of our testers did not find it met those needs.
- KBPublisher
KB Publisher was another great option. It met most of our needs, with a great search function, positive comments about how easy it was to use and all the usual features you would expect from a wiki solution.
- BrainKeeper
Straight away we ruled this out because brain keeper was not able to be locally installed, you had to use it hosted on their infrastructure. While this is not necessarily a bad thing depending on your budget, we prefer to keep our wiki locally run.We still went through the testing process however, and found this solution to be very feature rich. One disappointing note was it had a page version control, but you couldn’t revert to a previous version, just see the changes.
- MindTouch
MindTouch was an interesting offering. From a feature set perspective it had a large list of features, a good portion we had no use for. We considered this a disadvantage as it meant there was a lot of bloat or unnecessary functionality.We came to the decision that this was not a suitable option as the layout was not user friendly which we believe was as a result of the large list of features.
We then got on with testing Atlassian Confluence. Immediately the feedback from our testers was very positive. Great layout, easy to use, ticked all our feature requirements and a search function that was exactly what we were after!
Confluence had all the bits we needed plus more! A recurring comment was on the WSIWYG editor used when creating pages / documents, the editor in Confluence is amazing. With drag and drop ability for adding images and documents, as well as easy to use shortcuts.
Further to our decision Confluence has an excellent documentation area for users and admins alike. Along with that Atlassian offer an interactive and video based training area called Atlassian University.
Personally I have worked with Confluence in previous roles, and already had made my mind up, but to avoid to much bias we still let the team vote and give feedback.
Confluence was chosen as our new wiki replacement!
6 months later…..
We’ve been running Confluence now for about 6 months. We are on the end part of a migration to migrate all our old articles from our legacy system and could not be happier! We took our time moving the articles across because we wanted to verify each article and make sure it was worth moving!
Since going live with Confluence we have started using it quite heavily for our project documentation, internal tech support documentation and a large number of our team members are making great use of the persona spaces for their own notes, documents and general shenanigans.
At the time of deployment we went live with Confluence 4.1 and it was great, since then Confluence has now gone to Confluence 4.3 which has added a couple of features worth noting, including a WSIWYG editor for the Global Templates area.
We are looking forward to Confluence 5 and some of the new UI changes they are bringing in!
If you have any questions about why we moved to Confluence, or wondering about our experience in using Confluence so far, please feel free to leave a comment.
Disclaimer: The company I work for is partners with several vendors
Disclosure: My company does not have a business relationship with this vendor other than being a customer.
Our company extensively uses confluence for creating groups of all kinds. At times it can be difficult to find information due to too many meaning-less groups that have been created by users and the abuse of too much useless information being posted. I would recommend user guidelines for posting information and administration for removing groups that are not being used and to monitor whats being posted. Also, the search function still is not very good.