As a Documentation Engineer, my responsibilities include project management for the Technical Documentation portal. I work closely with our documentation portal vendor to identify, propose, and coordinate features implementation, bug fixes, and design enhancement.
The legacy API operations topic on the Cherwell documentation portal was a static page created in an XML editor with information provided by developers. Without access to the code, technical writers were dependent on SMEs to communicate changes to the API that needed documentation.
To avoid this dependency and give more control over the documentation to writers, I worked with development, the documentation team, the portal vender, and several other teams to establish a process to generate a JSON file from an instance of the software for each release. This JSON file is transformed using plugins for the DITA Open-Toolkit and published on the portal as a Swagger UI page. By removing the interactive features of Swagger UI from this page, I can provide a secure, up-to-date version of the API documentation.
At Cherwell, my responsibilities include creating documentation for two platform development teams and managing the Documentation Portal. The following examples display my use of content strategy techniques to provide necessary information about complex topics to audiences with varying levels of technical ability.
As an embedded member of an agile software development team, I directed the content strategy and created the documentation for this machine learning (ML) project. As with most ML features, the difficult technology remains unseen by the user. A large part of my work involved using minimalist writing techniques to provide only what the user needed when they needed it. This involved brokering a compromise regarding what information is available to the different audiences involved in the project: end-user, customer administrator, and internal audiences (development, support, etc.).
A feature development team that I worked with at Cherwell replaced the message queue service with an open source option. The documentation process involved collaboration with members from several different teams at various levels within the company. After starting as a couple small topics to describe the implementation by development, the support team noticed repeated questions in customer calls. To reduce the number of support calls, I iterated the documentation to dig deeper into this application. The documentation set for this project evolved to encompass multiple configuration, and troubleshooting topics.
In 2017, Calabrio acquired an analytics and data visualization software company. At the time, customers had access to a limited set of documentation published on Confluence. The space was maintained by developers and product management. As the technical writer for this project, I reviewed published and unpublished content to develop a strategy and migrate content to MadCap Flare.
The functionality of the reports drove most of the demand for this software. Reports are an integral part of the application and the main interface that users encounter.
The existing, public Advanced Reporting documentation did not adequately explain the importance of reports.
I enhanced and this topic to provide an explanation of reports. Once the content was complete, I adopted this conceptual topic as the landing page for a section of the new documentation set. While the new documentation is proprietary, this topic remains on the original Confluence space.
This topic worked in tandem with the conceptual "Understanding reports" topic to fill a gap in the reporting documentation. The goal of this project was to clearly lay out the complex series of steps to create a report. It adheres to the existing topic structure for tasks. This topic was