Why We Built Styleworks
By Tom Waddell, Chief Engineer
I knew that, at the end of this conference session, I had five minutes to tell people how to automate their style sheets with PerfectIt. I also knew that it wouldn’t be enough.
We spent the session learning how to craft beautiful style sheets. What information to consider including, what decisions to log, how to use this document as a communication tool with our authors. We learned how to create a fantastic resource, both for us and for others in the publication process, and I sat there with a horrible feeling in the pit of my stomach. I knew I was going to have to tell everyone they needed to start all over again if they wanted to use automation tools to help make the manuscripts they were working on consistent with the language decisions they had made while editing.
After I had given a whistle-stop tour of how to cram as much into PerfectIt as possible, it occurred to me that this was a great parallel to the editing process itself. We spend most of our time editing and logging the decisions in our style sheets and simply don’t have time at the end of projects to write that all out again for automation. This got me thinking:
What would it be like if you only needed to create one style sheet that could be used both as the written record and for automation?
Styleworks is the beginning of that vision.
The quiet role of the style sheet
I have a simple rule when attending editing conferences. Attend at least one talk on an area of editing I know little or nothing about. Over the years I have learned about all sorts of interesting topics, from spotting continuity mistakes in crime novels, to how to edit knitting patterns and cookery books. And in most of these sessions, waiting in the wings, ready to leap out and save the day, is the wonderful tool that is the style sheet.
Often mentioned, and invaluable to editors in all disciplines, the style sheet can act as editorial memory. As editors work through a document, they start to notice patterns. An author prefers toward rather than towards. They use hyphens with the prefix anti. They capitalize certain internal terms. They avoid the Oxford comma. None of these are universal truths, they’re simply choices. And as editors discover those choices, they jot them down in their style sheet, so they don’t have to rediscover them later.
That’s important for consistency. But it also serves another purpose that’s easy to overlook: It helps the editor avoid imposing their own preferences. If the author consistently prefers one form over another, the editor records it precisely, so they don’t overwrite it later. The style sheet becomes a way of protecting the author’s voice from the editor’s habits.
Where the friction appears
But there’s a limitation in the traditional workflow that editors have quietly lived with for years.
The style sheet is where decisions are recorded; it doesn’t apply them. You write down the preference, but you still have to remember to check it. You run searches, you scan manually, you build find-and-replace wildcards if you want help catching variations. None of that is particularly difficult. But it is repetitive. The editor ends up doing the same work twice: once when recording the preference, and again when preparing it for automation software. Who has time to duplicate that much work for every project they work on?
Also, when preparing those preferences for software you have to do so in a different format, designed for automation. Automation tools typically work “error first”: They need to know what the incorrect form looks like so they can flag it. That’s a lot of mechanical work. And the result is two different representations of the same decisions: one for humans, another for software. So now the same knowledge exists in two places.
If you are maintaining a house style, the two copies can gradually drift apart. Editors update the written version but forget to update the automation rules, or the automation rules evolve separately. To keep the system consistent, every change means updating both. For a long time, we simply accepted that as part of the process.
But then we started asking a different question.
What if recording a preference also prepared it for checking?
As I stood there mildly panicking about the prospect of explaining to editors how to build their style sheets for a second time so that software could use it, the question kept nagging at me: Why are we asking people to do this twice?
As a developer, that immediately felt wrong.
In software development we have a principle called DRY: Don’t Repeat Yourself.
Why were editors being asked to maintain two versions of the same knowledge? That’s like having to make the same sandwich twice before you’re allowed to eat one of them. If the style sheet already records the decision, why shouldn’t that same record be the one the software uses too? Shouldn’t the human-readable document be the single source of truth?
That’s the big idea behind Styleworks.
Instead of writing patterns or technical checks, you simply record your preferences in plain editorial language. Styleworks then prepares those preferences for PerfectIt so that you can check them when you’re ready to run a final consistency pass.
Language is hard
From a technical perspective, the hardest part of building Styleworks wasn’t the checking itself.
PerfectIt has been checking consistency for many years. The challenge was translating editorial preferences into something software could understand. Language is hard. Preferences often imply multiple variations. A single preference may involve plurals, verb forms, hyphenation patterns, or capitalization differences. Editors handle those variations instinctively.
Software needs them to be defined explicitly. For example, if a style sheet simply records the preference “color”, an editor immediately understands what that implies: avoid “colour”, apply the spelling to plurals, and use the same pattern in related forms such as “colored” or “colorful”. The word “color” in a document can also imply other “or” endings such as “flavor”, “harbor” and many more.
Automation software can’t make those assumptions. It has to be told explicitly what to search for and what to replace: essentially a long list of “find this, change to that” rules.
A large part of the engineering work behind Styleworks was getting the software to bridge that gap automatically, allowing editors to record a preference once, while the software quietly prepares the variations needed for checking later.
What this opens up
Styleworks is still early in its development, but it opens the door to an interesting shift in how style sheets can function.
Traditionally, a style sheet is a record. It captures the decisions an editor has made so those decisions aren’t forgotten. But the style sheet itself remains passive. It documents the preferences, while the editor still carries the responsibility of applying them consistently throughout the document.
What Styleworks begins to change is that relationship. When editorial preferences can be captured in a single place and reused more easily, tools can begin to support that work more directly. The style sheet remains the place where decisions live, but the editor no longer has to carry the full burden of applying those decisions alone. Consistency no longer relies entirely on memory and vigilance.
This is the opposite of replacing editorial judgment; it’s protecting it by giving editors tools that enable their decisions to be applied consistently.
Styleworks grew out of a simple realization: Editors don’t have time to do the same task twice. I’ve spoken to many editors who have never created a custom style for PerfectIt simply because it takes too much time.
The conference session brought this home to me because it reflected exactly the same problem. We spent most of our time discussing style and recording editorial decisions, then squeezed automation into the final five minutes. That's exactly what happens on many editing projects. The style sheet is built throughout the work, capturing all the important decisions. But the extra task of turning those decisions into something software can use is too time consuming.
Styleworks was built to solve that problem. Instead of rebuilding your style for automation, you simply record the decisions you're already making, and Styleworks prepares them for PerfectIt automatically.
Try Styleworks for free and let us know what you think. We'd love to hear how it fits into your workflow and what we could do to make it even better.
Tom Waddell
Chief Engineer
Since joining PerfectIt in 2015, Tom has led his team’s transformation of PerfectIt from a niche add-in to a tool that’s used by tens of thousands of professionals around the world.
Tom’s skill is in listening to editors and building for the needs of language professionals. With the launch of Styleworks, he’s introducing a new way of working with styles to the editing community.