I am aware that we can have custom metadata (-- ie, “nickname” “Age” etc. ) appear in outliner view, but would love to have that appear in the character documents as well-- it can get fiddly to find it in the somewhat cluttered meta-data sidebar.
I know you can insert placeholder/metadata code (“<$custom:Nickname>”) in a document and get it to show the result when you compile, but is there any way to get the result (rather than the code) to display in the editor ? (The way you can display either result or field code in word?)
These metadata fields sync back to my timeline software. Seemed like it would be neat to drop the placeholder into the character template and just automagically have the result appear. I suspect the answer is no, but thought I would check.
Just out of curiosity… what kind of features wold a WYSIWYG layer be in the way of?
Remember… a loooooong time ago when word processors used code, not WYSIWYG.
If they could change, why can’t Scrivener?
And… easier interface often attracts more customers…
Whether you agree/like or not, the design basis as I understand (and appreciate) for Scrivener (written about numerous places) is first for writers, then for production (compile) of deliverable format with a clean break between the two. Yes, other products combine those elements. But to combine, for many customers, would be not appreciated. Yes, Scrivener is unique, and the division is therefore a “unique selling point”.
As an aside, I do remember the transaction from “codes” to WYSIWYG in ancient times when the software industry was evolving quickly. I find it amusing to watch new “cool” trends to go back to “codes” and all that, e.g. Markdown.
As you noticed, I didn’t try to answer your “why?” question. I only know the design basis of Scrivener and I tried to explain that to you so at least you can have an appreciation of all that.
“Why” they can’t change? Dunno, but I have theories. That up to Literature and Latte and assuming anything about future market value of their product is outside my expertise. I do know that after more than a decade using the product, if they went the WYSIWYG route, I wouldn’t be a happy camper. I can do WYSIWYG now with so many other products that I do use, but not to the extent as I use Scrivener for writing projects.
I’m sure on this forum you can find many past discussions on this topic. Not much has changed to make it worth yet another discussion now, frankly. And certainly nothing to disagree about.
Yes, along with going back to dark screens with light text. Who else here remembers the chap who lambasted the whole Scrivener set up way back with the assertion that “real writers only use blue screens with white text”.
Personally, I find dark screens very difficult to work with except for photo or video editing.
Probably someone who transitioned from C64 straight to Mac. I’d find this color scheme way too “BoD-thy”. On the other hand, a constant feeling of imminent doom might be helpful when writing horror stories.
But I really like “dark mode” color schemes. I guess they trigger some kind of luminous nostalgia.
I’ll later do a video showing some of the advantages (to me at least) of not depending on WYSIWYG, but for now, here are two workflows creating entirely different exports from the same content (nothing so simple as showing or hiding field codes).
I am so interested in this evolving conversation! I appreciate just about everything in Scrivener, and use it exclusively to write now, so when I have to return to Word I am often frustrated. I’m not campaigning for a new feature – I wrote the original post just to confirm that a feature I was searching for doesn’t exist. I believe I understand the philosophy behind keeping all the heavy lifting in the compile, but also: the latest versions of Scrivener have introduced some WYSIWYG in the form of formatting/styles. It’s not completely clear to me why inserting the equivalent of a field code couldn’t work in the same way…
Here’s a screenshot from my WIP Editor. Dialog traveling brain to brain through the 2099 version of the world wide web appears in blue, Helvetica, 12pt. The style for that is babel.
and here is the same thing when compiled. In Compile, the blue highlighting doesn’t appear, and I override the babel style to add delimiters before and after it. If an editor doesn’t like those delimiters, I can change them to single quotes, angle brackets, parentheses, or anything else – and change the text itself to another font, bold, italics, etc. – in less than a minute without touching the Editor.
Thanks for the visuals. Not to be dense-- I still don’t see why {authorname} (or any other field) couldn’t be inserted into the document, and displayed as text. I will accept that the mysteries of coding are more profound than I can intuit…
*case in point, I tried to use the proper field code brackets around authorname in writing this reply, and and was surprised that the whole field entirely disappeared from my comment! I am clearly over my head!
Inserted when, though? Nothing is final until it’s Compiled, and we can have multiple compile formats for different purposes, different audiences, etc. If we have to decide when we’re writing, we miss out on all that flexibility.
Personally, I use {imageName} to compile an external image (so it doesn’t take up space in the project) to whatever export format I’m targeting. Here’s a workflow for that:
Very simply, KB (the programmer and designer of Scrivener) has stated at many times through the years that he doesn’t want Scrivener to be WYSIWYG. It wouldn’t meet his vision of what Scrivener is meant to be – or be a program he would want to work on – if it were.
I believe I understand the philosophy behind keeping all the heavy lifting in the compile, but also: the latest versions of Scrivener have introduced some WYSIWYG in the form of formatting/styles. It’s not completely clear to me why inserting the equivalent of a field code couldn’t work in the same way…
