The Product Was Called Format Finder. I Made It Actually Find Formats.

The Situation

Sabre's Format Finder was a 2.5-million-word online help system maintained manually for approximately fifty years. It began as one of the first analog hypertext help systems. I was brought in to update the technology, but I would find numerous issues before we could future proof the help system:

• I was mandated that everything I build get the most out of Sitecore, the CMS the help system would migrate to
• There were four technical writers pulled from customer service but without formal tech communication training
• The help system was overly verbose with fifty years of prose upon prose; some help text would explain the history of a specific command without going into detail about syntax
• The speed of loading globally was slow, especially outside the U.S.
• There were eight languages it would be translated into plus we had to be ready for Asian translations in the near future
• The writing team was not allowed to interact with development and other departments without manager approval and pre-scheduled meetings, keeping the tech writers out of the loop until it was close to release time

The Approach

To approach this project the following happened:

• Design-thinking session: I led a three-day workshop to understand the structure and reasoning behind the current help system; the outcome was a DITA solution.
• Research, so much research: At the time, Sitecore didn't support DITA; a professor from The Netherlands specifically told me putting DITA into Sitecore was "a pathway to hell."
• Developed a PIM approach: I developed the approach of using platform independent models (PIMs) to solve the Sitecore problems.
• Breaking down the current infrastructure: I took a look at the current network environment of Format Finder.
• Proof of concept for DITA: The first thing I did was create a test content model based on DITA. As the kind old Dutch professor told me, DITA in Sitecore would disable certain Sitecore features, especially with personalization. I tried this on a local install and confirmed. However, my mandate for Sitecore features were still in effect.

The Solution

Buckle up, this is where it gets fun.

Platform Independent Models in Action

PIMs work best when they are actual adopted standards you can reference. Here is how I built PIMs for my solution:

• DITA: First and foremost, we needed to structure the help content. Just by separating conceptual material from procedures would clarify the help.
• Dublin Core: This platform is perfect for an extra layer of metadata related to institutional metadata and is a great standard for archiving, independent of a CMS.
• XML vocabulary: I wrote an XML vocabulary specific to Format Finder so it wouldn't conflict with other XML projects. Sitecore is built on XML and would handle the XML and pass it along to our search server, SOLR.

Content Strategy

My approach for the content itself consisted of some standard processes for content strategy, but they needed more research and planning because this was a business-critical application.

• Content assessment: I performed a content assessment on the current help system, discovering 2.5 million words. I wanted to cut it by 30% or more.
• Tech writer training: I began training the four technical writers on International English as well as how to chunk and write in topics.
• Content modeling: I modeled a DITA adjacent model that included all of the XML vocabulary, the topic IDs for context-sensitivity, plus hierarchies for navigation and search.
• SEO: Since we were using SOLR for search, I built out dictionaries for search hierarchy: industry, institution, department, and product. I also developed stop words and context words for association. I worked with the SOLR admin to optimize all of this for high performance internal searching.
• Translation: I worked with the translation team to build better workflows for writing to translation. This was not an existing workflow because the content was authored in Author-IT and sent over for manual inclusion into Sitecore.
• Network: I worked with the network team to spec out Sitecore/SOLR clusters for global production to improve site performance.

Dynamic Content

Sitecore is complex, but it can really work with content chunks and dynamic content when needed. Here is how I dealt with dynamic content in Sitecore:

• Author-generated databases: I designed custom integrations with Sitecore which would help the CMS with bulk editing, command line syntax, and the ability for writers to create and maintain dynamic content.
• Command database: The commands in Format Finder were complex. I worked with the admin of Sabre's telemetry data lake where we figured there were about 110 "templates" for how the syntax worked across the product platform. See the illustrations after this list for how I broke down the command syntax.

Summary

Sabre replaced Sitecore with Salesforce before the model was fully implemented. Because the model was platform-independent, it survived the platform decision. The work wasn't lost; it was just ahead of its time. Again.