Scrivener 3: Linguistic Focus

Note: This blog post pertains to upcoming features in Scrivener 3, which will be released on macOS later this year and will follow on Windows some time in 2018.

As Scrivener’s name generator has been such a boon to those struggling to name the arch-nemesis of their main character, or any other character for that matter, we’ve added another writing tool into Scrivener 3. It’s called Linguistic Focus. (Dialogue Focus on Windows.) Attempting to see the dialogue within a wall of text, select ‘Direct Speech’ and suddenly all those spoken exchanges jump out of the page:

This is a great way of checking the flow of your dialogue and ensuring each of your characters has a unique voice. The macOS version of Scrivener 3 will also be able to highlight syntax elements such as nouns and adverbs thanks to a built-in feature of the underlying text system on a Mac.

So, if you suddenly want to skim over your preposition and conjunction usage, or check to ensure you’re using the best adjective in the given context, it’s only a selection choice away!

You’ll be able to find this new feature via ‘Edit > Writing Tools > Linguistic Focus…’ on Mac, and ‘Tools > Writing Tools > Dialogue Focus…’ on Windows.

Let Me Count The Ways

Note: This blog post pertains to upcoming features in Scrivener 3, which will be released on macOS later this year and will follow on Windows some time in 2018.

We get that you’re swamped (probably not as badly as Prince Humperdinck, but you’re definitely busy), so you want to keep track of every word in every which way that you can. Nothing screams progress like a hefty word count for the day, or even a resplendent negative session count when you’ve been editing. Scrivener 3 has built on everything provided by earlier iterations, even retuning a feature that was taken away, and then some.

Tweeting your project targets is back! Nothing keeps you honest like telling every follower you have how many words you’re intending to conjure up that day. A representation of your project targets window is now even included within your tweet:

Individual document targets remain, and if you go to ‘Project > Statistics…’ you can glean a wealth of information like word, character and page counts, reading time, and the frequency of particular word usage for your draft or selected documents. You can now create a list of words to ignore within word frequency reporting.

Select any area of text within a document to receive word and character counts, or choose multiple documents within your binder to get a combined count. Outliner mode then offers column options that will keep count of individual documents or groups of documents, whilst giving you an instant visual snapshot of the progress towards any specified document targets. You can even configure notifications to give you a prod whenever you’ve achieved any of your set goals.

Working to a deadline? Plug the submission date into Scrivener and the application will calculate the writing session target you need to achieve each day in order to reach your required count! (This has been a feature of Scrivener on Mac for a while, but it will be new to Windows users.) If you only write on certain days of the week, let Scrivener know and it will adjust your session count accordingly. If you miss a day, or happen to overachieve, Scrivener will continue to specify the number of writing days remaining, and recalculate on the fly what you need to write each day in order to hit your deadline.

Scrivener 3 brings something entirely new too. Writing history. The top section of the screenshot below provides an overview of the project as a whole. 228 different days have been spent labouring over each syllable in the project. An average of 391 words were written in the draft section each day, whilst 988 words went towards preparatory material and notes.

June was a prodigious month. 61,003 words written in the draft, averaging some 2,346 words per day, writing for 26 days out of the 30 available. Detail for each and every day is available to me, and thanks to some forward planning, even though Scrivener on iOS was released during July 2016, any writing completed on your iOS devices within a Scrivener 3 project will also be included within your writing history statistics. Furthermore, all this data can be selectively exported as a CSV file, so you can analyse it in as much detail as you desire using the spreadsheet application of your choice.

With the incept date for Scrivener 3 on macOS approaching, we can now look back at Scrivener 2. It was made as well as it could have been. “The light that burns twice as bright burns half as long – and you have burned so very, very brightly…” As mentioned previously, Scrivener 3 builds on everything that Scrivener was before, but lays its foundations in a 64-bit architecture on Mac ready for another generation of writers. Your words matter, and they’re being counted.

Scrivener 3: Copyholders and Layouts

Note: This blog post pertains to upcoming features in Scrivener 3, which will be released on macOS later this year and will follow on Windows some time in 2018.

Ever since Scrivener 1, you have been able to split Scrivener’s editor in two and view two documents alongside one another. In Scrivener 2 we added a new feature which is often missed: the ability to have one editor control the other. So, if you have the corkboard in the left editor, for instance, you can click on the “Automatically open selection in other editor” button in the footer bar (the button showing an box icon with an arrow pointing out of it). With this turned on, selecting a card in the corkboard (or a row in the outliner) causes the document associated with that card (or row) to be opened in the other editor. This added more flexibility to how you could use the two editors.

Ioa recently wrote a blog post on the new bookmarks feature in Scrivener 3. This provides an additional way of referring to documents and research in your projects, because you can now view bookmarked documents right in the inspector. There’s another place you can open documents, too: in Copyholders.

Copyholders

The ability to split Scrivener’s editor in two is very useful. But why only split it two ways? What if you want to refer to more than two documents at a time (or more than three if you’re using Bookmarks)? One problem is the relationship between the two editors: “Automatically open selection in other editor” makes sense if there is one other editor, but no sense if there are several. Likewise, by default, clicking on an internal link causes it to be opened in the other editor—if there were several other editors, you’d have no idea where it would be opened. For Scrivener 3 we wanted to make it possible to split the editor more ways, but without causing the confusion that would ensue with multiple full editors. The solution we came up with we call “Copyholders”.

In the real world, a “copyholder” is a small stand to which you can clip documents in order to refer to them as you write or type—and that’s exactly what Copyholders are in Scrivener, too. In Scrivener 3, both editors now have a Copyholder available. A Copyholder is essentially a subsidiary editor that appears inside the existing editor and which can only show single documents (so it doesn’t support corkboard, outliner or Scrivenings modes). Other than this limitation, copyholders are full editors in their own right, allowing you to view and edit text or look at research files.

To open a Copyholder, you simply drag a document from the binder and drop it onto the editor’s header bar holding down the Option key. (You can also use the Navigate > Open menu, but dragging is fastest.) Below you can see a Copyholder has been opened in the right editor, showing an image of a sunset:

Copyholders therefore provide a great way of referring to more documents at once, but their usefulness doesn’t end there. We’ve extended the “Open selection in other editor” feature introduced in Scrivener 2 so that it can now affect Copyholders. Supposing you have both editors open; one editor is showing the outliner and it has a Copyholder below it:

  1. Clicking on the “Open selection in other editor” button in the outliner footer bar works as before – the icon turns blue to indicate that the feature is active and selecting documents in the outliner will cause them to be opened in the other editor.
  2. Clicking on the button again, though, will cause it to stay blue (on) but the icon will change to indicate that the selection will now affect the Copyholder. So now when you select items in the outliner, they will be opened in the Copyholder instead of in the other editor.
  3. Clicking the button a third time turns it off again.

This makes possible one of my favourite new setups in Scrivener 3. Here’s how I’ve been setting things up:

  1. I split the editor vertically.
  2. In the right editor, I load up the outliner, showing the contents of a folder containing lots of research or notes to which I want to refer while I’m writing.
  3. I Option-drag one of these notes onto the outliner’s header bar to open it in a Copyholder below the outliner.
  4. I click twice on the “Open selection in other editor” button in the outliner’s footer bar so that selecting documents in the outliner will cause them to be opened in the Copyholder below it.
  5. I lock the outliner editor, so that clicks in the binder will not affect the outliner editor even when it is focussed. By doing this, the binder will always affect the left editor.

This results in a dual navigation UI:

Now, whenever I select something in the binder, it opens in the left editor, no matter what. When I select something in the outliner, it is opened in the Copyholder below it. It’s a fantastic way of referring to a bunch of notes and research on the right side of the interface while writing and creating new content on the left. It’s probably the new feature I have used most.

Layouts

Perhaps that five-step sequence above seems a little too much effort—after all, you’re in Scrivener to write, not play around with the settings. Moreover, Scrivener has a tonne of useful features like this that many users may never discover. We think the dual navigation feature is so useful that we want to make it easy for users to access. To this end, we’ve added several default Layouts that you can choose from the Layouts menu, or from the leftmost toolbar button, and these include the “Dual Navigation” setup:

You’ve been able to create your own Layouts (a way of returning to a particular UI setup with one click) ever since Scrivener 2, but these default Layouts provide some out-of-the-box UI setups that we think will be useful to many users. So instead of following the five steps above, you can simply choose the “Dual Navigation” Layout and all of those steps are done for you. When you’re ready to return the UI to regular navigation, you can choose the “Default” layout (or “Clear All Navigation Options” from the new “Navigation” menu).

Here’s another Layout I think a lot of users will find handy—the “Three-Pane” layout:

And—another favourite of mine—the “Centered Outline” layout:

So, Copyholders provide even more possibilities when it comes to referring to your notes and research, and the new built-in Layouts make it easy to switch between some useful UI setups with just a single click. These are just two of the ways in which we hope Scrivener 3 will prove both more powerful and yet simpler at the same time.

Here, There and Everywhere

Note: This blog post pertains to upcoming features in Scrivener 3, which will be released on macOS later this year and will follow on Windows some time in 2018.

With the rise in popularity of web searching, and similar tools like Spotlight on iOS and macOS, we’ve grown accustomed to the concept of not only finding things by searching, but interestingly so, using that mechanism as a principal means for navigating to things we already know about. You may have seen an article or two demonstrating how Google has for many become a shortcut in getting to other websites without having to key in a URL or find a bookmark for it. And on an iPhone or Mac, how often have you used Spotlight to load an app or document, rather than hunt down its icon so you can double-click or tap on it?

Wherever we find a sea of things flooding the ordinary routes in navigation there seems a clear tendency toward searching as a means of cutting through the data, straight to what we were looking for. Over the years my own use of Scrivener has been shaped by this tendency, even though there was never a dedicated way of doing so. Project search worked, but could be disruptive if the sidebar was already in use for another purpose.

Scrivener 3.0 takes the concept of searching as a form of motion, and puts it at the very top of the application, literally in fact.

Quick Search shows you where you are, and gives you a way of getting to where you will go next.
Quick Search shows you where you are, and gives you a way of getting to where you will go next.

If it looks a little bit like a URL bar in a browser, you wouldn’t be far off in that assumption. When not in use, it merely displays where you are, but when you click into it (or use the keyboard shortcut, Ctrl-Opt-G on the Mac and Ctrl-Shift-G on PC), you can type in a bit of the name of the thing you’re looking for and get a list of search results, narrowed down as you type, from anywhere in the project. Arrow down to the precise thing you’re looking for (or if it happens to be the first result you don’t even need to do that), punch the Return key and it will load into the active editor. You can also click straight on the result you want to load.

That right there will be enough for most things you’d need such a feature for, but true to form, we’ve packed a lot of extra capabilities into it. Let’s start with a few simple additions to the Return key or clicking with the mouse:

  • With the Shift key the search result loads as a Quick Reference panel. This is the least disruptive way to reference a document, as not a single thing changes in your project window using this route.
  • With the Opt/Alt key the result loads in the other editor split, creating one if necessary. That means you can look up reference material while in the middle of typing a word, and once you’ve loaded it in the other split you’ll be able to finish typing that word without missing a beat.

Not a fan of toolbars? We’ve got you covered. When the Quick Search tool isn’t available the keyboard shortcut will bring up a floating search tool that provides all of the above and dismisses itself cleanly when you hit Return, Esc or click on a result. Just like Spotlight.

Bring Out the Mouse

Searching isn’t solely about reading or editing things. Often we search with the intention of doing something with the things we find. To that end, every entry in the search result list can be dragged and dropped—and doing so will be just like dragging and dropping that item from the binder. Turns out you can do an awful lot with a mere search result!

Drag any search result in the list into the project window to do a variety of things with it.
Drag any search result in the list into the project window to do a variety of things with it.

Working counter-clockwise through the thicket of arrows above:

  1. Assign the selected document to a collection by dragging it onto a tab in the collection tab list, or right to the correct spot if the collection is open in the sidebar, corkboard or outliner.
  2. Drop into the binder, corkboard or outliner to move the document to the dragged location. This even works with the new label view, discussed by Jennifer in an earlier post. Yes, you can move a search result and label it in one move.
  3. Or with the Alt/Opt key held down: copy it somewhere else (an optional capability).
  4. Drag into the text editor to create a link to it. (Or if it is an image, to place the image, which I just did a few seconds ago, above.)
  5. Or with the Alt/Opt key, paste the contents of it into the editor. (Great for making little starter chunks of text, like tables you’ve already formatted. Rather than making one from scratch, look up your boilerplate and drop it in.)
  6. Bookmark it, either as a project bookmark or to the document you are editing. You can even drag it to the Bookmark toolbar icon to make it a project bookmark without any further ado.
  7. Drop onto any header bar to load it there. We’ll be talking about another thing you can do when dropping items on header bars with the Opt/Alt key later on. I’d mention it now, but no spoilers!
  8. Drop on the Quick Ref icon in the toolbar to load it as Quick Reference window. (This one doesn’t have an arrow.)

You may also note, if you squint at screenshots like I do, that we don’t stop at titles. Nearly the entire project is scoured for the text you typed in, so if you don’t quite remember the name of a thing, you might still find it via a snippet of text, or a note you jotted down on an index card. If all else fails you can click the “Full Project Search” button at the bottom, and witness the firepower of this fully armed and operational battle… wait, that’s the wrong speech.

Keeping Tabs Without the Clutter

As we looked at other similar tools, like Safari’s URL bar, we noticed more was being done with them than purely giving you a place to type or reference which site you’re on:

We liked the way Safari drew progress bars enough to use the idea for showing your overall progress on the draft target, along with your daily session target. So not only does Quick Search, well, search, it also functions as an embedded and steady monitor of your writing progress (should you set goals). The design fulfils a longstanding request we’ve had to embed this information somewhere readily available in the main window. Now instead of having to leave that Project Targets panel open all day, you can keep an eye on how the word counts are coming along with a low-key progress bar, right above where you type.[1]

You can also mouse over the tool to get a numerical read-out of the draft and session word count, and leave the mouse there to keep that information up instead of the name of the thing you’re editing.

Keep track of how far youve come with a glance.
Keep track of how far you’ve come with a glance.

Don’t worry, if you’d rather be kept in the dark while you write, you can turn this display off in settings. And you can change the colours too. This is Scrivener after all.

All told Quick Search (and Writing Progress) is a simple tool, but with enough flexibility to it that it has rapidly became an indispensable ingredient in how I locate, organise, compose and assemble text on the fly. And it is just one of the many ways we’ve thought about navigation and workflow in Scrivener. We’ll have more to discuss along those lines in a future article.


  1. The floating window is still there if you want it, and remains what you’ll use to set targets and thus activate this part of the feature.  ↩

Epub, Kindle and MultiMarkdown Export in Scrivener 3

Note: This blog post pertains to upcoming features in Scrivener 3, which will be released on macOS later this year and will follow on Windows some time in 2018.

Additional note: This blog post specifically relates to the development of the macOS version, but the improvements that resulted from this development are coming to Windows too.

One of the many areas of Scrivener I wanted to improve for version 3 was its Epub export. Scrivener 2.x creates Epub 2 files, even though the latest Epub specification at the time of writing is 3.1. Moreover, internally those Epub 2 files are a little messier than is ideal. An Epub file is essentially just a zip package containing a bunch of HTML, CSS and XML files (CSS files define the formatting used in the HTML). Scrivener 2.x creates a separate CSS file for each HTML file in the book (when it’s better practice to create a single CSS file that is used by all of the HTML files) and the HTML is a little messy.

Ordinarily, the internals of an Epub file shouldn’t worry anyone except for those who are passionate about parsimony—the most important thing is that it looks as it should on e-reader devices. However, the use of multiple CSS files has a deleterious effect on Kindle files. When you export a Kindle .mobi file from Scrivener, it is constructed using the same code as Epub export, and then converted to Kindle format using Amazon’s KindleGen utility. Scrivener-generated Kindle files look great on Kindle devices, but they don’t work so well with Amazon’s “Look Inside” feature. This is because a bug in Amazon’s “Look Inside” feature means it takes formatting from only the first CSS file in the book, regardless of whether or not it’s the one that’s supposed to be used for the text being displayed. This can result in the text using the wrong formatting—not a great introduction to your book for the reader!

All of these issues originate from a single cause: the HTML generator that Scrivener 2.x uses. To create ebook files, I have to convert the rich text in Scrivener’s editor to HTML format. Apple provides an HTML converter built in to the text system, so I have always used that. However, Apple’s converter only supports HTML 4 (whereas Epub 3 requires HTML 5), it produces rather messy HTML with a lot of cruft, and I have very little control over it (there’s no way of setting it up to use a single CSS for multiple output files, for instance).

For Scrivener 3, then, I needed to find a way of converting Scrivener’s rich text to HTML 5, and I needed more control over the HTML generation. I began by hunting high and low (sing: there’s no end to the lengths I’ll go to) for a third-party converter, but there is very little out there in the way of third-party converters that work with Apple’s text engine. I considered writing my own converter from scratch, but that would be a mammoth undertaking that would require regular maintenance.

The solution? MultiMarkdown. MultiMarkdown can already convert text to HTML 5, and it does so cleanly and allows a great deal of control and flexibility.

The problem? For MultiMarkdown to convert text to HTML 5, the text has to be written in MultiMarkdown syntax—that is, with asterisks denoting bold and italics, pipes and dashes representing tables, greater-than symbols representing the start of block quote paragraphs, and so on. You can’t just pipe rich text though MultiMarkdown and have it come out with the formatting intact.

The solution to the problem with the solution? I spent a couple of weeks writing a full rich-text-to-MultiMarkdown converter. This takes a rich text document and converts it all to MultiMarkdown syntax: bold, italics, footnotes, tables, lists, block quotes—the works. With that in place, to generate an Epub 3 file or an improved Kindle file, internally I could convert the rich text to MultiMarkdown and then the MultiMarkdown to HTML 5.

The result of all of this work is this:

  • Scrivener 3 can export to Epub 3 format.
  • Its Kindle export is also much improved, and should now work fine with Amazon’s “Look Inside” feature.
  • The internals of Epub 3 and Kindle files are tidier, containing only a single CSS file.
  • In Compile, you can optionally override the CSS that is generated. This means that those with experience in CSS will be able to add features such as drop caps (although not many e-readers support that yet) or anything else that CSS and e-readers support.
  • In Scrivener 3, as a nifty side effect of all this work, you can export to any MultiMarkdown format even if you don’t write using MultiMarkdown syntax: you can simply tick a checkbox and have all of the rich text converted to MultiMarkdown during export.

Compiling an Epub 3 file relies in large part on Scrivener 3’s new styles feature—for block quotes and other formatting to appear as expected in the exported ebook, you’ll need to apply styles to the text (something not available in earlier versions of Scrivener). To make the transition to Scrivener 3 as seamless as possible, for the time being it will offer the ability to choose between Epub 3 and Epub 2 export (and between older and newer versions of the Kindle export). This means that you won’t have to worry about updating the text in existing projects to use styles just to get it to work with Epub or Kindle export—you can continue to use the older exporters until you’re ready to update your text or start a new project.

Scrivener 3: Redesigning Compile

Note: This blog post pertains to upcoming features in Scrivener 3, which will be released on macOS later this year and will follow on Windows some time in 2018.

Scrivener’s Compile feature is powerful and adaptable, but it also seems to be a stumbling block for many users. Whenever someone describes Scrivener as “complicated” and we ask which areas they mean in particular, Compile is usually the first thing mentioned.

There’s a certain degree of necessity to Compile’s complexity (bear with me on this). When I set out to create Scrivener—well over a decade ago now—one of the most important goals for me was that it had to be flexible. I had tried all manner of apps aimed at writers. Back then, most specialised writing apps outside of word processors were built around a particular paradigm. Some wanted you to follow a set story structure, such as Vogler’s 12-step hero’s journey. Those that weren’t built around a popular narrative theory forced a particular structure on you: three acts, each containing several chapters, for instance. Copywrite and Ulysses came the closest to doing anything like what I wanted to do (in that they allowed you to break a larger manuscript down into smaller components without an imposed structure), but they didn’t provide any way of organising the sections of your manuscript into an indented, outline-like arrangement.

What I wanted was to be able to define my own structure, which would be different depending on the project, and to be able to reshape that structure as and when needed. Maybe I’d work in parts, chapters and scenes; maybe I’d only need chapters and scenes, or only chapters. For nonfiction I might organise things differently again. To this end, I built Scrivener around the core concept of a flexible outline—the binder. In the binder you can create folders and text sections and organise and nest them however you want.

Another of my aims was to allow the user to write using any formatting he or she wanted, and then to allow all of that formatting to be changed (optionally) at the export or print stage. So you could write in your favourite font but still output to standard manuscript format.

These two core aims come together in the Compile feature, which takes all of those separate, structured sections and sews them together into a single manuscript, overriding the formatting depending on the output requirements.

The problem we’ve always faced is that these two aims—complete flexibility of organisation and the ability to stitch everything together into formatted documents with specific requirements—are, to a certain extent, at loggerheads. If an app knows that you are writing in parts and chapters, it can provide an export that formats the text accordingly. But if you can structure your manuscript any way you like, when it comes to creating the final document, how can the app know which sections should be formatted one way and which another? How does it know that, say, in Project A, this folder is supposed to be the title of a part, this folder is supposed to be the title of a chapter, and this text document is a scene? Or, in Project B, this text document is a preface but these text documents are chapters, and should be formatted as such?

This has always been the huge challenge underlying Compile, and it’s the reason it has always had a degree of complexity to it: it needs to provide options that allow for any number of possible project structures, along with the ability to format those projects for many different requirements.

For Scrivener 3, we wanted to rethink how we approached this problem. I’m not going to pretend that the solutions we have come up with will mean that you never scratch your head over a Compile option, because there’s no perfect solution (barring machines becoming conscious, in which case I hope Skynet sends back a T-900/715 rather than a T-800/101 to help me, but we’re getting sidetracked). I do hope that Compile in Scrivener 3 makes a lot more sense to people, though.

Compile in Scrivener 2

There are two aspects of Compile that, I think, cause confusion for a lot of people. The first is simply the way we throw all of the Compile options right in your face.

We tried mitigating this a little by adding a “Summary” mode, but generally you need to switch to “All Options” as soon as you want to tweak anything, so most users end up faced with the full gamut of Compile options anyway. These options are powerful and give you complete control over your manuscript, but they are also a little intimidating if all you want to do is change which documents should be treated as chapter headings.

The other source of confusion is the way Compile formatting is applied to the sections of projects. This is all set up in the “Formatting” pane—where you tell Scrivener to show a title for this chapter, insert a “Chapter [Number]” heading for each of these folders, and change the text to Papyrus 16pt for these sections (this is a joke: please under no circumstances use a Papyrus font, unless that circumstance happens to be that the T-900 sent back in time for you accidentally zapped you back to 1997 and now wants you to design the front of a vegan friendship bracelets shop).

The confusion arises over how, in the “Formatting” pane, you have to think in terms of “levels” in the current project outline, like this:

In this example, formatting set up for “Level 1” folders in Compile will be applied to the “Part” chapters in the binder, formatting for “Level 2+” folders (the “+” indicates that this formatting will be applied to level 2 folders and deeper) will be applied to the “Chapter” folders, and formatting set up for “Level 3+” text will be applied to the scene documents.

This is actually a pretty good solution, because it allows you to define how your manuscript should look based on its structure. However, over the years of use and user feedback, we’ve thought a lot of about its limitations:

  • Setting up the levels in Compile like this ties each Compile format to a particular project structure.

  • It’s difficult to have different formatting for the same types of documents on the same structural level.

  • Not everyone finds it natural to think in terms of outline levels. Users think of their documents in terms of what they are as opposed to where they are placed in the outline: as chapters and sections rather than as level 1 folders and level 2 text files.

We spent a long, long time thinking about these problems for Scrivener 3, trying and throwing out a good number of ideas—and implementations—along the way. All those options are needed to offer the flexibility central to Scrivener, and the level-based approach is at heart a good way of applying formatting to projects with an outline structure. So how could we take all that was good about Scrivener 2’s Compile but make it simpler and less intimidating, while also providing more separation between Compile formats and individual projects so that a single Compile format could be used with all sorts of project structures?

Compile in Scrivener 3

This is how Compile looks in Scrivener 3:

Some things you might notice:

  • All of the Compile formats are now neatly listed on the left, rather than being in a pop-up menu. (You can create your own formats using the buttons at the bottom.) This list shows only formats applicable to the currently-selected file type.

  • The middle column shows a preview of roughly how the text will look when compiled. It shows template text rather than text from the current project (because to show the latter would involve compiling the project in the first place). In actual fact, what it’s showing are Section Layouts, a key new concept in Scrivener 3 Compile which I’ll talk about below.

  • On the right are project-specific options. In the screenshot you can see the contents (the list of documents in the project to be compiled), but there also tabs for document meta-data (author name, title) and options (include comments? Include footnotes as endnotes or end-of-page notes?). For ebooks you can also set up the book cover and table of contents here.

  • Next to each document listed in the contents, you’ll notice there’s a Section Type—in the screenshot each document is set either as a “Chapter” or “Section”. This is another key concept which I’ll cover below.

This UI essentially replaces the old “Summary” pane, but it is much more useful. It allows you to set up how the current project should use the selected Compile format, and for everyday use will obviate the need to dig deeper into the more complex options. It can do this because, internally, all of the various Compile options have been separated into project-level options and format-level options. So, for instance, each Compile format contains formatting settings that can be applied to any project, but whether or not you want to include comments for this particular project (for example) is something that you choose here using a quick checkbox.

At the heart of Compile in Scrivener 3 are two new powerful concepts: Section Types and Section Layouts:

  • Section Types are part of a project and tell Scrivener what each document in the project is (for example, a scene or a chapter group).

  • Section Layouts are part of a Compile format and provide different ways for documents to be formatted. So, a single Compile format may contain one Section Layout for formatting chapter titles and another for formatting scenes, for instance.

  • To set up Compile, you simply tell Scrivener which Section Layouts in the selected Compile format should be applied to the different Section Types in your project (“format chapter groups using this layout and scenes using that layout”).

Section Types thus mean that you no longer have to think in terms of outline levels when working with Compile. Instead, you think in terms of what each document is. For example, here are the Section Types that have been set up for the built-in Novel project template:

Each project template comes with some Section Types set up for you, but you can change them to whatever you want. You then assign Section Types to documents in the same way you assign labels or status, via the inspector or outliner (you can also set them in the Compile panel). In this way you can set a folder as a “Chapter Group” or a “Part Group”, for example, and a text document as an “Introduction”, a “Title Page”, an “Appendix”, or whatever the project requires.

Meanwhile, each Compile format is now project-agnostic, and, instead of containing a map of how to format specific outline levels (as in Scrivener 2), they now simply contain a list of different formatting presets (Section Layouts) that can be applied to any documents in your project (based on its Section Type). For instance, the “Standard Manuscript Format” has one Section Layout that simply prints out “Chapter [Number]” in Times New Roman for any document to which it is applied; another prints out the chapter number and title; another prints out the title for a new Part; another formats scene text; yet another formats a whole chapter (a chapter title and text). When you Compile, you simply choose which Section Layouts in the Compile format should be applied to each Section Type in your project, ignoring any that you don’t need:

In the screenshot above, any document that has been set as “Chapter Text” (the Section Type) in the project will be formatted as a “Numbered Synopsis” (the Section Layout) during Compile.

What this means is that Compile formats are no longer limited to working with a particular project structure, and you no longer need to learn how to edit Compile formats just to get them working with your project. Instead, each Compile format comes with a bunch of Section Layouts, and you choose which ones to use with your project. You no longer have to tweak your project structure just to get Compile to format things how you want, and you no longer have to dive into the full swathe of options just to change which documents are treated as chapter headings.

We haven’t completely thrown out the old level-based design, however—after all, it was useful for applying formatting to many similar documents at once. Instead, we’ve moved the level-based setup from Compile to the Project Settings, and it now just provides a way of setting up the default Section Types. So, you can tell Scrivener that, say, any text document at level 3 should be a “Scene” unless you change its Section Type in the inspector or outliner. Where in Scrivener 2 you had to think in terms of outline levels to format your manuscript, then, now this is just something that will save a little time if you learn how to do it. You are free to ignore it and set the Section Types manually.

In practice, if you’re using the built-in project templates, you often won’t need to do anything other than choose the format you want to use from the list on the left and hit “Compile”. But if you’re creating your own project from scratch, it’s now much easier to format that project during Compile. And it’s also easier to create Compile formats that can be used with a wide range of projects.

Under the hood, all of the Compile options that were available in Scrivener 2 are still available in Scrivener 3—and more. But now you access these options by creating your own Compile format.

Many users will never, ever have to use these options, because the pre-provided Compile formats are now so much more flexible. But for those who like to dive into the more technical stuff, or who have specific formatting requirements that aren’t provided out of the box, everything you need is still in there.

We have prepared four videos introducing users to how Compile works for when Scrivener 3 is released. These progress from the basics right through to creating your own formats. Here’s the first one so that you can see the new Compile in action:

Scrivener 3: Doing it with Style(s)

Note: This blog post pertains to upcoming features in Scrivener 3, which will be released on macOS later this year and will follow on Windows some time in 2018.

Over the years, one of the most oft-requested features for Scrivener has been a styles system such as can be found in most word processors. For those unfamiliar with styles systems, this is what they offer:

  1. Styles are essentially named sets of formatting instructions. For instance, you might have a “Block Quote” style that contains instructions for making the text indented with a smaller font, or a “Heading 1” style which makes the text large and bold.
  2. When you apply a style to a section of text, that section of text knows what style it is. So, when you click into some text formatted as a “Block Quote”, some control in the UI will report that the cursor is currently inside a “Block Quote” paragraph.
  3. If you change the formatting of a style, the formatting of all text associated with that style is automatically updated. This is really the big advantage of a styles system. For instance, suppose you decide that you want all your “Heading 1” paragraphs to be blue and all “Block Quote” paragraphs to be italicised. Rather than having to go through all the text and update each paragraph one-by-one, with a styles system you just update the style, and all text to which it has been applied is updated automatically.

Scrivener 2 on macOS and Scrivener 1 on Windows currently has “Formatting Presets”, but not a true styles system. Formatting Presets provide (1) above but not (2) or (3). You can use them to quickly format a piece of writing, but you can’t easily update formatting to multiple areas of text after you’ve applied it.

All of this changes with Scrivener 3, which introduces a true styles system.

Scrivener comes with a number of styles predefined out of the box:

Assigning them is as easy as clicking in the text whose formatting you want to change and selecting a style from the list. Styles are available from the format bar, the Format > Styles menu, or from the contextual menu. You can even assign keyboard shortcuts to your most frequently-used styles.

Defining new styles works much the same as defining formatting presets in Scrivener 2. You simply select or put the cursor in a piece of text that uses the formatting you want for your style, then go to Format > Styles > New Style from Selection to bring up the New Style panel:

Once you’ve done that, the new style will appear in the styles list for the project, ready for use.

If you want to change the formatting of a style, you follow the same procedure but instead choose Style > Redefine Style from Selection. When you confirm the changes, all text using that style will be updated to use the new formatting across the entire project.

There’s a styles panel that allows you to search through text looking for and selecting particular styles, too.

Scrivener 3 differs from most word processors in that you’ll generally only want to apply styles to text that you want formatted differently—to headings, block quotes and such. In most word processors all text is styled, with the main text using a “Body” or “Normal” style (depending on the word processor). In Scrivener, you’ll want to use “No Style” for most of your text, as this will give you more flexibility when you come to compile or reset your editor default formatting. This system also means that you don’t need to use styles if you don’t want to. For this reason, there is no “Body” or “Normal” style provided by default.

Talking of which, styles are useful enough on their own, but they gain a whole lot more power in Compile. Styles are exported to numerous formats, including Word, and you can use styles to set up the CSS of Epub 3 and Kindle files. Not only that—just as you can override text formatting during Compile in Scrivener 2 (which you can still do), in Scrivener 3 you can, if you wish, override the formatting of individual styles. So, you can style your block quotes in one way when exporting for printing and in another way when creating an ebook. Those working with more technical formats can even enclose styles in custom codes using the prefix and suffix feature.

One of the core ideas of Scrivener has always been that you can write using whatever formatting you want and not have to worry about how the finished product will look until you come to export (Compile). However, historically, one of its weak areas in this approach has been that, although you can override formatting during Compile, any text formatted differently (block quotes and such) can end up getting mangled by these overrides unless you use a complex series of options provided specifically to work around this problem (for instance, Compile > Formatting > Options > Preserve Tabs and Indents). The new styles system solves all of these issues. Now you can tag some text as a block quote or a caption or an email—or whatever you want—and have complete control over how all of this looks in the compiled document, without needing to worry how it looks in the editor (unless you want to—as ever, you don’t have to override anything, it’s up to you).

You might be wondering how this affects the iOS version. In fact, Scrivener for iOS already supports Scrivener 3’s styles system. When you open a Scrivener 3 project in the iOS version, the formatting presets in the formatting palette are replaced by styles.

All in all, styles bring a lot of extra power, flexibility and convenience to Scrivener 3.

Bookmarking Folders in Scrivener 3

Note: This blog post pertains to upcoming features in Scrivener 3, which will be released on macOS later this year and will follow on Windows some time in 2018.

In a recent blog post, Ioa talked about how, in Scrivener 3, the new Bookmarks feature consolidates and replaces several features, including References, Project Notes and Favorites. You can bookmark any document in a project, or any file on your disk, and these bookmarks sit in a list in the Inspector much as References did in earlier versions of Scrivener.

The big difference in 3.0 is that there’s now an editor directly beneath the Bookmarks list in the Inspector, and the content of any bookmark you click on is opened there. This means that you can browse and edit any bookmarked document right in the Inspector, alongside whatever you are working on in the main editor.

Another cool feature of Bookmarks, though, is that if you bookmark a folder, all of its subdocuments are available for viewing in the Inspector too. Here I want to quickly show how that works in practice.

Let’s say I’m working on a novel, and in my binder I have a “Characters” folder in which I keep a different document for keeping notes on each character in the story. I also have a similar folder, “Locations”, for keeping track of the main places used in my novel.

These are the sorts of notes I’m going to want handy as I’m writing. I therefore add the “Characters” and “Locations” folders to my Project Bookmarks, so that they appear in the Project Bookmarks list in the Inspector:

Because “Characters” and “Locations” are folders with subdocuments, a down-pointing chevron appears on their right in the bookmarks list. If I click on one of these chevrons, I am presented with a menu listing all of the folder’s subdocuments – in this case a list of all my character notes:

From this menu, I select one of my character note documents to load it in the editor beneath the Bookmarks list, allowing me to refer to and update my character notes as I work on my scene or chapter:

Project Bookmarks in Scrivener 3 thus provide a great way of accessing all sorts of reference material right in the Inspector.

(In Scrivener 3’s built-in novel project templates, which have “Characters” and “Locations” folders already set up, these folders are automatically added to the Project Bookmarks list for you.)

Structuring with Label View

For our second post on the upcoming Scrivener 3, I’m excited this week to show off a new corkboard layout that takes advantage of one of my favourite features in Scrivener: coloured labels. Labels have always been helpful for organizing your project—you might use them to mark a scene’s viewpoint character, to indicate a document’s main topic, or to track locations for a script. In Scrivener 3, you can further use labels to visually chart your project’s structure by the points important to you.

Traditional corkboard view and new Label View
Arranging by label keeps the linear order but breaks out the documents into distinct threads.

Use labels to monitor the tension level of your scenes? View ▸ Corkboard Options ▸ Arrange by Label will quickly give you an overview of the pacing. For a story with multiple narrators, creating a label for each viewpoint character will let you see at a glance whether any character goes too long without a scene or has too many too close together.

Label view can display vertically or horizontally
Cards can be displayed horizontally or vertically along the label lines.

Just as on the regular corkboard, you can rearrange cards by drag and drop. Moving cards between label lines will update the card’s label without changing its order in the narrative. And of course you can create new cards and edit them, all as you’re used to doing, making the label view great for both initial planning and later reorganizing.

Project Notes are Dead, Long Live Project Notes!

When we first started putting together The Big List of what Scrivener 3.0 was going to be about, high upon it was the nebulous goal of making the overall experience more cohesive and streamlined. We may spend a little time going over some of the many finer points of that project in a future article, but for now I wish to focus on one aspect of that, something that some might consider to be a smaller adjustment, but one that has changed how I organise work inside of my projects—and reintroduced me to a feature that I had let languish in my own daily use of Scrivener.

Continue reading Project Notes are Dead, Long Live Project Notes!