Introduction
Nick Card, I.T. Manager at Combined Transport, shared his experience with implementing an in-house wiki; specifically:
- His thoughts about why you’d want to do that.
- Why he thinks it’s a good idea.
- How you’d sell it to your team so they actually use it.
- Some of the process that he did; the nuts and bolts of what he did; the pros & cons of various wiki software options; what he selected and why.
Wiki Basics
Anyone who is unfamiliar with the basics of a wiki can check out Wikipedia. One of the inventors of the original wiki described a wiki as follows: wiki promotes meaningful associations, making it easy to link to other pages, and the link immediately informs you as to whether the content exists or not. Wiki is not carefully-crafted; it’s not only for experts and it’s not for a casual visitor. Instead, wiki is meant to elicit the participation of visitors in the ongoing process of collaboration.
Talking about wikis from that perspective provides three ways that tie into business problems you may be trying to solve—and why a wiki is a good solution.
Problem #1: Information Sharing
A big business problem is: lack of information sharing; people tend to silo stuff that they know and then retain that information as sort of department-private, or a black box to others outside that department. That siloing of information also means you can’t collaborate on other, bigger problems that span multiple departments or divisions within the company by sharing information or procedures or policies.
Problem #2: The Bus Factor
Then there’s the Bus Factor: If you are hit by a bus, what happens to your company knowledge? When you think about information sharing in that way, it’s easy to think that it’s the management that has all the answers about the process; however, it’s really the line people who live it every day and have refined the processes and made changes—and capturing that information means you have to have a tool that’s easy for them to use to store that information. That tool is not reserved for experts or a visitor; all people are part of the collaborative process.
Problem #3: Cross-Department Connectivity
The Bus Factor is huge, so anybody must be able to create content; it’s got to be easy to add new pages and expand the structure of the wiki because you’ve got to take that knowledge and put it in the wiki. How do you span the silos, connecting them and expanding the wiki? When you think about it that way, it makes too much sense; you must have one.
Single Repository
There are some downsides. But the really big thing that Nick wanted to accomplish at Combined Transport, was being able to have a single repository for all their business knowledge, no matter what the user’s position in the company, no matter who they worked for … if they wanted to understand more about the company, the bigger picture, how their work impacts others, they’d have one source to access. They could both contribute their knowledge and gain knowledge. Overall, a wiki makes an organization stronger.
He had all these lofty goals, he did all this work, put his heart and soul into their wiki—they named their wiki Blue because their trucks are blue—and then nobody did anything with it… So heartbreaking.
The Big Problem
If there’s no information in your wiki, nobody’s going to use it. Nick tried two tactics. First: How to be sexy. Nick’s Tip: find a piece of information about the company that is not necessarily easily-accessible and figure out a way to display that information in a manner that’s cool and shows off the features. For example, he thought the big sexy thing for their company was their Truck Map. They take the location of all of their trucks all across the country, put the information on one map, and then users can go to the map page and, boom!, you see all of the company’s trucks on a map.
Q: Is that interactive?
Nick: Oh, yeah.
He found a map plug-in for the wiki and users can go in and, for each truck, they can click on it and the information box will display which division it’s in, who the driver is, whether it’s refrigerated or not. Very cool, but not super-practical. There are some use cases where it would be helpful; for example, in the case of a breakdown, they could see what else is in the area. But, as a salesperson or a dispatcher, he’d want to see where all the trucks that they’re brokering are located right now; that’s cool. But not everybody bought-into this idea. Nick realized that the app needs to provide utility. They’ve got to find the one piece of information they’re seeking and usually, it’s a dynamic piece of information that people need access to but it’s not necessarily the easiest information to get to and/or share.
Dashboards
There are two things they did: First, they took their email reports and turned them into dashboards. Instead of receiving Excel spreadsheets that the staff received once or twice a day, they’d present a dashboard that displayed all the information in an HTML table that was updated every five minutes. Now, you can go to this page and immediately see this content as it’s changing; how many drivers are coming in, how many trucks they have sitting, the current status of their equipment.
Second, another thing that was useful—and this is what started getting people to understand that they could create their own content—was after-hours information for their shippers. So they have a 24/7 call center that provides information for their drivers, and also provides support for their drivers.
One of the things that the dispatchers have is access to their customer base. Oh! Something goes wrong and you’re going to be late … In the refrigerated world, there’s a ton of stuff that can go wrong, and you’re delivering in the wee hours of the morning. If something goes wrong in the middle of the night, who do I call? That information is siloed in the Dispatcher Space and the people who need the information are the people who manage the Driver Services Department. The wiki provided a really easy way for them to provide contact and other [instructional] information about a new customer—and that page can be as large or as small as necessary, depending on the details. For example, a customer like Safeway where there’s tons of locations and tons of procedures; there’s a nuance in all of that which can be captured in a wiki because a wiki doesn’t force a structure on anybody.
That started the company on the wiki process; that’s how they started selling their coworkers on the wiki process—to get them to start using the wiki. Today, their Driver Services Department has gone from using a 4” binder full of paper and handouts and procedures to 100% digitized information stored in their wiki; it’s searchable, interlinked, and it’s accessible to not only the people who have a binder but to everyone in the company. The Driver Services Department is the only department completely invested in the wiki. In fact, their use of the wiki has moved it from “cute” to mission-critical software. They can’t operate without having that information available to everyone.
Do-Over…
Nick shared that, if he were to start over on this wiki project, he’d make some changes.
Branding
A couple of other barriers that he realized—having a logo and some sort of a cute name like Blue–is critical. The inspiration was actually IBM [Big Blue]; they called their wiki BluePedia. IBM was one of the first pioneers of a wiki CMS system. It was actually built via MediaWiki, which is the software that powers Wikipedia today. IBM actually spun-out their entire wiki team and now it’s called Blue Source and it details all of the activity IBM did to make wiki work for them. Now he hears people ask, “How do I do that?” and the answer is, “Hey, it’s on Blue; check out Blue!” That kind of enthusiasm makes Blue a part of their company’s everyday life.
Strategies
Those are Nick’s strategies. He doesn’t claim to be an expert. He’s had success with some departments and failures with other departments in his company. One key thing to understand is: follow-through with a topic; have all the information about a topic in one place so you’re not forcing people to go to multiple places to find everything they need to know about one topic.
Wiki Packages
Nick cited four software packages worthy of the [development] time investment:
- MediaWiki
- Tiki Wiki
- Confluence
- Doku Wiki
MediaWiki
MediaWiki is everywhere. All of Wikipedia and the Wikimedia Foundation use it and Wikia which is the largest wiki farm uses MediaWiki, as does Blue Source. Far and away, about 75% of all wiki traffic uses MediaWiki. So, it’s huge!
MediaWiki is really well-developed, very well-tested has a huge user base, has tons of plug-ins and extensions, if you have problems and want to modify the source code, it’s all very accessible and easy, but it is a much higher barrier to entry because it was designed first and foremost to run the Wikimedia Foundation’s material. So there are IT Experts who are deploying it and there’s no quick-and-easy installer for MediaWiki. You’re downloading and extracting files … if you’re setting it up on a Linux Server, you’re setting up a SQL PHP instance. There are a few turnkey ISO downloads. There’s a ton of variability in configurations, adding more nuances to the setup.
Also: It’s explicitly not a CMS. A CMS is a Content Management System. When you think about a CMS, the classic example is, “I have access to this stuff, you have access to that stuff; I control my stuff, you control your stuff, but I can give you access to my stuff or you can give me access to your stuff.” So we have a bunch of content to manage. MediaWiki, in the sense of it not being a CMS, is because the WikiMedia Foundation’s philosophy is: Everything is open to everyone. So there is no “my information and your information.” It’s all collective. Which brings up an interesting problem, which is: the technology vs. policy problem.
Some people shouldn’t be changing some things. For example, if we have our policy—our explicit standard operating procedure—on our wiki, you shouldn’t get to change that. Only managers should be changing that standard policy. Well, with MediaWiki, there are certain plug-ins that let you lock-down some things but everybody can change everything. Now, the default response in the IT World is that we need to have permissions and controls and lock that down. Nick made the point that we can also have a policy that declares that only managers can change certain items. And MediaWiki is really good about tracking who changed what, so there’s an accountability piece there. I would caution about solving policy problems with technology when a simple policy will do. There’s a huge advantage from solving policy problems with policy: you can easily change your policy whereas, with technology, sometimes it’s harder to change the underlying technology than it is to say, well, now you can change that stuff.
Q: Do you have backup/restore capability with this stuff? If I, as a manager, go in and make a change and others decide they don’t want that change, it can be restored from a backup?
Nick: The standard part of the wiki software, and MediaWiki as well, is a full history of all the changes that have occurred. Huge advantage of wiki is it’s knowable, everybody’s familiar with it, it’s comfortable to use … but because it’s there for the Wikimedia Foundation, a lot of add-ons have been developed to perform activities that MediaWiki users want.
Tiki Wiki
A good opposite of MediaWiki, in many ways, is Tiki Wiki. Tiki Wiki is the largest actual CMS that is deployed today, as far as we know. And Tiki Wiki is explicitly a CMS. Tiki Wiki has support for plug-ins but their thing is about everything is built-in. Everything gets upgraded regularly. You don’t have to worry about your business falling apart because certain plug-ins got upgraded—or didn’t get upgraded—or you’re trying to upgrade the underlying plug-ins to keep up. Tiki Wiki is all about you bring everything into one spot and now you have one piece of software you deploy and you can keep it updated, and that is all of your wiki stuff.
In Nick’s opinion, the downside to Tiki Wiki is it tries to be too many things to too many people, so it doesn’t necessarily do all of those things well. When he first set up Blue, he used Tiki Wiki because he was really enamored with the CMS and he was really focused on having technology solutions to those problems. He wanted to be able to control who got what or who could see what or who could search what, and all of those aspects. It is also business-friendly, in the sense that it has five-year-long releases. If you’re looking for an easy-to-deploy wiki, you’ve got a lot of weird different cases and you’re a relatively small organization, Tiki Wiki is probably the one he’d steer you towards.
Confluence
Another wiki software product, which is pretty-well known, is Confluence. Confluence is the only closed-source software in this group of four. And, it’s expensive! But it’s a heck of a platform. Confluence is probably used by the majority of Fortune 500 companies that are open about their CMS stuff. The support is there; it’s part-and-parcel of the whole package. They have a lot of stuff that makes it really easy to do cloud deployment. You’re not having to fight with … for example, if you wanted to do a MediaWiki Cloud deployment, you’d have to manage the stuff on your own. Confluence has their own special Confluence Cloud that makes it very easy for users to get access, especially from a multi-siloed location that has users all over the world and you need Internet access controlled as well. Confluence does all that very well. But it’s expensive; that’s the trade-off.
Confluence describes their product as a CMS with a wiki underneath it. But a lot of people are moving away from those wiki features and trying to be more like a SharePoint competitor; less document-rich and more sort of content-edited stuff. Atlassian is the company that makes Confluence. They also make Jira. It’s all written in Java, so if you like Java, it’s great; if you don’t like Java, it’s not great.
Doku Wiki
The last one in the group of four is Doku Wiki. If you have ever done much with a university and they’ve had a wiki, or you’ve known someone who has their own personal wiki, odds are it’s Doku Wiki. Doku Wiki is super-simple. You don’t need a database; it’s a very simple flat file storage. It’s got a decent amount of plug-ins and stuff [functions] built-in, but it’s not trying to be everything to everyone. And, if all you want to do is get some information out there and do some of that basic wiki linking stuff, Doku Wiki is great for that. As soon as you want to integrate with your active directory, you have to start doing database integration, and having thousands of users, Doku Wiki is incapable of keeping up with that. But as a small user-base product, it’s fantastic. It’s very easy to set up and produces a usable product very quickly.
Conversions
Q: You mentioned that you transitioned from one wiki to another; how was that process? Very problematic?
Nick: Because we had so little content, I basically simply started over. I recreated a few pages manually.
Q: Generally, if you have wiki content produced from one wiki product and want to transition to another, is that a big deal?
Nick: Yes. The irony, too, is that if you use MediaWiki, it’s the easiest to transition away from because it’s so popular. Most people have written markup parsers to convert the MediaWiki from whatever their version of markup is. To go the other way, though, MediaWiki has no interest in trying to get other people to convert, so they’re relying on third parties. So those folks have to write their own markup parser to get their data back in a relatively clean way. In that case, I got lucky because we really didn’t have anything. We started over completely.
Initial Wiki Setup
The last thing Nick talked about was how he set up their MediaWiki instance, some things he learned along the way, and some things he’d want to do differently if he did it again today.
He ended up selecting MediaWiki primarily for the plug-ins. There are two things: 1) the usability; it’s familiar, it’s friendly, and 2) it’s got so much plug-in support; there are so many different things you can do with it. Semantic MediaWiki is a package that allows you not just to link pages together but actually build data into pages. For example, with Semantic MediaWiki, instead of saying, “the Eiffel Tower is 300 feet tall,” you can actually embed that meaningful information into the page. With that feature, you can now run queries on your wiki and say, “show me buildings and how tall they are” and you’re not relying on parsing an Info Box that might display the height of a building; the information is actually embedded as part of the wiki entry. To Nick, that was a no-brainer, for the expandability and what they could do with that.
If you follow the instructions for setting up MediaWiki, it will have you go through basic LAMP setup on Linux. You install MySQL, PHP, and then you discover that you’re running CentOS, and MediaWiki requires cutting-edge versions of everything. So then, you have to go find some third-party repository you can download. So there’s that downside to MediaWiki. It’s expecting all those cutting edge versions of companion software. Once you get all the right software installed and have the prerequisites, you then download the tar file and extract it to your Web root, and then you’re good-to-go. You have a wiki! You run through the setup, you get the local settings, the PHP file (which is all the settings that control your wiki and creates all the databases), and now you’re good-to-go. Now it’s time to update your wiki; that’s where the default kind of sucks.
Employing Git
There’s a better way to manage and control source code, and that’s the way Nick’s current wiki is managed. All of the wiki—the extensions (the plug-ins), the themes, the wiki engine itself—all of those are available via Git. So, the right way to do that kind of setup is: you make it all as a Git Clone, so now you just set up some file out there that tells you which branch you’re pulling. Example: He’s doing his long-term support release, which is on 1.32 right now, and then the script just iterates through all the directory tree and updates all of the Git stuff and then announces that the new version is ready. He then update all his files; super-easy! He doesn’t have to think about downloading, extracting, overwriting the wrong files, and overwriting the file he changed; much nicer! And most of the extensions are available via that same process; as extension updates. And then, a few of the extensions that are official MediaWiki ones, like Visual Editor (a WYSIWYG editor), that is also revision proper. So you can’t use the wrong version of Visual Editor with MediaWiki or it won’t work. So if you use everything via Git, everything is coordinated.
A Better Way…
But Nick thinks there’s a better way to do it. And he thinks that better way is Docker. He said that he has not done a lot with Docker and Docker Instances but from what he’s read, that is the way to go; especially from the perspective of ease of data reliability. Because right now, he’s limited at the virtual machine level; he has to have his entire MediaWiki Virtual Machine somewhere else if it goes down. Being able to do it from Docker Containers from centralized storage, to him, seems to be the right way to do it. But he feels he needs to learn more about containerization before he would want to give-in to that.
Gunnar: I can tell you, right up-front, it’s dang easy. It’s: Docker Pull MediaWiki | Docker Run MediaWiki and you’re done … except if you have plug-ins.
Nick: Yeah, we do. That’s what we rely on.
Gunnar: What you’ll have to do is define your own Docker file that pulls all of the plug-ins into the image, and build your own Docker Image.
Nick: Idea for future Tech Talk: Containerization.
Karen: Got it! Thank you!
Gunner: And, a Docker file is pretty simple; it’s just a script that pulls in … go to this URL … go to that URL … take this action … continue.
Nick: So that’s my Tech Talk on Wiki.
Q&A
Q: Is there any level of authentication with MediaWiki, or is it wide-open?
Nick: It isn’t wide-open. So, we run a little wiki farm of multiple versions of MediaWiki so we run the same code base and then it’s just different versions of the local settings in the .PHP file, depending on where the virtual address that it’s coming through on Apache. Our general wiki thing is: if you can get into [an entry], you can see and edit that entry.
We have two sites right now that we are connecting with the dark fiber and, if that gets cut, which we’ve had happen before, then what happens is, now, I think we have our fallover working, so it will fall over to the VPN over the Internet so then everything should still be fine. But in my perfect world, what I’d really love to have happen is if these two sites completely lost communication, services like Blue would still be maintained across both sites. If they lost communication and suddenly go into read-only mode, at least we have that information across both sites and, as a user, all I’d be doing is going to the same URL and it automagically does all the right routing and stuff. And that’s where I’m struggling because I wonder how I route this across two separate sub-nets depending on … because I could add the DNS entries but then it’s not going to pull the DNS entries and poll … it will cycle through the DNS entries and pick one so it needs a load balancer. I’m wonder if I’m over-complicating this because, when I start searching these terms, they end up scaling massively. So I’m wondering, how does Wikipedia scale?
Q: Does anyone else have experience with this type of thing?
Dave: I do. I’ve been a wiki fan for so long that I can’t function without one. So rather than keep installing and building, and reconstituting a wiki on my laptop every time I change laptops, I’ve started using VooDooPad which is a Mac app that’s very wiki-like. It’s not any of the common flavors of wiki.
Q: Is there any way to access the Mac data on a non-Mac system?
Dave: Possibly. I think you can export data. I think you can also run a light server. But I doubt there’s any kind of authentication.
G: But there’s not a Windows version?
Dave: I don’t think Jesse writes anything that’s not Mac, although he did have an iOS version of it but I think he may have stopped maintaining that. Like Nick, I’m a big fan of wikis and I’ve run into so many places where certain groups of people will “get it” right away; they’ll invest the time—they’ll make the time—to simplify their lives down the road. Other times, you’ll have people who simply reject it out of hand; don’t have time for it, going to keep it to themselves. Maybe it’s a [perceived] job security thing. Some people are really just hard to nudge.
Nick: I actually pulled the page reports from the last week and we had a spike in the usage of our wiki. We have a new manager in our Driver Services Division, and I think he’s very enthusiastic about our wiki. And his team is full of a bunch of old-timers; they’ve been with the company forever and are very set in their ways. So the fact that he’s getting them to start creating and adding—or even just looking—at wiki entries is great news!
Jon: I think there are two advantages: 1) They already had the book; if you don’t have the book, then you’re creating stuff from scratch and that’s a lot harder. For them, it was simply translating the book into the wiki. 2) They took one person and declared them the department liaison; the person to ask whenever they have questions, before they must escalate a level up. So, they had a lot of internal support to build their wiki.
Nick: That’s right! There’s almost no basic problem they can’t solve within the department. It makes it easy and comfortable to try the wiki, or to lean over the cubicle and ask a fellow worker how to do something.
Q: Does your company have any kind of after-hours training?
Jon: We’ve had a few of those types of training sessions, at lunch.
Mercedes talked about how their wiki is very useful. They had no training on how to use it. Younger workers are very enthusiastic about it, but others do not naturally gravitate to it.
Q: Do you think this is a requirement for companies these days?
Nick: Will companies have to have some kind of digital information repository? Yes. If you don’t have one, you’re kidding yourself. Else, you have a bunch of Word documents and some hand-written notes spread all over, stickies on monitors. You can’t search. You can’t back it up. Nobody else can access it. Having a digital information repository is critical to being able to grow, to pass on knowledge. We talk about the Bus Factor a lot, with our key personnel. Our Shop Manager made up a thick binder a few years ago. Hey! Don’t update the binder; update Blue! Updating the wiki doesn’t come naturally to people. Now Nick is looking into how to digitize her hand-written notes.
Q: What about training?
Nick: I’ve never offered that. I’ve had some informal sessions, though. I’ve found that it’s most effective when we have something specific to enter into the wiki and can demonstrate the process. I’m not always the best person to train them, though. Because I have to make some assumptions about base knowledge because I’m not the best person to connect with them at their level.
Q: What if you presented this under the guise of Disaster Recovery?
Nick: It’s a particular kind of Disaster Recovery (as opposed to getting hit by a bus). If somebody leaves the company [for example, someone who’s been with the company for 30 years]…she knows it all…unless it has to do with computers. She was dragged into the information age. She is getting close to retirement. What happens to use when she moves on? How do we get her invested in a tool set that’s going to allow her to pass on her knowledge? Another issue is: a lot of what she does should be automated; it’s very manual (like re-typing information from one spreadsheet into another spreadsheet).
Q: And, another issue is: Did we design these tools to make it difficult for non-computer people to have a hard time?
Jon: Our scanners do not allow you to automatically email from the scanner because she’s on Office 365, and it broke the link between our Fujitsu Scanner and the email. You can still scan to the hard drive and then you have to do the attachment on email; that’s a difficult step.
Glen: In terms of the wiki training, the whole wiki idea sounds like something that’s basic. A video file with screen capture and screen motion, and having someone walk through the basics of using a wiki with a few examples (check for this, check for that) might work. That way, anybody could take a look at the video. That might be an effective advertisement for using the wiki and get people comfortable with the basics of using a wiki.
Nick: I like that idea. And, since I control the Marketing Guy, I can make that happen.
Q: Is there a conflict between the trainee’s aptitudes and skill set vs. the trainer’s aptitudes and skill set?
Nick: Our Licensing Guy retired recently and a new girl (from one of our dispatch positions) came in and now does all our licensing. The difference is night-and-day. The old guy didn’t even do hunt-and-peck. The new girl does what he did in half the time, or less. And now, she’s thinking about how she can improve the process, to do more and to save money. The problem with him was his inefficiency at using technology. We want to gain efficiency by improving our people.
Jon: I really like the video idea to get people started…watch the video and then get started in training. The advantage I find most often is: if I stop and put the solution into the wiki, it would be there for the next time I need to know how to solve the problem.
Nick: I have a problem with consistency; documenting what I have done in a manner that makes it easy to repeat the procedure. I don’t take the time while I’m figuring out what to do to properly-document the procedure so it’s repeatable. E.g., OK vs. Submit on a button.
Nick: So, maybe there’s another Tech Talk idea for you: Training.
[discussion]
Q: Are you happy with the search quality?
Nick: Yes. I made some minor changes, though.
Cross-Training: Stop thinking about it as Areas of Responsibility and start thinking about it as Ownership.
Karen: Some incentive for training is: you can’t move on until you train somebody else to do your job.
Nick: Do that all the time.
Gunnar: Plenty of examples of people who have lots of free time and don’t use it at all.
[Cross training discussion.]
[Silo Problem: wiki is a good solution for that issue.]
[How do you own down the tree?]
Karen: Do you ever use temp help?
Nick: Nope. But would like to use free interns…
Check out Carbonite as a cloud storage solution.
Jon: How much software can you afford to buy and pay ongoing support for? Monthly.
Formerly, we’d buy a new computer and get upgraded software. NOW, we have to upgrade often. Even if you backup to the cloud, you still need the expert to restore everything. Their priority is not necessarily inline with our priority.
Click here to download a copy of Nick’s Notes.
Join us next month for a Tech Talk on Upgrading Windows.
Author: Karen
Written: 3/7/19
Published: 3/30/19
Copyright © 2019, FPP, LLC. All rights reserved.