Internal wikis provide a centralized repository for data that is designed to be freely available to all who have access. They are valuable sources of information that can cover anything from onboarding procedures of new employees to client historical data to standard operating procedures for handling network security penetrations. Any information that you can think of that would be valuable to your employees should have a place within your company wiki. Do you have a new application that you would like to introduce to your staff or a certain way that you believe an existing application should be used? Documentation within your wiki will be invaluable for study. What about an overview of current employee biographies? Perhaps listing their areas of expertise and contact information? In the wiki it goes.
Wikis are valuable assets but only if people actually use them. If they are confusing, disorganized, or there are barriers to access, they are much less likely to be utilized and all of the effort going in to deploying and maintaining your wiki will have been in vain. Let’s take a look at the qualities your wiki should have to ensure people will actually access them and what you should consider before deployment.
Simplicity
In order for the information you have gathered to be easily accessible, the presentation of your wiki should be as uncluttered as possible. A wiki is not a platform to show off your webdev skills. Do not involve unnecessary elements such as banners, flashy javascript, or distracting animations. Think 1995, not 2025. It should load quickly, images should be kept to a minimum except for illustrative purposes, and navigation should be intuitive.
Accessibility
Accessibility in this context has two meanings. The first is making sure the wiki itself is easily findable on your network. If your company has an employee home page, make sure the wiki is linked. If you have info signage for employees throughout the building, include a note about the wiki there as well. Internal company directories, HR emails, employee handbooks, all great options for mentioning your corporate wiki. The URL should be simple and memorable as well. In the second part of this series I will go over creating a DNS entry and local TLD for accessing the wiki.
Accessibility in the second sense refers to readability, understanding your audience in regards to technical knowledge, and accessibility of information for those with impairments. Corporate teams are made up of people from all walks of life, and it is important that there are no barriers to entry when it comes to being able to do their job to the best of their abilities. A few guidelines to help with ensuring accessibility include the following:
Stay away from small type and hard to read fonts. Your color scheme should be high contrast as well, black type on a white background is best. No one wants to scour through pages of tiny gray type on a black background, especially those who may have visual impairments.
Use alt-text to describe images and if videos are included, make sure to provide captions as well as audio descriptions if there is no descriptive audio available within the video. The ADA provides guidelines to make websites accessible to those with impairments or disabilities which you can find here.
When describing high level concepts, stay away from technical jargon and confusing acronyms. If using acronyms, make sure to write them out when first using them and place the acronym next to the full term, eg. Domain Name System, hitherto referred to as DNS. Keep in mind the audience that will be reading the information in your wiki and their level of technical expertise. New hires may not be aware of commonly used terms that are specific to your corporate vocabulary. If there does happen to be a term that will be used often but is not commonly known, now is the time to make a wiki entry for it!
Organization
Understanding how your wiki will be organized from the beginning will reduce headaches related to maintaining your information base down the line. It is advisable to create a rough outline of how you would like your information to be presented to your audience before actually building your documentation. Examples include grouping your data by department, subject matter, index based, etc. Will you have an overall FAQ? What type of structure will you employ (hierarchical, categorical, chronological)? Remember that simplicity and accessibility are paramount when considering your layout if you wish for your wiki to actually be read.
Now that you have some guidelines as to how to prepare your documentation, the next step is deployment. In part two of this series we will discuss setting up the infrastructure, installing and securing our wiki, access control, and creating a local URL via DNS and web server configuration using best practices.
Leave a Reply