Tech Writer: Kyocera
Kyocera was my greatest challenge and most satisfying job of all I’ve had.
Hired as a tech writer to join a team of 4 writers, a UI string editor and 4 Japanese translators, I became involved in so much more. Our team was already investigating the selection of a new DITA/CCMS system to transition our topic-based authoring system to. I was immediately interested in the selection process and the world of DITA/CCMS software. Our choice had to also integrate with a translation manager, so our DITA content could be sent out for localization into as many as 20 languages.
New to DITA when I joined Kyocera, I tasked myself with learning about DITA, DITA XML language, and, critical to implementing cost-saving to our documentation, the use of variables for branding documentation. I taught myself about conrefs, conkeyrefs, conditional processing, DITAval files and use in publishing and remember the joy of the ‘ah ha’ moment when I first managed to publish a document using two different brandings, covering both images and text (company name variables)!
When we selected easyDITA and XTM for the tools we’d use going forward, I was involved in converting our existing content from DocZone into a DITA format that would work in easyDITA. I was part of the team of three that handled the implementation, met weekly with the two vendors to bring up and resolve problems.
As I learned the ins and outs of using easyDITA, and working with a link to the DITA XML editor Oxygen, I taught my team the tricks I’d learned. Eventually, I wrote up many processes into short Confluence articles to show everyone how to accomplish tasks and troubleshoot problems. When we started the implementation, I was tasked with designing the architecture of the system we would implement.
When it became clear that our version control would need enhancements gained from implementing a branch, merge and release strategy, I learned about how those functions worked in easyDITA, designed the rules for when we would use each function and trained the team on how to do it.
Kyocera out-sourced some of the writing responsibilities to a team of authors in the Philippines, and I worked with them to learn how to handle the workflow of write, review, localize and publish. I made adjustments to processes based on working with the new team and integrated all into the workflow.
I had begun to investigate changes in technology, such as converting from the old Microsoft .chm online help format to Oxygen’s Web-help Responsive format.
Honestly: Best Job Ever!
Hired as a tech writer to join a team of 4 writers, a UI string editor and 4 Japanese translators, I became involved in so much more. Our team was already investigating the selection of a new DITA/CCMS system to transition our topic-based authoring system to. I was immediately interested in the selection process and the world of DITA/CCMS software. Our choice had to also integrate with a translation manager, so our DITA content could be sent out for localization into as many as 20 languages.
New to DITA when I joined Kyocera, I tasked myself with learning about DITA, DITA XML language, and, critical to implementing cost-saving to our documentation, the use of variables for branding documentation. I taught myself about conrefs, conkeyrefs, conditional processing, DITAval files and use in publishing and remember the joy of the ‘ah ha’ moment when I first managed to publish a document using two different brandings, covering both images and text (company name variables)!
When we selected easyDITA and XTM for the tools we’d use going forward, I was involved in converting our existing content from DocZone into a DITA format that would work in easyDITA. I was part of the team of three that handled the implementation, met weekly with the two vendors to bring up and resolve problems.
As I learned the ins and outs of using easyDITA, and working with a link to the DITA XML editor Oxygen, I taught my team the tricks I’d learned. Eventually, I wrote up many processes into short Confluence articles to show everyone how to accomplish tasks and troubleshoot problems. When we started the implementation, I was tasked with designing the architecture of the system we would implement.
When it became clear that our version control would need enhancements gained from implementing a branch, merge and release strategy, I learned about how those functions worked in easyDITA, designed the rules for when we would use each function and trained the team on how to do it.
Kyocera out-sourced some of the writing responsibilities to a team of authors in the Philippines, and I worked with them to learn how to handle the workflow of write, review, localize and publish. I made adjustments to processes based on working with the new team and integrated all into the workflow.
I had begun to investigate changes in technology, such as converting from the old Microsoft .chm online help format to Oxygen’s Web-help Responsive format.
- I implemented a set of Schematron rules to provide guidance on allowed and not allowed terminology during the authoring process.
- We also were investigating a conversion from the standard DITA open toolkit PDF publishing to an HTML/CSS based publishing tool, to give us more in-house control over the format of our publishing choices.
- Lastly, and almost the most fun of all, I was the lead “bug-catcher” for troubleshooting problems with our tools.
- Why did that publish fail?
- A single topic didn’t show up in the translation editor, why?
- You’re getting an error in easyDITA that you don’t see in Oxygen?
- Why did that conditionalized image NOT switch for the 2nd brand?
- Why did that publish fail?
Honestly: Best Job Ever!