One of the things that makes Scrivener very different from other writing tools is that it has a very strong, and very non-standard, set of principles that guide how it is developed and used.
-
Assembling a larger document from a collection of smaller documents. This is core to the whole Scrivener experience. It’s not a monolithic document like a Word document. It’s a collection of small documents that you can easily add, remove, move, edit, change, search, label, add keywords, group into Collections, take snapshots of, and generally work with as you see fit. During compile time, Scrivener will stitch your selected documents together for you according to the compiler configuration you have designated.
-
Divorce the working format (what the writer sees) from the final format (what the Compiler produces). When we as writers create documents, we usually are not creating them in a void. Our output goes to someone else’s desk as input, in many cases. That input has specific requirements about how it must be formatted – standard manuscript format, standard script format, PDF, Epub, etc. Yet forcing writers to think about that final format during every stage of the writing process creates inefficiency – AND actually makes it harder for writers with disabilities. If I have vision problems, having to look at 12-point Courier (or variant) all day might be very difficult. With Scrivener, I can separate the formatting I use while writing (to something larger, in a soothing color, in a very personal typeface) from the format the Compiler will apply to the finished document (standard manuscript format – nobody needs to know I wrote my story in 30 point pink Comic Sans).
-
Allow the user to retrieve their data using standard tools if something goes wrong. This is why Scrivener’s file format looks like a folder with a bunch of RTF and XML files – because that’s exactly what it is (although on MacOS this is abstracted out to what is called a “package file”) and that is a good thing. If something goes wrong, you don’t need Scrivener – you can use your file explorer and local RTF editor to retrieve your data.
And you don’t have to like Markdown, or ever use it, in order to use Scrivener. But those who do prefer it can use an optional set of Compilation configuration to run their document through markdown, Pandoc, LaTeX, or other post-processors that they have configured to apply their preferred final format automatically.
Ah, but you wouldn’t necessarily send them the raw Scrivener project. You’d Compile it first…and the compile configurations you’ve selected would take care of applying the proper formatting.
According to its core principles, Scrivener is not a word processor. While there is overlap in functionality, there are things you would do in Scrivener that you can’t do in a word processor, and vice versa. Scrivener specifically was designed to not use WYSIWYG as a core design principle. If that’s what you need, there are other writing tools out there that provide that facility.
One of the most common complaints I’ve run into using Word over the course of my career is how fragile Word documents are. It was much worse until Microsoft upgraded to the .DOCX format – I was writing documents for the Office group at Microsoft in .DOC format that would regularly get corrupted and nobody there could figure out why. When working with specialized templates that pre-provided every style they would ever need, writers would still manually format sentences or parts of sentences instead of just applying the proper styles. They couldn’t help themselves. Over the lifecycle of the document, those portions of the documents would cause more and more problems until someone ended up having to strip out all the text in that area into Notepad, then put it back in and re-apply the styles. And hope they’d gotten it right.
The point is, there is a large population of people who are willing to sacrifice some level of stability in their document in order to have total control over how it looks at all stages of its lifecycle. There is also a large population of people who want their tools to enforce a separation between the structure of the document and the final formatting of the document. Scrivener is written for that latter population – and if that doesn’t include you, then you may not be in the target population for Scrivener. (And that’s not a bad thing and definitely not an attack – I’ve tried a bunch of software over the years that worked in ways that I just couldn’t or didn’t want to get used to!)
But they’re not working without formatting. They’re simply applying the formatting at a different stage of the process, and they’re trusting in the computer – an automated process – to uniformly apply the correct formatting based on the hints they’ve given in the text.
Do have a care here, please. There is a difference between having a strongly held belief because you’ve worked through the alternatives and being closed to other beliefs without having considered them. Many of us in the Scrivener camp are here precisely because we came through the wilderness looking for a program that did things in a different way.
So the same with computer software. Scrivener does not enforce its principles across all writers, only on those who accept them. Would it not be dogmatic to force one’s choices of how a particular software package should work on others, especially when there are already so many packages that do work more in that fashion already?