#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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s