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!

3 – That’s the Magic Number

It’s time to open Scrivener’s next chapter.

Scrivener 2.0 for macOS was released in November 2010, and Scrivener 1.0 for Windows in November 2011. Since then both have seen plenty of new features and refinements added in free updates, and more and more people have used Scrivener to write their books. But we’re not standing still: for a while now we’ve been beavering away on the next big release of Scrivener.

I’m talking, of course, about Scrivener 3—coming soon to a screen near you.

Featuring a refreshed UI and some major overhauls, our focus for Scrivener 3 has been not only on new features but also on consolidating and simplifying what’s already there. We’ve taken years of experience of writing in Scrivener, both our own and that of our users, and poured it into Scrivener 3. The result is the best version of Scrivener yet, and we can’t wait to get it into the hands of our users.

Soon, we’ll start posting a series of blog posts about what you can expect. For now, here’s what you need to know about the release.

Scrivener 3 for macOS

Along with the updated features and the revamped interface, Scrivener 3 on macOS has been rewritten as a 64-bit app and to take advantage of new Mac technologies under the hood. Scrivener is more than ten years old now, so for 3.0, whole swathes of code and UI elements have been recoded and rebuilt from the ground up to stand Scrivener in good stead for the next ten years. As a result, Scrivener 3 for macOS will require macOS 10.12 Sierra or above to run.

I’ve been working on Scrivener 3 for a long time, but it’s now in beta-testing and is nearly ready. We’re finalising the updated manual and preparing for release later this year.

Scrivener 3 for Windows

“Wait!” you cry, “Can you guys not count?” Well, we can, but, mavericks that we are, we are eschewing all sense of sequence and jumping straight from Scrivener 1 to Scrivener 3 on the Windows platform. Why? Because our daring duo of Windows programmers has been working very hard to attain parity with Scrivener 3 on macOS. It will look every bit as beautiful as the macOS version, has been reworked to better work with high resolutions, and will bring the feature set much more into line across the two platforms.

Scrivener 3 for Windows is still in development and will follow a few months behind the macOS release. As much as we’d love to release both versions at the same time, the only way we could do so would be by artificially holding back the macOS version for several months. The Windows team has always had to battle not only with the macOS version having a five year head-start, but also with having to write a lot more custom code because of platform differences. So Scrivener for Windows is catching up, but our Windows users still have a little longer to wait. Because we want to make sure it’s rock solid and everything our users have been dreaming of, for now all we can say is that Scrivener 3 for Windows will be released when it’s ready, most likely some time in 2018.

However! The good news is that the more intrepid among you don’t have to wait until 2018 to try Scrivener 3 for Windows. We’ll be releasing an early access beta of Scrivener 3 for Windows on the same day that Scrivener 3 for macOS is released for sale. Anybody who owns Scrivener 1 will be able to run the beta (although it will initially be a work in progress with missing features, which is why I say it’s for the more intrepid). The Windows beta will also allow cross-platform users to upgrade their Mac version and continue to work between platforms with the updated file format.

Scrivener 3 is a Paid Update

Scrivener 3 is the first paid update in over six years. This means that if you own Scrivener 1 or 2 and want to use Scrivener 3, you will need to pay an update fee. (We haven’t yet set the price, but it will be around the same as it was for going from 1.x to 2.0 on the Mac.) There will be free updates for those who bought within a limited time period prior to the release date (more news on that soon). Two notes on this:

  1. Windows users won’t need to pay the update fee until Scrivener 3 is released on Windows. Owners of Scrivener 1 will be able to use the Scrivener 3 betas for free until then, at which point the betas will stop working and you’ll need to pay for the upgrade.
  2. Mac users who bought through the Mac App Store will need to pay full price again simply because Apple allows for no way of providing upgrade pricing on the App Store. We’ll be happy to provide a discount on our own store for any Mac App Store users who email us with proof of purchase, but you won’t be able to get the update on the Mac App Store without paying full price. We wish it weren’t so, but we have no control over how the App Store works.

We hope you’ll find the update cost worth it. There’s some cool stuff a-coming.

Scrivener for iOS

Scrivener for iOS is already set up to work with Scrivener 3 when it’s released. And we’ll be continuing to update Scrivener for iOS, too, of course. At the moment I’m focusing on iOS 11 support and improvements, such as the new possibilities that Files app brings.

Scapple

…has not been forgotten! Scrivener has taken a front seat for a long time, but once Scrivener 3 is out, we intend to spend some quality time with our Scapple code.

And Finally…

Over the next few weeks, we’ll start talking about what’s new in Scrivener 3 and what’s been changed. Until then, I’ll leave you with a couple of screenshots, one from macOS, one from Windows. We can’t wait to show you more.

Scrivener 3 for Mac Screenshot
Scrivener 3 for macOS

 

Scrivener 3 for Windows Screenshot
Scrivener 3 for Windows

Version 1.1 of Scrivener for iOS

We’re delighted to announce that in the next week or so, we’ll be releasing our first major update to Scrivener on iOS. It includes a much requested feature, one we enjoy playing with, and lots of work under the hood related to Dropbox syncing.

We’ve added Dark Mode to Scrivener on iOS. Switching into Dark Mode provides an entire theme that will be useful to those that like to continue writing late into the night. Once a project is open, tap the gear icon in the footer of the sidebar to open ‘Project Settings’. You will then see the toggle option for Dark Mode. All elements of Scrivener will immediately switch to a darkened theme that is ideal for working in low light environments. Whether you prefer writing on your iPad or tapping on your iPhone, you can now do it with the lights turned down low. Drift into that romantic scene writing by candlelight!

Dark Mode.
Screenshot of Scrivener’s Dark Mode.
Scrivener already had custom icons available for any type of document contained within your project. We’ve embraced the zeitgeist and you can now use emojis as document icons! Simply bring up the inspector for any binder document and press on the icon option. Along with the list of existing markers to choose from, you will notice a custom field. You can type any letter (or combination if you wanted to associate a character POV), or an emoji into that field. Not happy with a particular scene, it probably deserves a Pouting Face. Thumps Up Sign for that document you’re completely happy with. Any document icons that you do associate, will be immediately available to you the in populated list. Custom icons are an iOS only phenomenon at the moment, but they will sync with Scrivener projects on macOS and Windows when updates are released later this year.

Emojis.
Emojis as document icons.
Along with bug fixes, the work you won’t see relates to updating the API used by Dropbox. Dropbox is moving from API 1 to API 2 at the end of June 2017, so we’ve updated all the underlying sync code to ensure the process remains seamless.

We naturally hope you all enjoy using Scrivener 1.1 on iOS. We’ll be submitting the update to Apple for review next week, so it should be available in the iOS App Store in the next week or two. If you’re not already using Scrivener on iOS, now is probably a great time to take your writing mobile!

Scrivener in App Store Best of 2016

Scrivener - Best of 2016

Many thanks to the lovely Apple folk at all the stores that have included Scrivener for iPad in their “Best of 2016” app picks. It’s been a great year (for Scrivener, I mean – clearly it’s not been a great year for celebrities), and being picked as one of the Best of 2016 is a spiffing way to end it.

My sincere thanks to everyone who has supported us this year and all the past years, by giving us nice reviews, telling your friends about Scrivener, or just, y’know, buying it and using it and creating books and scripts and games and words with it.

I suppose I could get all Matthew McConaughey Oscar-speech-emotional on you, but I think we all know that the best speech of gratitude ever given was that of Hightower when he graduated Police Academy:

“Thanks.”

Bookmark Your Favourites in Scrivener for iOS

Drilling through a hefty binder of hierarchical files on an iPhone can be a chore, so Scrivener on iOS lets you bookmark documents to make them easily accessible. Just tap the ribbon icon in the editor footer to add the file to a special “Bookmarks” group at the top of the binder. You can also swipe left on a row in the binder and bookmark the item from the “More” menu.

Screenshot of bookmark icon states
Tap a document’s bookmark icon to toggle it on or off.

Bookmarked folders appear in the path menu from the binder navigation bar, so you can jump to them directly from anywhere in the binder. The “Move To” menu also lists bookmarked folders at the top to simplify restructuring your project. When you no longer need an item bookmarked, swipe its row in the binder for the “Remove” option (under “More” if you’re not viewing the bookmarks list), or tap its bookmark icon again.

Screenshot of bookmarked folders in path menu
Bookmarked folders are available from anywhere in the binder.

Bookmarks on iOS sync with the “Favorites” list on Windows and macOS, so you can quickly load your documents no matter where you’re working.