A complement to Wiki Talk Pages in enterprise Wikis

As a documentation PM, I recently took some spare time to inspect the Talk Pages feature in the MediaWiki software. As an enterprise documentation PM, I concluded that Talk Pages has its limits when MediaWiki software is used in enterprise settings (instead of public settings, for example, Wikipedia).

So, I came up with a feature idea to bridge the gap of Talk Pages for enterprise MediaWiki users. I call it Page Action Items.

For a PM, sometimes the context where a software is used is as important as the specs of the software itself. MediaWiki is an example for this. Enterprise wikis are different from public wikis such as Wikipedia in the following ways:

  • In an enterprise environment, every wiki user has each other’s contact info (corporate email, internal IM, etc.). This means they don’t need a designated communication channel on the wiki to have discussions.
  • Unlike Wikipedia, a tertiary source of information, enterprise wikis are usually primary/secondary sources for internal business information. Therefore, pages usually have an owner – the person/team accountable for the business section – instead of being owned/moderated by the community. Discussions on page content usually happen in a small ring of owners.
  • The target audience of any given page are the stakeholders of the corresponding business section. This means when discussion of content happens, the stake is higher, and the discussion is more time-sensitive. If someone calls out a mistake in business data on a page, the page needs to be changed as soon as possible.
  • Enterprise wiki content is usually regarded as official business documentation. This means although not usually involved in editing pages, Readers are usually very responsible and can be trusted to directly alter the page and call for page owner’s attention when they believe the page needs updates.

For example, consider a user story: Suppose Burger King (BK) had an internal wiki. Two BK employees, Alice and Bob, are marketing specialists who oversee BK’s spring promotions in Vancouver, among other things. One of the pages they maintain is called “Spring 2019 Promotions in Vancouver”. They are the Contributors (owners) of this page. Charlie, who is a store owner in Vancouver, would be a Reader of this page – and not a Contributor – because he doesn’t own BK’s promotion strategies. Usually when the page content needs to be updated, Alice and Bob just exchange emails to sort out the updates and change them once the details are finalized. But now suppose Alice typed down a wrong price for a promotion item on the page and Charlie spotted it. What does Charlie do? He can email Alice or Bob, but by the time they correct the price, other store owners might have published the wrong price. He can’t just correct it himself because he doesn’t know the right price. He can raise an issue in the Talk Page, but chances are other store owners won’t check the Talk Page immediately – neither would Alice or Bob. His best option might be to edit the page and call out that there is likely a mistake on the page. But even this way, he doesn’t know when Alice and Bob would see his comment, as they manage too many wiki pages. Charlie needs a way to effectively bring the page to both the owners’ and the Readers’ attention.

Such differences make Talk Pages less useful in enterprise wikis than in public wikis. Instead, in enterprise settings, the need for communication shifts in the following ways:

  • Because the ring of Contributors for each page is considerably smaller than that of public wikis, general discussions about the wiki content doesn’t have to be done on the wiki.
  • When actions need to be taken to update business information on wiki, Readers need to be notified directly on the page, and owners need to easily keep track of all actions needed on all their pages.

As we see, in enterprise wikis, Contributors (page owners) still need input from others. But input from other Contributors (page owners) can come from other corporate communication channels such as emails, and input from Readers usually are in the form of action items that need to be addressed. Here I came up with a Page Action Item feature to allow Readers to effectively pass on action items to Contributors.

  • On a wiki page, there will be tools available, ideally as buttons on top of the page, for all Readers to easily assign action items to the page, such as “correction needed”, “missing information” or “page should be removed”.
Mockup for Page Action Item, 1 of 3
  • Once an action item is assigned by a Reader, a corresponding banner will show up on top of the page, warning other Readers of the page to be cautious of work-in-progress information.
Mockup for Page Action Item, 2 of 3
  • In addition to immediately receive email notification about the action items they were just assigned, with a link to the corresponding page, Contributors of the page will also be directed to a Contributor dashboard, a one-stop tool to surface and triage all action items on their pages.
Mockup for Page Action Item, 3 of 3

This feature will help enterprise wiki users ensure that all stakeholders are highly in sync about the status of business documentation, and Contributors can effectively track, triage and act on their tasks in maintaining business documentation.

Of course, this article is, after all, an idea. It needs more PM investigation on the users, usage scenarios and other current solutions. It also needs further discussions in UI design of the action buttons on the page and Contributor dashboard. It’s also important to carefully design the UI/UX elements, possibly with an onboarding guide, so that users understand the feature and don’t end up using both Page Action Item and Talk Pages to do the same thing – which will only create confusion.

If you are interested in discussing further, feel free to ping me on MediaWiki Phabricator, @Msftwikipmey.