The Top Things I'd Like To See In Scrivener 3

Okay, I’ve been using Scrivener (and loving it) for several weeks now, getting used to it, discovering what it can do. I initially made a bit of a fool of myself by posting a list like this without truly trying to discover the program first, and thus wound up as coming across as silly; not to mention, the things I was requesting were way outside Scrivener’s area of focus, and would’ve taken hundreds of single-developer man-hours to fully realize. Now, though, it’s a bit of a different story. While I don’t know everything that Scrivener can do yet – I suspect that would take months – I’ve nonetheless come up with a list of things I’d like to see in Scrivener 3, or a future update of 2. I’ve tried to be realistic with regard to Scrivener being the (rather incredible) work of a single individual – i.e., I tried to avoid feature requests that would take oodles on oodles of man-hours to make work. Then again, I’m not a developer, so I’m really just sort of guessing when it comes to the under-the-hood complexity of these things. Anyways, here’s the list. I’ve tried to describe the way I see these things working in my head, though again, I’m not sure how far that goes toward my understanding of their underlying complexity or the specific challenges of implementing them.

  1. Wildcards and basic RegEx support. I would love to be able to construct regular expressions and use them in the search-and-replace dialog (along with wildcards), as well as the “Import and Split” dialog, and pretty much anywhere else Scrivener wants me to input a line of text. This would be a HUGE improvement, and one I salivate over the possible uses of. That’s why it’s #1 on the list!

  2. Combining “Search and Replace Styles” with “Search and Replace” and adding a few new features: I would love to be able to search for the phrase, “Dogs are nice”, bold, italicized, twelve-point, indented, and with a paragraph mark after it, and replace it with “Cats are cool”, underlined, ten-point, not intended, and with two paragraph marks after it. This would be an ENORMOUS boon to those of us working on large and complex documents with lots of sensitive formatting.

  3. The addition of “Import” and “Import and Split” to the right-click menu that pops up for items in the Binder.

  4. A quick reference guide to all the various <$variables> that Scrivener uses.

  5. A Slightly-Improved Compile Presets Management – Right now, we have to click on Compile, then set up our various options, then click the Presets menu, then click on Manage Compile Format Presets, then click “+” or “Update,” then close the palette. So why not just add three little buttons to the Compile window – “Save as Preset”, “Update Preset”, and “Delete Preset”? (They don’t even have to be “text” buttons.)

  6. A Slightly-Improved Compile Workflow – Instead of having the Compile button bring up a modal dialog sheet with the process-terminal “Compile” command, why not have an entry in the “Project” menu called “Compile Settings,” which brings up a modal dialog, as before, but with a simply “OK” and “Cancel.” Once the options are set, the user can “OK” them and get back to work. When they’re done, they click on “Compile” in the toolbar, which takes their Settings and then runs with them. This would take the process of deciding a document’s final formatting and make it a part of the writing process. One could argue that Scrivener was designed to avoid doing just that, but then again, it could also be argued that Scrivener’s method of abstracting formatting from writing is, in and of itself, enough, and that the process of designing one’s final output should be a natural – yet separate – part of the writing process.

  7. A “De-Compiler”-style RTF Importer – Recently, I had a 600 page Word document that was broken into chapters (separated by page breaks), which were then broken into numbered scenes (separated by double carriage returns); I wanted a quick and easy way to import this into Scrivener and have Scrivener “understand” that a page break followed by the word “Chapter” meant “create a folder with the text after Chapter as its title”, and that two carriage returns followed by a number meant “create a document and put the text that comes after this into it.” Maybe this could be based on a reverse of the already-existing Compile process – that is, a page break means one thing, a single return means another, an arbitrary number of returns means yet another. It certainly wouldn’t be usable in every single situation, of course, but boy, would it certainly be AWESOME to be able to break down documents like this.

As someone who uses bibliographic software quite a lot I could imagine that no.4 would be hell to implement and destined to mushroom horribly. Sente has over 1,200 formats for various journals and so forth, and I can just imagine the queue of people asking why their particular formatting needs weren’t catered for (why have you got APA but not ZQX?). I think I’d rather see Scrivener stick to its core functions there, and use Sente or Bookends or Zotero (free) or some other dedicated bibliographic program. I’m not sure that tacking on a database for all the bibliographic information and all of the code for formatting the citations would be as easy as it might seem – but I’m not a coder. Then, of course, you would have to build in a web browser so you could get information from Google Scholar or wherever, and the code to extract that information … It seems like a lot of work for something that one can already get from existing programs, and could quite conceivably lead to a heavy workload in terms of support problems (why aren’t my authors formatting correctly? The ZQX format is wrong. Why are half the fields missing when I try to import my 5,000 references from an RIS file?) I think Keith would need to be a little mad to take that one on. Then again, he did go from teaching to coding Scrivener :smiley:

Cheers, Martin.

I agree with Martin, being one of those who’d never use such a set of features anyway.

Well, maybe so. I didn’t think of that. I had no idea there were so many formats! Then again, I’m a lowly undergraduate in English, and as everyone knows, for us English majors, the world ceases to exist beyond MLA and two or three other formats. Unless of course it’s something we really need. :slight_smile:

But I can see your point; that would be hellacious to code and maintain–and to debug, not to mention support. I didn’t think about the sheer scope and size of the backend needed for such a thing. Okay, I hereby redact my third request. :smiley:

Unless I’m misunderstanding your request, Scrivener already has a basic version of Feature Request #3. See section 11.1 of the User Manual.

I would love to see compilation available from the command line, so I could put it in a Makefile (which is how I get from .tex to .pdf).

Feature #4 is located in the Help menu (Help>Placeholder Tags List…) I only know this because I asked for the same feature. The patient Scrivener gurus pointed me to its existing location.