Word, macOS, and System Keyboard Shortcuts

I’ve got just one question for you, fellow person:

Wouldn’t it be great if you wished yourself dead a touch less often when using Word on a Mac?

Microsoft is hellbent on making Office for macOS behave exactly as it does on Windows.  That sounds great on the face of it, but they take it too far with the keyboard shortcuts.  They have their own keybinding system that overrides a lot of the quiet native stuff offered in macOS.  When you use Word on a Windows system, Word’s shortcut system just happens to match the Windows-standard text navigation.  You never have a reason to notice that Word is goofing around with your keyboard input.

Of course, on macOS they put the proper Command-based shortcuts in play, but the Control-based Windows ones are still there too, making Word respond to both Cmd and Ctrl for commands such as Save, New Document, Cut, Copy, Paste, and others.  Word altogether ignores the wisdom of the standard Cmd-Up and Cmd-Down for “top of document” and “bottom of document” (instead making it jump paragraphs) and instead opts for the Windows-influenced Cmd-Home and Cmd-End, which is particularly obtuse because on any modern Apple keyboard this means you have to push Cmd-Fn-Left and Cmd-Fn-Right when you really want to go up and down.

Worse for me, honestly, I use the “secret” system Ctrl shortcuts quite a lot in text editors of all kinds, so Ctrl-N, Ctrl-P, Ctrl-A, and Ctrl-E mean important things to me (up, down, home, end).  Word messes up or completely ignores these commands, because even on macOS, Ctrl-P means Print to Word, and Ctrl-N is a new document, and Ctrl-A means “select all.”

I refuse to be bothered by this counter-productive nonsense on a daily basis.  So here’s what you do.

Screen Shot 2017-06-16 at 11.21.17 PM

Open Word and visit the “Tools” menu for the “Customize Keyboard” menu item.

The window that pops up will give you access to the master keyboard shortcut system that Word uses (and stores in the mythological “Normal.dotm” file—more on that later).

They try to throw you a bone in this window to break up the commands into their respective menubar groups, but the truth is that it’s not a very tasty bone.  There are lots of shortcuts bound to things that don’t explicitly appear in the menus, and they all have names that come off as obtuse to the average user.

Screen Shot 2017-06-16 at 11.26.59 PM

So scroll down in that little Categories list on the left and find “All Commands” so that you can cut the bullshit and get to filtering commands with the names I show in the table below.

When clicking on a cryptically named command in the right side list, you will notice that the box below all of this will show any shortcuts bound to that action—sometimes there is more than one, as you will see if you look up the “FileSave” command, which lists both Command-S and Control-S.  A huge number of these commands don’t actually have shortcuts assigned, but they’re open to new assignments if you’re brave.

All we’re going to move some assigns to their “native” macOS behaviors.

As a technical aside, it’s actually not good enough to just remove Word’s bad use of a shortcut and hope that it’ll let macOS just do the right thing—you have to actually redundantly tell Word what to do for any standard shortcut you hope to use.

Screen Shot 2017-06-16 at 11.54.40 PM

To set a new shortcut, place your blinking cursor in the box below all that and just press the combination you want to use.  If it looks right, press that “Assign” button and (once you finish off by pressing the window’s “OK” button) you’re good to go.  As demonstrated in the related image, you don’t have to worry when assigning a shortcut that is in use elsewhere; Word will strip the old command of that combination and assign it only to this one.

Another potentially interesting aside: if you ever remove an overridden shortcut, it seems to go back to its original command all by itself.  No matter what I did to stump it, Word seems to know what all the defaults are even if you mess stuff up.  Just remove a bad shortcut if you don’t like it and things will go back to normal.

Following is the list of (fairly self-explanitory) command names that I myself was interested to fix, and also what the proper system default shortcut should be.  I’ve written the names the way Word will display them when you’ve correctly entered the shortcut.

Command name New shortcut
StartOfDocument Command+Up Arrow
EndOfDocument Command+Down Arrow
StartOfLine Control+A
EndOfLine Control+E
LineDown Control+N
LineUp Control+P

To add zest to my already improving life, I added these as well, which help you navigate up and down by paragraph.  These aren’t strictly system shortcuts, but they are common in popular code and text editing software.

Command name New shortcut
ParaDown Option+Down Arrow
ParaUp Option+Up Arrow

By default, pressing the “OK” button on this window will automatically save these changes to your “Normal.dotm” file, which is the master template that Word will use for all future fresh, blank documents.  Lucky for you, if this is really the only reason in your life you’ve messed with this stuff, then all previously existing documents will get to use the custom shortcuts too (since those documents didn’t embed their own overrides).

I choose to back up the file in order to preserve this work so that I don’t have to mess with this process in the future should I get a new computer and install Office.  There’s not much of a reason to back it up just to preserve Word’s default though; just deleting “Normal.dotm” will make Word recreate a fresh default one.

You can find this special file in the amazingly named folder “UBF8T346G9.Office” at the following place in your user account’s “Library” folder.  (Open Finder and use the “Go” menu for “Go to Folder” to paste this path and go there directly.)

~/Library/Group Containers/UBF8T346G9.Office/User Content/Templates

If you’ve had Word installed for a long time and did an in-place upgrade from their 2011 version to 2016, the folder will be at the old location, shown below:

~/Library/Application Support/Microsoft/Office/User Templates/My Templates

So.  May you wish yourself dead a touch less often when using Word on a Mac.

Fantastic Revisions and Where To Find Them

Now that NaNoWriMo is over, I’ve switched back to revision mode for Holder of Ash. I’ve started my third (of probably many) revisions, and like the first two, it’s a big one.

At the start of November, I got really excited and did some prewriting for the sequel, The Assembler Constant.  I set out on that little journey fully expecting to realize issues in Holder of Ash—things I would have to foreshadow better, conflicts that have to be seeded if they’re going to show up in the sequels with any convincing delivery.

I realized all at once that Kenjn, the dominant councilor for Queen Djet Zne’tal, needed to be male instead of female.  It was the kind of realization that was at once both hard and easy to internalize—I knew it was going to be the right thing to do, and yet I loved the character as she was.  I can’t say that it was a “darling” exactly, but I was at least fond of her.  She was like a matronly version of Zarya from the game Overwatch (which is a home run of a character shorthand that I fully intend to use, so back away from that with your hands where I can see them).

The change became important to me for a couple of reasons: I had used a lot of female characters to the point of having a large proportion of the males be bad guys, and I loved the subtle effect that making Kenjn male did to the relationship between Djet and one of the other main characters.  It felt right.

So Kenjn would become male, but now I had a council of three males, an antagonistic female, and the queen herself.  I didn’t like the way it was shaping up so far as it concerned the sequel.  In Holder of Ash it would probably be fine, but…

That led me to realize that I needed to cut the pool of councilors in half.  Four to two.  Kenjn would stay and the antagonistic female would stay, because those were the only two that actually impacted the plot in a really meaningful way.

Getting to work

I got to dwell on this change through all of November while I wrote other things for NaNoWriMo.  It really let the scope of the change sink in.  It’s not that the scope was staggeringly big or that the change would be hard, but just letting it sink in helped me become confident with what I was planning to do to the manuscript.

Now, I got hyper organized in this project and used Keywords out the wazoo to tag every scene with the characters that appear in it.  This actually wasn’t going to be good enough for me to hunt down the scenes that needed changes, if only for the simple reason that (until a full read-through) I might miss offhanded references in thought or dialogue to a cut character where they weren’t otherwise present.

screen-shot-2016-12-01-at-4-30-31-pmI love Scrivener’s search function.  A text search for the names of the cut characters was obviously what I needed, and Scrivener is about to make my life a lot simpler.

Because these two characters were to be removed simultaneously, I put them in the same search.  You could make separate searches out of these, but I liked the idea of treating this as a single step of revision.

To make it work, I use the RegEx operator type, which enables the arcane “pattern matching” mode.  I put a \b at the start and the end to signify a word boundary (so that “Trab” didn’t match the word “demonstrably”—a case sensitive search could help you here, but not if the name was something like “Koa” and you used the word Koala at the start of a sentence somewhere in the manuscript).

The parentheses are wrapping a list of things I’m looking for, and the pipe character | between the names is an OR operator.  If you need to, you can append more of those into the parenthesized list: \b(Trab|Anmir|Kenjn)\b

So now we can save the search using the last option in the list, and you get a new tabbed item in your binder:


Now you have a list of scenes where these names appear.  Don’t rely on this to catch everything (I know for sure that I have scene where a POV character sees these characters without knowing them well enough to use their names) but it’s a great automatic TODO list of scenes that need attention.

Once the scene has no more mention of either name, it’ll automatically get removed from the list.  If that’s a problem, you can make your own custom Collection via that thin little + icon by the word “Collections” and drag all of the scenes in your search to that Collection instead.

This is basically my task list for the next week or two!  Thanks Scrivener!

An Effective Use of Templates in Scrivener

Here’s the basic introduction to templates if you don’t know how they work or how they could help you in your outlining/prewriting:

In your project Binder, there are a number of folders you might be managing.  The obvious defaults might be just Draft and Research.  You can add a Characters folder to join these, or inside of Research, whatever suits your fancy.

But do you find yourself duplicating a lot of work when you do multiple Character sketches or Place profiles?

What scared me away from templates at first was the idea that a single document was supposed to hold all of the templated info.  I may as well just duplicate some other existing character file and change the values.  No big deal.

But templates are way better than that.  You can make a template folder that comes with all the broken out sub-documents you want.  Combine this with the “Default New Subdocument Type” option for folders, and you can do some really great things.

Setting up your Templates folder

screen-shot-2016-10-31-at-2-17-02-pmStart by adding a regular old folder to your project.  You can name it whatever you want, but Templates is a pretty reasonable choice.

I let this folder exist at the root of the project alongside Draft and Research because once I set it up, I’m probably not going to drill down into anymore.  You can make this folder live wherever you want, though.


Now designate this folder as your source for all Template files/folders.

This will give the folder a unique icon to show its special status.  You can only set up one of these folders.  The menu option shown here will change to “Clear Templates Folder”.  It’s not the end of the world if you clear it and re-set it, even if you’ve already started building out your repository of templates.


I’ve now added a Character folder within Templates, and I gave it the icon I like to use.  Notice the small “T” added to the icon to represent that this is serving as a template.

For a basic template, you’d make this a text file instead of a folder, but I want it to be a folder so that I can throw in a bunch of default sub-documents that I like to have when I make a new character.

So let’s add a few documents (with fancy icons!) that give me the big picture view of this character.  I’ll want to add notes on the fly once I’m working with a real character, but this is the just the template, so I’m creating just the stuff that all characters hopefully have in common.

Let’s step away from our Templates folder for just a minute to explore how to put this to use.

Make a Characters folder in Research, and make sure it’s actively selected (that is, the Binder has application focus, not the writing area of Scrivener or something else).


Using the Documents menu, you have an important option available: “Default New Subdocument Type”.  That’s fancy talk for “What happens when I push [Enter] when I have this folder selected?”

The answer in this case is that we want the Characters folder to spawn new Character templates instead of basic old text files.


You’ll notice that hovering over the Character template shows us the sub-documents we made, but you should ignore those.  You can actually just click on Character directly and it’ll move that little checkmark from the default “Text” choice to “Character”:



So now, when you have Characters highlighted in the Binder, pushing [Enter] will create a whole duplicate of the Character folder, complete with all of the sub-documents!

There is one hitch about the way Scrivener handles templates that you’re probably going to run into at this point:

Even though your brand new Character folder says its default sub-document type is a standard “Text” file, highlighting the new character or one of its sub-documents and pushing [Enter] again will yield something that is probably not all that helpful: a nested character template.


Yuck.  I want to be able to push [Enter] inside of my character folder to create new blank text files for notes, ideas, stuff that I like to see in the expandable list rather than actually opening a notes file and skimming for text in paragraphs.

If you check the “Default New Subdocument Type” for your new Character, it’s actually already set to Text, so what happened?

At the time of this writing, Scrivener treats Text as the lack of a more specific choice on your part.  It’s Text because you’ve provided no override.   But this folder consequently inherits the setting of its parent folder (and maybe that folder inherits from its own parent, all the way up the chain).  Once it finds an override, that’s what it’ll use.


So here’s what you do.  Back in Templates, add your own template file called Text—I’ve left mine empty, just like a default text file.

Delete that Character folder you made in Research, because we want to update the template and recreate it from scratch.

Now you can set this “custom” Text document as the default sub-document for our Character folder template:

Screen Shot 2016-10-31 at 2.50.07 PM.png


Now make a Character in your Research‘s Characters folder, and push [Enter] again inside of that Character, and you’ll see your Text file appear instead of a nested Character.


Once you spawn a copy of a template, Scrivener doesn’t track where it came from, so old copies won’t get updated if you alter settings on the original template.  This is why you should either trash the broken version of the Character that we made before we realized this mistake, or you should go back and set the Character‘s default sub-document type to the new Text type.

Nested Templates as default sub-documents


You can set sub-documents for sub-documents!

Here, I’ve built out a World template because in my story there are going to be a few of those, and I want to track some basic info about them.  In addition, I need to list the cities or points of interest, and each of those places might have any number of notes, from “This is the capital” to “So-and-so died here”.

So we have an empty Places folder in the World template.  Rather than loading a handful of blanks to get it started, I leave it empty, then make a lonely Place template (green flag in the image above) outside of the World template.

Now you can do what you’ve done before: Set the Places folder to use Place as the default sub-document:

Screen Shot 2016-10-31 at 4.38.14 PM.png

Make sure for both World and Place, the default sub-document is our custom Text type so that we don’t accidentally make nested Worlds in Worlds, and Places in Places:

screen-shot-2016-10-31-at-4-43-17-pm screen-shot-2016-10-31-at-4-41-33-pm

And finally, you can create a proper Worlds folder in your Research and set the sub-type to spawn World templates:


Each World comes with set of skeleton documents for notes, and a Places folder which spawns Place templates.  The Place templates are empty, but you can generate as many notes as you want.


To the left is the final view of the templates and example research that I built.

The best way to make the most of templates for faster project construction is to use them as default sub-document types, like we’ve done here.

This may seem like a time-consuming effort, but I highly recommend that you save a stripped down version of this as a custom project template.  Even if you find yourself customizing it for each project, this can be fun to tinker with and can ultimately save you a lot of fiddling.

I have a workflow for my Draft as well, which is to create Chapter templates that spawn simple Scene text files with a name pattern that I like, such as “City: Location”.  It’s a tiny thing, but it makes working in the Binder completely effortless.

When you save a Scrivener project a new project template, you should keep things like our Characters and Worlds folder, but make sure they’re empty and have the right template set as their default sub-document type.  This will let you start a new project and immediately get to work!


And now you’re a template power user!

#STWL: Scribing Tools Wish List #1 — Meta-Data Woes

Let me at least say that I have an abiding love for Scrivener as a project manager.

Let’s talk about one pretty huge but, though.

Meta-Data: Labels, Keywords, and “Custom”

I love that Scrivener supports user-defined project metadata, but the whole thing feels kind of tacked-on.  It’s a shame, because the functionality is there, but it’s awkward to make maximum use of it.

You have two categories of user metadata: keywords and “custom meta-data”.  The difference between the two is essentially that keywords are just tags you put on something, and “custom” is like a tag but with a value hand-entered by you on a per-document basis.

For this reason, “custom” items can be enabled as columns in your outliner view, and every document down the list will show its entered value for that one “custom”.

But here’s where my gripes come into play:

  • There’s seriously not a better way to refer to these than a “custom”.  Give this concept a better name.
  • Keywords and Customs are extremely related in concept and execution, and yet are implemented very differently.  The UIs could not be more different from each other.
  • Keywords and Customs are project-searchable, but Scrivener offers no automatic helping hand to give you filters.  You have to perform the search manually.  This is pretty annoying if you think about it.

User Interface

Defining new items

Screen Shot 2016-10-27 at 3.13.41 PM.png

I’m going to have to just gloss over the fact that the UIs for these two things are so separate.  You can assign them colors, although for Customs the color is optional.  I can only guess that color is required for keywords because they’re essentially just more Labels, but less useful because you can’t do much with them.

I’d vote for putting the Keywords as another tab in that Settings sheet, but the Settings sheet is actually a modal dialog thing, so it has to go away before you go back to the project.

This is nothing against modals, but we should have these two things living together one way or another.


I’m kind of happy with the way it works in the outliner:


You can even click directly into a Custom’s column and edit the value…

But you can’t click and edit Keywords—it’s a fancy list that might have multiple terms with their differently colored underlines.


Searching only works against the values you enter for a Custom, not the presence of a given Custom.  In other words, I can’t do a project search for the phrase “key-value item” and expect to get a list of documents that define a value for that Custom.  Instead you get nothing (unless some document somewhere had that phrase in the VALUE of some Custom).

Keywords are better suited for this—you search a keyword, you get documents with that keyword.

Document UI

screen-shot-2016-10-27-at-3-37-06-pmAt this point, the question should be asked: Could we perhaps merge these two different ways of tracking meta-data?  Would it perhaps be more straightforward to keep Customs, call them something else, and optionally allow them to be “tag-only” (to prohibit values)?

When we flip to the inspector’s “Custom Meta-Data” panel, we see the bottom bit display a sheet of all the Customs declared in the project, and a space to enter values.  They’re even colored like in the outliner!

There is a separate panel for Keywords, which is empty even if you’ve declared Keywords in the project—it only lists the ones that have been explicitly assigned to the document.
Adding keywords into that list is actually kind of weird:


Pushing the little + button adds new keywords to the project on the fly and lets you type existing names or new names.  This is kind of nice for rapid creation of keywords on the fly, because it auto-assigns random colors and everything.

But could we maybe… combine these things?

I might like to see a UI more like the “Custom Meta-Data” panel, where I have a sheet of my existing stuff, all Keywords and all Customs.  The Customs can keep their textboxes, but the Keywords would be checkboxes for me to hit if I want to tag the document in question.

But that’s a digression.  It’s actually not the best solution.  Let’s continue.

The quirk that probably stops Scrivener from making a change like this is that Keywords are actually implemented in a hierarchical way.  You don’t get any indication of that hierarchy in this Keywords listing, but if you open the floating panel for the project’s bank of them, you can see and change the structure (which organizes how they would appear in that “Add Keyword ->” menu shown above).

The other quirk we run into at this point is that you can tag the same document with the same Keyword multiple times:


This is probably comes down to a lazy implementation.  If Scrivener stopped it from autocompleting the a duplicate keyword, what happens if you type it all the way out and push enter anyway?  Are you supposed to get a distinct copy of the Keyword with a new color?  Definitely not.

The Binder


So here’s the rub.  This is what it all comes down to for me.  I can’t surface ANY of the Customs or Keywords in my binder via colors.  This might sound nitpicky, but it’s HUGE.  Coloring in the binder is an incredible way to see the story documents for what they contain.  Navigation, reorganization, and skimming is all much easier with those colors.  But Labels are the only option for coloring binder items to add visual distinctions in a big project.  Labels are cool, but every document only gets one.

What if I could declare which meta-data source shades the binder icons/cards/rows?  I could even shade icons one way and rows another way—why not?

It’s awkward to do in this kind of cascading menu, but more than that, we have to ask ourselves what we need from the workflow to make this work:

  • Shading by Keyword doesn’t actually make a ton of sense as-is.  Are you supposed to pick some global keyword and if the document has it then it’s shaded, and if it doesn’t then it’s not?  Nah.  That’d be dumb.
  • Shading by Custom is more practical, except it’s the per-document values we put in the Custom that really dictate the color, isn’t it?  Scrivener lets us pick a color for the Custom itself, not the unique values that will appear in it.

So now we understand why it only lets us shade by Label, because “Label” is essentially a special Custom that Scrivener names for us, and the labels you add as choices are actually what we need: color-coded values that appear in the choice list.

The Conclusion: Labels

Keywords are cool—they’re searchable.

Customs are cool—you can put arbitrary per-doc values in them and show as outliner columns

Labels are cool—you can assign colors to values

All three are broken, and no single one is sufficient to solve the problem.

We need someone to figure out assigning multiple labels to a single document, where they are hierarchical: every top-level Keyword gets a dropdown, and your choices in that dropdown are the color-coded sub-items for that Keyword.

In Scrivener speak:

  • Ditch everything: Labels, Keywords, and Custom
  • Every project starts with a top-level Keyword called “Label”
  • “Label” is a dropdown picker that starts empty, just like in Scrivener today
  • Adding new labels is actually adding new child Keywords to “Label”
  • All child Keywords let the user assign colors (the labels concept lives!)
  • The user can add more top-level Keywords for whatever they want, just like Keywords today.  I would probably spring for “Setting” as a top-level.  “Characters Viewpoint” would be another.
  • With the addition of new top-level Keywords, that lonely little “Label” dropdown gets siblings: now there are “Setting” and “Character Viewpoint” dropdown (empty of course until I add child Keywords to each as I flesh out my story)
  • Allow child Keywords to be entered on the fly to address the use-case for arbitrary text entry in Customs.  It autocompletes and auto-assigns color if the value is new.
  • Now my choice for coloring binder icons/cards/rows is nicely structured to let us pick a top-level Keyword as the source of color shading (the color being the child Keyword chosen for that top-level on a per-document basis).

This all comes off as very picky, but if something like this ever happened, it would streamline the metadata situation so much that I would just spend a day crying under my blankets.

We still probably want to maintain document tagging (i.e., more than just picking one thing out of a dropdown), but I think this puts us closer to better meta-data.

What a bright future.

Using and Configuring Scrivener

Scrivener caught my eye years ago because of the flexibility it offered.  I didn’t need the kitchen sink of features (although Scrivener is that), we’re talking about my ability to configure it to bring forward what I care about the most.

Coming from a much simpler editor, Scrivener was a little overwhelming, but these changes helped me feel like I was in control.

What I need

When I’m pre-writing, outlining, or in the throws of storytelling, I need some basic information handy at any time:

  • Document words counts
  • Total word count for everything inside a folder
  • A running word counter for my work that day
  • Separate space for notes that doesn’t require me to leave the document I’m writing
  • Easy navigation between my book’s parts (my notepad-era writing is over, I can’t be bothered to scroll around or use Find for the exact wording of a chapter name)


This is where you could star in an episode of LOST if you start looking through them all, but let me point you at a few that I find helpful, relative to the bullet points above.

Document coloring

screen-shot-2016-10-13-at-12-55-17-pmThis won’t matter unless/until you add Labels to your project, but this is inevitably an early part of how I set up a story with multiple viewpoints.  I make project labels for characters, assign a color, and then match that label to any document from the viewpoint of that character.  The coloration from the Icons setting becomes a quick way for me to see the texture of the story from the document list.

Default font and formatting

Before you go through the headache of changing the formatting on a real document, visit the main settings and see if you can’t get a sane default.  You can actually interact with the toolstrip buttons above the sample text, the first button being the font changer.  I like to make sure I have a proper indent set up.  The other notable setting here is line spacing, the last item on the toolstrip.


If you want, you can play with all of these same settings in a real document to try them out, and then come to the program settings and the Use Formatting in Current Editor will be enabled for you to import as the new global default.

Scrivener will never retroactively apply your global default to existing documents, however, so don’t spawn a lot of documents if you’re not ready to commit to the defaults you’ve got set up.

Page settings

I hate losing my cursor, so I drop in to the Editor settings and select Highlight current line, and I set the typewriter scroll style to Middle of screen.  I hate losing my cursor.

I hate losing my cursor.


The color of the line highlight can be changed over on the Appearance tab of the settings, at the bottom:


Window layout

This might seem like a picky time to talk about layouts, but I’ve found that I keep coming back to the same system:  Outline sidebar on the left, a second faux-sidebar just beside that locked into the Research folder, then the editor itself.  I also like using the info sidebar for scene-specific notes, and often I throw the Project Notes off to the side so I can track problems I find with the larger story.


Now, for someone that came from using a glorified Notepad editor, this looks like a lot.  It is.  I’m getting comfortable with my workflow, however, and so I’ve gotten particular about it.

You can set something like this up by splitting the layout vertically, drill the left panel down to your Research folder, and then locking it into place so that clicking on scenes causes the right-hand editor to change (left click on the Research icon in the banner next to the back/forward arrows).


To get the most of the Research sidebar, I turn off all of the column headers except for the title and synopsis.  The synopsis is easily edited directly from the list view!


I saved my layout so that I can bring new projects into the same layout very quickly.


I tend not to open documents in the Research sidebar for editing, but by right-clicking one that I need to investigate or change, I can choose to view it in a floating Quick Reference window.  The documents in Research tend to represent notes, so I’m not usually using the real Notes section on such a document, and Quick Reference fits that use case pretty well.

Project structure

I personally like starting from the blank template.  Once I’ve set up stuff like my default font and paragraph spacing (blah blah), the blank template is all I want.

We have Draft and Research, and my first order of business is to add a document in Research that I call Concept.  I start unloading my overarching ideas into that document.  I may never really look at it again, but it helps me solidify the tone that got me excited in the first place.

I make a folder in Research called Characters, too.  This starts off as a loose collection of sub-folders titled after character names, but often I don’t even have that much, so I name them after the occupation.  Not much else has to go here just yet.


At this point, I open my Meta-Data Settings and throw down some labels named after my characters.  Again, because I might not have settled on the character’s final name, often the colors are all that matter right now.


For a big story like the one I’m using in these screenshots, I’ll add labels for storylines, too.  I apply those to whole chapters (except for chapters that have things from across both storylines—I leave those alone).  This helps me see in the outline view how much time I’m spending on one world versus another, and I can plan more effectively how to weave the two storylines.

For Draft, where the actual story goes, I make folders for the various parts, then documents for chapters.  I’m rarely putting anything in the chapter document itself, but I put scenes inside named after the location where the scene is taking place.


These scene names aren’t something that will ever be seen in the final export, but they help me see into what I’m doing, and it definitely helps me navigate when I’m looking for that one scene.

The icons get colored based on the viewpoint label assigned to it, and as you can see, I allow for scene breaks even if the viewpoint isn’t changing.


Gee, Brain, what do we want to do tonight?

screen-shot-2016-10-13-at-2-16-47-pmThe same thing we do every night—we write!

To keep track of how I’m doing, I make sure the outline view has the Total Words column turned on.  This will show me sums for any sub-documents, which is actually what I care about so that I can check on chapter lengths when I have a group of scenes.
screen-shot-2016-10-13-at-2-24-22-pmFinally, if you need to see how much you’re
writing in a sitting, turn on the Project Targets overlay.  I like to set the word tracker to only reset manually (rather than at midnight, etc).

There’s a lot more that you can mess around with, but this setup goes a pretty long way for my productivity.