IEEE: Implementing an XML workflow in a Standards environment

PATRICK GIBBONS: Yeah, so, we've been working with eXtyles and Typefi for about-- I want to say about four or five years now. So I'm going to walk you through what we've been doing and how we got there.

So just a start of a little background. IEEE Standards Association-- we have over 1,100 active standards and publish about 120 per year-- anywhere from between 5 pages of content to 5,000 pages. But the average is about 100, and the vast majority are in Word. But there's a good number-- I'd say about 20% or so that are still-- at least page count wise-- that are still in FrameMaker. And we support over 500 working groups.

And we're not just a publishing department. My director likes to say that we're standards professionals who do publishing versus publishing professionals who do standards. We have to be very involved in the whole process of development. We have to check and make sure they're following the procedures and that they're using the correct terminology or for legal issues. So there's a whole lot more to what we do than just publish the journals.

We're not part of the larger IEEE Publishing Group. They have thousands and thousands of journals and transactions. But we do need to coordinate with them because we're both on the same IEEE platform, the IEEE Xplore, which is our online presence. And though we're a very small part of the IEEE published content, a lot of our stuff is pretty important. If you're distracted and want to look at your laptop or your phone while I'm talking, the IEEE standard 80211, the ethernet standard, it's made the Wi-Fi available for everyone to do that. So you can thank the IEEE for that.

So around-- I want to say around 2011, 2012 or so, the IEEE made a mandate that we needed to start providing XML simultaneously with our PDF content. They were going ahead. And on their dime, they converted our legacy content. But they wanted us to simultaneously deliver PDF and XML, so they could display HTML of our standards on the IEEE Xplore platform and also so that we would be able to develop apps and e-books and also data mine the content for internal use and maybe to even sell as IP outside-- it's yet to happen, but it could.

And while we're at it, we were hoping to reduce inefficiencies in our process-- be able to publish our standards quicker and to streamline our production and publishing process. This was a big challenge to us because the old way we used to do things-- which we really, really liked and were really very good at-- as has already been explained, we got a Word file from the working group. It came into the IEEE. And either an in-house editor or a freelancer would punch it up, fix the formatting, edit it, and then we'd get that final MS Word document, make a PDF out of it, send it off for conversion. And then we'd pretty much just tweak that final Word document and give it back to the group.

Everything was fine, but then we were told we needed to change the way we do things. So we thought while we were at it, if we're going to have to go to XML, why don't we do it right from the get-go.

And as we've talked about, the holy grail for everyone-- it's, of course, an XML first platform. And it just wasn't doable. This was in 2014. We looked into it. We actually spent a bit of money trying to develop something. But the more we dipped into it, the more the consultants said, "Wait, you do that? Oh, now you're doing that?" It just became more and more expensive.

The platform was very rigid-- way too rigid for our users. There's this saying we say in-house-- there's no standards in standards. You think that everyone is going to do things the same way and that they'll follow our rules. But everyone's got their own thing that they want to do, and it doesn't always fit. And you have to make allowances for that. Also, again, it was mentioned the inability to work offline was a big deal for some of our volunteers. We actually had some of our higher profile users take a look at the system, and they said, this just isn't going to work. And also returning a draft to them out of it was seeming to be impractical, and it was getting too expensive. We just kind of bagged the whole thing.

And that's where we met Bruce and Inera. And we've been using them for-- I want to say about four years now. And so we have a new way that we're doing things. It's invisible to the groups, which is nice. They still work in Word. This is only for Word. We still send out our FileMaker files for conversion. We don't have a solution for that, yet. But in Word, the groups still create their standard draft. It comes to us, and, to some extent, we do a little bit of reduced formatting, editing. And then it goes through the eXtyles system.

Some of the things that the eXtyles plug-in does for us-- it strips out all the fields and flattens everything. And it goes through, and it matches up the bibliographic references to Crossref and corrects them if they're not quite right. It tags them all. And it's colour-coded. It looks very nice. It lets you know exactly what you're looking at. It also tags all the cross-reference links. It also verifies the URL addresses to make sure that they're working and tags them correctly and whatnot.

And then we take that XML, and we send it to Typefi and make a really nice PDF out of it. And we also have to send the XML to Xplore, and they put it up on-- it's not there yet-- but it will be used for HTML on the Xplore system.

Now one thing that we're still trying to figure out-- one is how much are we having the freelancers and editors format the document? A lot of it gets taken care of in the style sheets, and you don't really need to have things look exactly right in the Word file. That's kind of a hard thing for people to wrap their heads around. And to a large extent, we're still kind of having them do a lot of that for another reason I'll get to in a minute. Also, there's other editing things, like the eXtyles will go through, and it'll find when you're not abbreviating a unit of measurement the right way. If you have centimetres spelled out, it will change it to cm consistently throughout the document-- that kind of thing. And that's something an editor typically does, but you don't really need that with the new processing.

The biggest hurdle that we're coming very close to solving-- working with Inera-- the Word file once it's done being processed by eXtyles is not really something we can give back to the working group. All of the cross-references are gone. Everything's been flattened. You can't really go back and link to them using the old Word methods for inserting cross-references So for now, we've kind of been working in parallel. We keep our Word document pretty clean, so that we can then send that back to the group. And we have to apply changes if they come up in between the processing of eXtyles. But, again, we've been working very close with Robin and Bruce. And we're very close to a solution, and I feel pretty good about getting there.

So we expected a lot of challenges in going to this system. Number one that people hate change. Like I said, we were a pretty well oiled machine. We knew what we were doing. We liked it. We didn't want to hear we were going to have to do something different. We were a little leery about the turnaround document, which has borne out to be a little bit challenging. The skills gap-- of course, you have to train everybody on how to use the new system. We were going to start having to pull out-- treat our figures differently. It used to be it's embedded in the Word file, make a PDF. Nine times out of ten it's fine, as far as we were concerned. There was also issues-- we had to deal with coordinating with the larger IEEE, particularly loading our documents in to Xplore.

Now, the unexpected challenges-- people really, really don't like change. I mean the resistance to some of this is-- it still, to an extent, exists. It's a whole different way of thinking of things. People are very used to seeing it look how it's supposed to look in Word. And it's very hard to get people to accept that, yes, this indent is off. It doesn't matter. We're not publishing this Word file. We're sending it through a style sheet and InDesign, and it's going to look fine in the PDF. Or you don't have to have a continued table header when your table goes to the next page. That's going to be taken care of. And you have to break people's habits of thinking of the final document as the Word document.

There's also issues with software-- the Microsoft instability. Any of you, if you're using eXtyles, are aware of a Microsoft update suddenly making things not work-- and everyone has to scramble to figure out how we're going to either go back to the last update or get a patch from Microsoft. So that's been challenging-- something we weren't quite ready for. And, again, we're getting a lot more involved in the figures. We never used to really be too concerned. But for the Typefi PDF, we need to get EPS files or TIFFs and also for Xplore-- I think that's more of an Xplore requirement. But we never used to have to be concerned about separate file figures.

And it's also for now, our time to publish has actually increased a little bit because people are still learning what they're doing and how to do it and how we're going to take care of some of these things. With time, I see that changing. But right now, we're still up a couple of weeks from where we used to be as far as our average time to publish.

And also the working groups-- believe it or not-- as nice as the PDFs look, they don't like to see something different than what they turned into us-- or why isn't this figure where I put it? Why is this table breaking? I don't want it to break. It's like, why are you worrying about it? Especially, when things are on HTML, you don't care about these things. So it's a learning curve for everyone involved. Overall, though, I think the benefits definitely outweigh the challenges.

We're up to 80% of our standards documents are now in the new workflow. And for our Word documents, that's 90% to 95%. So we're saving a whole lot on the outside vendor conversion. The PDFs look great. Images float better. There's less white space, the table breaks are nice. We get highlighted internal links, which is something we didn't have in Word. The figures look better because we're paying more attention to them and having them taken care of better. And we also now have the ability to take XML, create mobile apps, and do all kinds of things with it.

So that's our experience with the growing pains of implementing an XML workflow. I'm happy to answer any questions. I'm here tomorrow, too, if anyone wants to see some examples that I couldn't really show you. But that's all I've got, so thank you.

AUDIENCE MEMBER: Great to hear your input, but you mentioned something I would like to hear a few more words about. And that is your work with the graphics because now we're moving to vectorised graphics for everything. And have you provided additional staff to do work internally? And when you're talking about better looking graphics, what we're seeing a lot of times is that things are converted to the correct formats but that you actually have to do internal work to create the proper graphics.

And also in the formats used, we're all talking about using EPS, which is mainly a Photoshop product, whereas the dot Illustrator file is the real proper vectorised format that should be used if you're using Adobe format, or the dot SVG, which is a structurised vector graphic that moves us into a more flexible space. So what considerations have you done when it comes to graphics in terms of that?

PATRICK GIBBONS: As far as SVG files-- I'm not 100% on this-- I believe our TIFF/EPS requirement comes from Xplore. I'm not 100% sure on that. And I think there might have been an issue. I don't remember. I know there's a reason we're doing it. I don't remember what that reason is. As far as conversion, this is actually a slight added expense. We send a lot of our figures out to be redrawn, actually. So it's not just a matter of upgrading the file format. We actually have a lot of them redrawn if they're in really bad shape.

AUDIENCE MEMBER: Third party or internal?

PATRICK GIBBONS: Third party. Yeah, we don't currently have internal staff to take care of that.