For a couple of years now, Ephox has been very successfully using a wiki to provide communication within the company and helping to bridge the gap between our two offices on opposite sides of the pacific. Central to the success of the wiki has been the successful integration and configuration of EditLive! as the editor. It certainly helped that we have a high quality editor with lots of attention to detail but the most important aspect was the amount of attention we paid to correctly configuring the editor.

The first key configuration option was to use HTML as the markup for wiki pages, but preserving the ability to use wiki markup for links. This meant that the full functionality of the editor was available, but the ability to easily link to other pages was preserved. It was still possible of course to use standard HTML hyperlinks and for external links that was quite common. For internal links though, it’s difficult to beat the efficiency of putting square brackets around a phrase to make it a link. When you use a WYSIWYG editor, don’t be afraid to preserve non-WYSIWYG functionality where it makes sense. The aim of the editor is to reduce the learning curve as much as possible without reducing efficiency in the long term.

The next key benefit was using the editor to encourage specific behaviors. We wanted people to add their comments to pages so we added a custom button that inserted a simple comment template with the date and the user’s name – taken from their wiki login. This meant that not only was it easy to comment, inline, on content on the wiki, but it was easy to see the comments and know who they were from.

The other good idea we had was to put a bug report button right there in the editor. The original intent was to capture feedback about our editor so that we could improve it, but it has actually allowed us to identify and relieve user complaints about a range of different things from wiki configuration and other problems to new configuration options to set in the editor as well as quite a few bugs that we managed to get fixed before any of our users saw them. There’s a huge benefit in giving users a highly visible channel for providing feedback. Our biggest problem with the current feedback system is that it often feels like a black hole for users – we don’t have a dedicated sysadmin to make improvements so they can often take a while to come through and often the original request is forgotten by then so they don’t notice when the changes are finally made. If we devoted a little more time to making the feedback system more advanced, it could better tie in with our ticketing system and the user would be informed of progress.

Another really cool feature that we’ve actually had in our editor for many years but goes unnoticed half the time, is the ability to pop the editor out into a separate window. When you want to make larger edits, it can be really useful to be able to maximize the editor window and just focus on what you’re writing. This allows more detailed content to be developed on the wiki instead of being written in Word and then possibly copy and pasted or possibly just forgotten. Another common behavior is to attach documents to the wiki but people are far less likely to download and open the attachment just to browse the content to see if it’s really what they’re after. In the end that information just winds up being ignored. If you can get it to be developed right there in the wiki, it can be edited, commented on and get all the other benefits of content on a wiki.

Finally, we’re beginning to discover that there is a lot of power in having track changes available on a wiki. At this stage we haven’t really worked out how to leverage track changes as well as I can imagine we can. We’ll have to keep an eye on how people are using it and see what ideas we can come up with to leverage the track changes data. Improved diffs seem like a pretty good starting point.