Genesys publishes up their technical content using Mediawiki and related extension - solving a host of content management problems using a query-based approach to structured authoring.
More than Just Lines on a Map: Best Practices for U.S Bike Routes
Content as Data: Developing Structured, Query-based Wiki Content
1. Content as Data | STC Summit 2015 | #stc15 | @GrenonBarry 1
Content as Data
Developing Structured, Query-based Wiki Content
and Barry Grenon
Senior Manager,
Genesys
José Druker
Staff Technical Writer,
Genesys
Tues. June 23, 2015
1:00 PM in Franklin B
#stc15
@GrenonBarry
8. Content as Data | STC Summit 2015 | #stc15 | @GrenonBarry 8
Background -- Books on our wiki
We use an extension called Ponydocs, which basically stitches together a set of
wiki pages into a “book” with a version, a product, and a table of contents to
navigate through the pages. Here’s what a book page looks like on our wiki.
9. Content as Data | STC Summit 2015 | #stc15 | @GrenonBarry 9
Lots of reference material
We also have books that are strictly reference material – content that might be
used in more than one location, and requiring different levels of detail in
different contexts.
12. Content as Data | STC Summit 2015 | #stc15 | @GrenonBarry 12
Challenge and opportunity
So, how to successfully create and maintain useful, easy-to-find, richly linked
web pages?
The challenges can be distilled into two main areas:
• How to handle the amount and complexity of enterprise-level content
• How to construct good web pages that work together (think EPPO)
The challenges are also opportunities to improve our documentation by:
• Taking advantage of what the web can offer
• Exploiting possibilities for reuse/repackaging/dynamically generating content
The “content as data” model we’ve developed helps us meet the challenges
and exploit the opportunities.
2015, Genesys Telecommunications Laboratories, Inc. All rights reserved.
28. Content as Data | STC Summit 2015 | #stc15 | @GrenonBarry 28
Gotchas and Complications
All complications can be worked through, with… work.
• Draft vs. Published
• The usual single-source issues
• Writer’s and the “black box”
• Skill set to make templates and build queries
Do the work once – efficiency compounds over time.
[JD] Thank you for your interest in our topic.
My name is BG, senior manager in the tech pubs group at Genesys
My co-presenter is not here unfortunately, due to some personal circumstances that came up.
I want you to pay attention to the word “query” on this slide – the query is the heart of it, and what makes it different from other systems that I know of.
Big software company – a lot of content, a lot of writers split mostly between California and East Coast Canada, with a few others sprinkled throughout the world.
We went wiki as a way to get content online, and worked our way into a content management approach that we find really exciting with its range of possibilities and benefits.
[BG] This is for anyone who is interested in getting the benefits of structured documentation, in a mostly unstructured body of knowledge. This is a pretty technical, hands-on demo of how you can use MediaWiki to manage your content.
[JD] Just to make sure we’re all on the same page.
For Data: Means you can ask the database questions and get information back based on different criteria.
For Metadata: We mean more than the traditional metadata such as author, date created, etc., which MediaWiki provides. We mean content-related tagging – e.g., that a particular phrase is a procedure title or that a particular line item is the default value for a configuration option.
[BG] For Single-sourcing: Not multi-channel publishing. The same piece of content can live in different locations.
For Query: Queries are the heart of the system. Being able to query the content stored in a database way gives us the single-sourcing, the variable formatting and basically the main benefits you can get from DITA-type systems, but using dynamic queries instead of static maps.
For Wiki: We use MediaWiki.
[BG]
[BG]
[BG] Ponydocs was built by Splunk for their own docs and released open source.
The book model -- make it familiar -- was the key to our initial success in moving the content online. It let us create a simple website architecture, a portal page for every product, and a “book” to match the old PDFs, with page numbering.
This is where we started with wiki work.
[JD] This is one visualization of the content. Writer manually creates the full description in another guide (much longer than suitable for a table), which could include links to other metrics. Because of maintenance overhead, this table wouldn’t link directly to the full description.
[BG] EPPO = Mark Baker
[BG] For enterprise-level content: Think how one bit of reference information can show up in dozens of different contexts in books/tables/individual pages.
For advantages of the web: Link-ability, reference-ability
[JD] Templates:
The boilerplate can include wiki markup for formatting.
“Mini-style sheets” means they’re directly editable in the wiki, for discrete visualizations of content.
Queries:
Our queries are shielded behind templates.
Repository:
Our repository pages are either in a separate namespace or in a Ponydocs book that is never released (we call it a “library” book).
[BG] Mention that you can also use form entry. Most useful if letting other groups add very structured content.
Note the MediaWiki syntax for specifying named parameters.
[JD] Lots of useful MediaWiki parser functions – e.g., {{#switch}}, {{#if}}, {{#ifeq}}, {{anchorencode}}, {{#explode}} – give you lots of flexibility to control what gets displayed and how. Things can rapidly get very complicated behind the scenes!
[BG]
[BG] Constructed page pulls together actual content from many individual pages in the repository.
[JD]
[JD]
[BG] Many-to-many
[JD] Many-to-one.
Use the same query but change the formatting to give different visualizations of the same content.
Change the query to get different content.
[BG]
[BG] Constructed page pulls together actual content from many individual pages in the repository.
[BG]
[BG] It is worth moving content into the template format, strictly for the efficiency gain on writers not fiddling with formatting. In effect, all of the single-source, alternate display, automatic population of related content, is stuff you can get for free, because your content is set up in templates, as named paramters.
In other words, you could stop at just formatting, and not use the queries, and it would be an increase in efficiency. Queries then turbo-charge that efficiency.
[JD]
Draft vs. Published – we use a variety of strategies to control the public visibility of content.
The usual single-source issues – links, static vs. always-updated content, etc.
Writer acceptance – writers need training and time to adjust to losing control to “the black box”.
Template design and query skills – need a combination of software and information management skills (a technical writer!)
Strategies for draft vs. published: MediaWiki categories, a “docstatus” parameter on the page on which the templates switch to provide alternative outputs, parallel repositories combined with a bulk page-transfer tool.
Simplicity increases complexity – the simpler you want things on the front end, the more complexity behind the scenes.
Use forms – give writers forms to hide behind-the-scenes complexity, reduce errors, and enforce content requirements.
Enforce naming conventions – metadata FOR FREE! Good page names especially can give you a lot of useful metadata for free.
There is a whole community around Semantic MediaWiki. But no substitute for a good technical writer.