7. Documentation engineering and automation
This chapter develops the engineering detail behind Umbraco migration tooling, Figma retrieval, and documentation validation. The Writing examples show how source changes can be inspected in a rendered form.
7.1 Preserving content through migration
Migration work brought source structure, authoring behaviour, rendered output, and publication packaging into the same investigation. The Umbraco/Pulse history describes determining which source formats should drive import, comparing output with existing SOTI XSight help, and producing static packages compatible with Pulse/WebHelp. The process evolved through HTML, DITA, Markdown, and hybrid discussions, so I do not impose a single final input pipeline without the latest implementation evidence.
The integrity requirements are specific. They include notes and tips, line breaks after note titles, table widths and merged cells, image dimensions, IcoMoon icons, media-folder conventions, static assets, local links, context-help IDs, search, and “On this page” behaviour. Related-information work also includes parent and neighbouring-topic links. Later history records concern about how task sections such as About this task and Procedure transfer into the target authoring model.
These details explain why migration is more than transferring prose. The structure and relationships must survive, and the rendered result must still function as help. The quality chapter retains the observations that informed this work.
7.2 Export configuration and publishing tools
The report records build-numbered export folders using UNIX time codes and product/version-specific configurations. It describes a goal of supporting multiple products and versions instead of only SOTI XSight 2026.1.0. The Umbraco Publishing Tool was requested with a Technical Writer-oriented interface, a fixed HelpDocs URL, configurable client credentials, export options, progress display, and later simplification of the page layout.
The graphical interface belongs to the usability part of the project: making a technically involved export understandable to its intended operator. Client-secret values are not retained in this master. Configuration concepts, access requirements, and technical context remain available without reproducing credentials.
My investigations included test-content cleanup, locating source HTML, reconciling SOTI Identity imports, comparing exporter packages, and inspecting current files.
7.3 Structured content transformations
My DITA-to-Markdown table findings describe a limitation in the DITA-OT Markdown pipeline. The proposed investigation was staged: test markdown_github, try a lightweight Python post-processor if needed, and consider a custom XSLT plugin as a longer-term route. These alternatives should remain identified as an investigation and proposal rather than an assertion that every stage was implemented.
The record also includes a DITA Figure Wrapper instruction file describing a desktop utility for identifying or wrapping image structures without extra Python packages. The guide is evidence of packaging technical knowledge for reuse. The audit located and inspected the original guide and the utility source. The guide describes a Windows/Python desktop tool that follows map and topic references, detects images outside figure elements, supports a size filter and scan-only mode, and exports reports. Its source imports Python standard-library modules, including Tkinter. Runtime and round-trip testing remain separate from this source inspection.
Nested/merged-table inventories provide a separate contribution: locating risky source structures before conversion. They inform testing and transformation decisions rather than proving that all problematic tables were repaired.
7.4 Human readable review interfaces
The rendered-diff work aimed to make DITA changes inspectable through HTML previews, highlighted differences, and before-and-after output. The history records a preference for full-page review resembling a familiar document surface, rather than requiring every reviewer to interpret XML. That requirement appears in both WYSIWYG diff and epic comparison work. The ten writing comparisons offer a visitor-facing example of that review principle; they are a separate portfolio rendering, not a claim that the original internal tool was released publicly.
An SME review-tool exploration involved rendered content, comments, possible WYSIWYG editing, and hosting as a service. The work-history report identifies a local darryls-review-pal project and requests to adapt it for SME review. This is evidence of investigation and requested changes, not confirmation of a production collaboration service. The ownership of the starting code should be established before attributing the entire implementation to me or publishing it.
Other review-related investigations counted ditamap-linked topics with substep elements, located file references and author history, and divided linked SOTI MobiControl 2026.1 topics among reviewers. These supporting utilities help define review scope and assignment but are not interchangeable with the authoring substitute tool.
7.5 Jira Figma and reporting integrations
The Jira/Figma retrieval project connects a feature identifier to its design evidence. Discovery across child and linked tickets, multiple frames, image export, account limitations, and a local browser interface all appear in the report. The repeated investigations suggest an evolving tool, but its current code and export behaviour have not been verified for this master.
My reporting experiments include a refreshable Aha workbook for the Technical Writing team, Excel/Jira Data Center guidance, ticket-status notifications, and commit-history analysis. I used an exported pivot as the starting point for a more useful refreshable view.
7.6 Repository based development
The August 26 to September 2, 2026 GHE access case describes my HelpDocs migration development and standardization of documentation-authoring tools. It identifies collaboration with Mike Van Halteren/Data Science on Umbraco Utilities and source-level work in a HelpDocs POC repository. The intended role of Git was shared code, history, and review before Web-team acceptance or deployment.
The report records approval on September 2 and a Help Desk observation that this was the first instance of a Technical Writer receiving GHE access. I retain that as a reported observation within the access case, not as an independently verified company-wide distinction or a performance award.
7.7 Environment and server troubleshooting
The documentation-tooling history includes IIS static hosting, rewrite and proxy rules, local services and ports, cache refreshes, Umbraco preview/publish behaviour, metadata previews in Teams, Ant installation, transformation failures, Git access, SSH/RDP, and networking commands. It also records AI environment and MCP setup investigations.
These tasks are part of keeping the workflow usable. They belong in the technical record with their context and uncertainty, rather than being presented as a collection of unrelated finished software products. The full work register retains their individual dates, titles, and requests.