American Petroleum Institute (API) is a standards-setting and lobbying organisation for the oil and gas sector of the energy industry. The organisation maintains a catalogue of more than 800 standards and produces 70+ revisions and first editions annually.
Prior to using Typefi, there were numerous challenges in publishing these standards which resulted in a backlog that slowly grew to more than 100 documents.
After switching to a new publishing workflow using Typefi and Inera eXtyles, API was able to drastically reduce turnaround time for its standards, cut proofing time in half, and produce a record number of standards in 2022.
In this presentation from the 2023 Typefi User Conference, Andy Charest, editor at American Petroleum Institute, discusses the problems the organisation faced prior to using Typefi, the challenges of changing the old process, and the incredible successes that the organisation has seen since working with Typefi.
Transcript
Background (00:00)
ANDY: How you doing? I’m Andy Charest from American Petroleum Institute, to differentiate from the technical term API that’s been used about a hundred times this morning.
I am not a techie, I’m a simple editor, but through using Typefi and eXtyles over the past three, three and a half years, been able to learn a little bit about what goes on in the backend. And that’s been really valuable for me and for my team.
Chris Forsberg and Pat Little are here. They’re editors in our editorial team, which is part of the greater Standards Development department at API. So everyone hear me, talking too loud? Okay.
So American Petroleum Institute, it’s part of the energy industry, oil and gas sector. It began in 1919 as a standards-setting organisation.
So a lot of people, especially in DC, know API as a lobbying group. But really we have two floors, the 11th floor and the 12th floor of our building. 12th floor is lobbyists. 11th floor is standards.
We create certification exams, auditable standards, recommended practises, technical reports, specifications covering all sectors of the industry. We have a 20-person standards staff that includes us, two part-time editors as well. And then we have a freelance graphic designer.
And we publish an average of 75 standards revisions a year, plus errata, translations, and then we also help the policy team up on the 12th floor with corporate policy white papers. So, busy, we got our hands in a lot of different projects at all times, and it’s a little bit overwhelming.
But I have to say we’ve done pretty well over the past few years, which I will explain in the next slide.
Publishing at API before Typefi (02:19)
So two decades through 2017, we alternated between having people in-house and outsourced editors.
Anybody who has worked in newspapers or in any kind of journalistic capacity understands that the life of a copy editor is a very, very tedious one, and you just don’t know if you’re going to be outsourced or if you’re going to have a job the next day.
Fortunately, we’ve had this team together for about six and a half years right now, and I think we’ve been able to prove our worth. So thanks to you guys. And I just wanted to make that apparent.
So the lack of continuity though in the staff, it resulted in a big backlog, a hundred documents plus. Really not much adherence to our in-house and Chicago style manuals, and just inconsistency all over the board.
And I use the word rampant because I mean, I just don’t have enough words to describe how inconsistent these documents were. From revision to revision from segment to segment, it was a blank show.
And so hires made in 2017, I was hired, Chris and Pat were hired to create a new editorial team. Hard work, brute force, we were able to eliminate the backlog. And then we actually established a goal of all things of publishing 70 revisions, first editions, a year.
But even though we were successful with that, a big elephant in the room was the inconsistency.
So you have formatting, nomenclature, et cetera among the committees, the authoring committees that write the standards. Each committee seems to have its own break from style that they are dead set on. And if you’re working with authors, you know that they can be difficult to work with and really great to work with both at the same time and everything in between.
So that is, I would say even now, that is the one constant challenge we have, which I’ll explain it in a subsequent slide.
So in order to create a more consistent workflow, and also we wanted to take a step toward digital publishing, which we were tasked by our VP, we contacted Inera, maker of eXtyles, and Typefi.
New workflow with eXtyles and Typefi (04:53)
So we wanted to convert our Word standards to XML, establish a fixed template that, I will use the word encourages, but really forces consistency in document production. And then be able to publish not just a PDF, but eventually to alternate outputs.
And we actually did, not to get ahead of myself, but a separate workflow to EPUB that Jamie helped us with. And while we’re not selling the EPUB versions of our standards yet, we did a pilot project with three of our most read standards, our most popular standards, and on both the Apple mobile platform, Apple Books, I guess, and then Google Play Books, it looks great.
Tables look great. All the links work. It’s a usable document for anybody that has a mobile phone. Which is great for when we have people out in the field, they don’t want to take a laptop, they don’t want to take a giant manual, they just want to have something that’s in their pocket and then they can reference a specific table, click on it, blow it up a little bit, and it’s right there.
So that was really helpful and that’s going to become more helpful in the future.
So like I said, our solution. We wanted to use eXtyles for formatting and to convert to XML, and then Typefi for automated publishing. We started working with both companies in mid 2018.
Jamie came out to DC and trained us, and then we customised both tools to our specifications, into our style guide, by early 2019.
Results of switching to Typefi (06:35)
So it was a big boon for editorial. It was a learning process, but at the same time, it helped us to be more efficient in our publishing.
So as I was saying earlier, authoring committees, slow to accept a new workflow. They were used to trading these Word files that had, from different versions of Word, photocopied corrections, and then a lot of creative kerning and leading where it just looked awful. It was like a really poorly typeset book that was done on a Xerox machine.
So fixed layout took away that “creative” energy from the authors, and that was a shock to their system…Subcommittees that work on these standards, there’s more than a hundred subcommittees. So you get a lot of input from a lot of different people. And juggling that, funnelling it all down into a new way of doing things is really, really hard.
And that’s not part of our job description, but it’s become part of our job description—to not just be editors, but also to influence people who are not used to being influenced.
So, fortunately we had positive results in terms of the efficiency of our page proof reviews, and that brought some buy-in from most of the committees. Several are and never will be sold. It’s okay, because we’re in charge here, at least for this.
So we published 80 documents a year in 2019, 2020 and 2021. That’s 10 higher than our initial goal of 70. And then an API record 95 documents in 2022.
We worked really hard. Like I said, a lot of brute force, a lot of factors go into that, but Typefi, eXtyles’s workflow, it proved to be a game changer for us.
We didn’t have to manually fudge Word layouts, automatic updating the table of contents—we were talking table of contents earlier—and fixed layouts for front matter and back covers. And then Jamie was able to work with us to have custom front covers for joint standards as well.
So those were two elements that were really inconsistent due to author’s preferences. So we were able to get around that. That was really, really a boon for us.
Changes to the workflow (09:21)
So, only constant is change. That’s true. Definitely where we work. With more than a hundred authoring subcommittees across four industry segments, new requirements, and then constant requests in how to present our standards that are not conducive with our style guide and our processes.
So because these standards committees, they are the ones writing the standards and they are governing the subject matter, a lot of times there’s no give in any departure from how they want the information to be presented. So, we have to try and find a happy medium between their requests and then the services Typefi provides for API.
So Jamie and Dilum have been our solutions consultants and really responsive to the variety of requests and different requests that we’ve had over the past few years. So thanks a lot for that. It is probably not easy fielding all those Typefi help requests, but it’s much appreciated.
Bullet styling challenge (10:38)
But one of these, I just wanted to let you know, this is a really “in the weeds” type of issue that we had, but it shows that even a small change makes a big difference in a document and how a document is read and how it’s used.
So this had to do with automating a laborious process, and that is manually adding a bullet in the left margin to show that a purchaser needs to make a decision on a specific type of equipment or the equipment’s function. Purchasing Bullet Automation—you’re never going to hear that term again, but that’s what we’re dealing with.
June 2021, submitted a job request to create a script so that the bullet in brackets placed at the beginning of a paragraph text can appear in the left margin. So we set up a markup page for visual reference and worked with Jamie to update the transform. And you can see right here what it looked like before. Hopefully you could see that.
So you had the bullet after the section number, the paragraph number, and it was kind of stuck there between that and the paragraph. Now you have it before the paragraph number, so a lot easier to see. It’s not hidden in the text. So really small type of deal, but important.
So we used to have to place it, place the bullet in the Word or PDF file before or after publishing. That was really time-consuming. So this automated feature, it cut in half the time it would normally have taken to create a page proof of the document, of this type of document.
So like I said, it was a small fix, but this is an important distinction that needed to be made in the document and enable us to more effectively present the document. So the committee was really happy about that, and Pat and Jamie worked in concert on that to help us.
Typefi and complex tables (12:57)
So, ongoing challenges, works in progress.
We have a tonne of tables in our documents. And the way that the authoring committees create those tables can just be convoluted at best. Cells within cells, tables within tables, equations in tables, pictures in tables. So like I said, they insist on certain things and we have to find that happy medium.
So especially with tables, we have these giant tables that can be eight columns in width, extend over several pages. And then, like I said, complex tables, that’s most of the tickets that we send to Typefi help involve those.
So one issue that we’ve had to address is being able to change a template to accommodate large amounts of information in a table. So rows may not break evenly when the table jumps, or a cell may have a certain amount of, several lines of copy in it, but only three show up. So that’s the one challenge.
That’s the one thing, one of the main things that we’re working with Jamie and the team on to get workarounds so we can publish, but also just to find a permanent solution.
So that’s the skinny on API’s work with Typefi. We really appreciate all the help we’ve gotten and we want to really continue the relationship in the future. Thanks.