CHIPS Articles: Wikis, Portals and Bandwidth Considerations in the Fleet

The Navy has long had a requirement for units to share information at great distances to collaborate on mission essential tasks. Whether called wikis, portals or collaboration sites, these tools allow large groups to share information in near real-time. For the sake of simplicity, these types of sites will be referred to as wikis for the remainder of this article. If you have used Navy Knowledge Online (NKO), All Partners Access Network (APAN), the Non-Classified Enclave (NCE), a Microsoft SharePoint portal, Collaboration at Sea (CAS), or Wikipedia, you have used a wiki.

Since the use of these sites is new to the fleet, there are understandably some growing pains. One of the greatest challenges to using current tools is the bandwidth required to support them. While many of these sites are shore-based, it is important to remember that often customers are not. A page that loads instantaneously on a shore network may load slowly on a carrier — and be completely unusable on a frigate. Fortunately, great gains in bandwidth management can be had if we break a little "cultural china" and teach users to properly use the tools as intended. Ensuring a wiki is properly designed will take us the rest of the way.

Wikis, portals and collaboration sites all refer to the same set of tools. While it's true that wikis provide voice and desktop sharing functionality, the largest savings in bandwidth usage and tool usability lie in the format used to share information via text (including documents) and chat. Sharing documents via a wiki requires a fundamental paradigm shift for users.

Wikis allow the content of the document (picture and text) to be placed directly on the page or for a document to be uploaded for users to download. Wikis are not shared/global drives; thus, attaching a Microsoft Word document not only negates the advantages of using a wiki (collaborative editing and search), but also drastically increases the amount of bandwidth required to share the information.

Content Generation

Decreasing the size of content files dramatically reduces required bandwidth; and therefore, drastically increases the amount of service that can be provided by a given bandwidth. Very simple changes can have an enormous effect on data size. For example, the operation order (OPORD) for the Navy’s exercise, PANAMAX 2010, is 5.1 megabytes, but the text content is a mere 53 kilobytes — 100 times smaller!

The OPORD also contained two maps that were reduced in file size to less than 50 kilobytes each by reducing the image resolution and changing file type. Doing the math, even these results are 33 times smaller than the original OPORD!

Cosponsored by U.S. Southern Command and the Panamanian government, the 12-day PANAMAX exercise held in August brought together sea, air and land forces in a joint, combined operation. To understand the scope of planning for PANAMAX, it is important to note that the exercise consisted of participation from 2,000 personnel and 18 nations.

Undercutting Search

In adopting an information sharing solution, there are many options to consider: How will the wiki be used? Do users need to download a Microsoft document or do they simply want to reference the information inside the document?

Have you ever searched in vain for a document following these steps?
• Go to a folder/directory/Web page;
• Click on a document that might be what you are searching for;
• Wait for the document to download;
• Wait for the application to open;
• Wait for the document to be opened by the application;
• Scan the document and determine it is not what you are looking for; and
• Return to step one and repeat until the appropriate document is found!

This process can be maddening! Now consider that every time you click on a link it takes 30 to 60 seconds to see a result (much longer on a frigate). Luckily, most wikis have a search feature; unfortunately, the search feature will search the text content of the wiki, but it will not typically search inside attached Microsoft Office documents.

At this point, if users are attaching Microsoft Office documents, they are not only downloading large documents — much larger than necessary — but also downloading documents that will not be used because users can’t determine if they contain the information they need.

Here is a recent scenario from Operation Unified Response in Haiti to illustrate the point. Non-governmental organization (NGO) doctors at mobile field hospitals had a need to know when medical evacuation helicopters would deliver patients to their facility; their only communication tool was a smart phone. Is it more reasonable to expect them to download and open/view a Microsoft Excel document or view a “lite” version of a Web page to find this information?

Undercutting Version Control and Collaboration

It is rare that a document is written, beginning-to-end, by a single person. Quite often, different people are required to work on different sections of the same document. Additionally, that document is often submitted for approval and editing by the chain-of-command in an organization. Microsoft Office allows changes to be tracked via the “Track Changes” feature. Using this feature, you can see who made changes and why. What Microsoft Office does not allow, however, is for multiple persons to edit the same document at the same time. This invariably leads to multiple copies of the same document spread throughout the network, none of which are completely up-to-date.

Consider the process for updating an OPORD for an exercise. The N3 (operations) needs to update Annex R, while the N6 (communications) needs to update Annex K. In this scenario one of three things will happen:
• Annexes K and R will have to be separate documents that will need to be merged by someone.
• Annexes K and R are contained within the same file and either N3 or N6 will have to wait for the other to finish making updates before starting work.
• N3 and N6 will each make a copy of the OPORD, neither of which will contain updates made by the other, and someone will have to figure out what changes were made and merge the documents.

To date, we’ve tried to mitigate this challenge by either placing “last updated” on the document or using version numbers. Unfortunately, in time-critical operational situations, this is less than ideal. What if the N3 decides to update from version 1 to version 2, while N6 decides to update from version 1 to version 1.1?

What if both of these updates happen on the same date rendering the last modified date useless for tracking purposes? But placing the content of a document on a wiki, allows multiple persons to update content simultaneously and still see incremental changes being made by other personnel in near real-time.

Additionally, many wikis have the capability to track changes much like Microsoft Office, so it’s easy to determine who made changes, where, when and why. This allows real-time version control and ensures that all personnel have access to the most up-to-date document.

Wiki Architecture and Features

Information professionals and system administrators must keep in mind their target audience, expected use and future requirements when acquiring and setting up a wiki. Target audiences may be strictly U.S. Navy shore commands, but can also include U.S. naval ships, foreign navies or NGOs. Some users may only need to view the information while others may need to view and edit.

Stick to Open Standards

Keep in mind that not everyone uses Microsoft products. Whatever product is used, it should have vendor agnostic standards. HyperText Markup Language (HTML) is an open standard; Active Server Pages (ASP), Lotus Domino and Adobe Flash are not. While Microsoft SharePoint has good integration with Office 2010, U.S. Navy ships use the Common PC Operating System Environment (COMPOSE), which does not currently support Office 2010.

For best results for information sharing, no custom software client or fly-away kits should be required; they will certainly not be part of the baseline for partner nations or NGOs. Additionally, custom clients are costly in terms of time and money. Fly-away kits are also difficult to incorporate into the networked environment because there will never be enough of them for all users, and it will always be a challenge to get the kits to the right deploying unit on time.

Further, what happens when a component on a fly-away kit has a casualty? Are there enough kits left in reserve for replacement? At this point, the equipment that was considered a fly-away kit is now organic to the ship, and there is no flying away anymore.

Mobile and Reduced Bandwidth Versions

Users need content, although some will want it to be aesthetically pleasing. Separate mission need from user want. In the June 2010 edition of the Information Professional (IP) newsletter, I wrote an article on how bandwidth-restricted commands could direct users to mobile, “lite” versions of websites through user agent strings.

One brave IP implemented this temporarily on a carrier strike group for the entire Facebook website. The mobile version of Facebook allowed the crew to communicate with friends and family, but did not allow access to FarmVille or some of the other games.

While the primary mission of allowing Sailors to communicate via social networks was accomplished, many complained about the lack of access to unauthorized, bandwidth-hogging information assurance risks. This is a clear example of a usage while providing 90 to 100 percent of the functionality that users need.

Security

The security of any network-enabled tool is critical. There are some very basic administrative steps that should be taken to secure these network tools. The first obviously is to be cognizant of who is authorized to view information and who is authorized to edit information. Fortunately, wikis keep logs of user updates.

It is equally important to have a good authentication scheme. User names and passwords are usually sufficient, but the password requirements should include both complexity and expiration requirements. Likewise, user accounts that have become dormant or which belong to personnel that no longer require access should be deleted.

Consider the Layout

There is no right or wrong way on how to design a layout for a wiki, but there are some best practices. Two things that are of paramount importance to users are determining what content has changed since they last logged in and helping them find the content they’re looking for. Streamlining these tasks will save users from tremendous frustration, and it will also save the unit’s bandwidth.

After the initial login screen, the next page to load should be useful to the user. This seems intuitive, but I’ve seen so many wikis where this is not the case. Upon logging in, a user should be presented with a page that contains three things: a “What’s Hot” list of important documents/links/content; any system-wide announcements; and any changes to content to which the user subscribes.

For NKO, What’s Hot might be changes to uniform policy; system-wide announcements might be upgrades to NKO servers; and user subscribed content user want versus a mission need. Mobile or lite versions of Web pages provide vast savings in bandwidth might be changes to the IP officer page. Additionally, pages should have Really Simple Syndication (RSS) feeds. An RSS feed includes summarized text and metadata with a published date and eliminates the need to click into the actual content. More importantly, RSS feeds can be updated without explicitly visiting a site and, in many cases, RSS feeds can be accessed without even opening a Web browser.

Sites should be designed so that it takes no more than five clicks to get to any content on a wiki. Remember that every time a user selects a link, there will be a waiting period for the page to load. Tree views, which present a hierarchical view of information, are great for navigating directly to content. It’s also important to provide a “map” to show users where they are currently located on the wiki.

Knowledge management is key to the success of your wiki. If your wiki supports a staff, the organization of the wiki should probably mirror the staff organizational chart. Remember to archive outdated content. Note that I wrote “archive” and not “delete.” Depending on the content, it may be beneficial, or legally required, to keep old documentation. Create an archive section that is also easy to navigate. Congratulations, you are now a wiki wizard!

Continuity of Operations

This tongue-in-cheek expression often holds true: “Why buy one when you can buy two at twice the price?” We often work in adverse conditions. Things break. No plan survives enemy contact, so we need a secondary location for our files in case of a downed communications link. A possible single point of failure will become the single point of failure; thus, wikis and their content must be backed up regularly.

One area in which wikis are currently lacking is in the area of replication. The latest high-tech buzzword is “the cloud.” What does it mean? It means that if the server that holds all of my data dies right now, none of my users are the wiser because another server magically makes itself available. It means that if I can’t reach the U.S. Naval Forces Southern Command, U.S. Fourth Fleet (C4F) portal, my network automatically presents me with an exact replica that is mirrored on my ship. This idea of replication is an area ripe for development.

Chat

Chat offers a completely different functionality than a traditional wiki; however, chat is often supported in conjunction with the use of a collaboration portal. Most of the best practices for selecting a chat product are the same for selecting a wiki. Stick to open standards and reduced bandwidth variants when possible. The two most common chat protocol standards are Internet Relay Chat (IRC) and Jabber/XMPP (Extensible Messaging and Presence Protocol).

The advantage of using IRC or XMPP is that clients exist for virtually any and all operating systems including cellular phones. Additionally, if installing custom software is not an option, Web-enabled clients exist that require nothing except a Web browser and Java. While shore-based commands have the advantage of using Web-enabled clients, bandwidth restricted units may want to install standard software clients. Most modern chat clients support multiple standards. It is recommended, however, that unneeded and bandwidth-intensive features, such as file transfer and video chat, be disabled by default.

Create and Collaborate

Wikis hold tremendous promise for collaboration and can be tremendously successful tools if selected, administered and used correctly. We must find ways to create and collaborate with each other, with our partners, and with NGOs in near real-time. Wikis hold the promise of letting us do just that.

Lt. Cmdr. Pablo C. Breuer is the staff communicator for Commander, Destroyer Squadron 40.