Absolutely, at least in intent and capability of output—I’d say Scrivener is even superior to Word on this account (if I understand the limitations in how you describe it), since Scrivener’s system is algorithmic instead of binary (hidden vs. not). What you hide can be a complex multi-factor search result through keywords and so on. You can do interesting stuff like only compiling out sections that are marked as needing rewrites.
But to get back to the basics You can test this theory really easily. Just make a blank project, add three things to it, and use labels to colour two blue and one pink. Now load up Compile, click on the Contents pane, and add a filter at the bottom to exclude pink items. Now enable and disable the filter. That’s how easy it is to have two editions embedded in one tree.
Scrivener’s own user manual project, which you can download from our support page would be a practical example of how you can do that with three intertwined text trees. The user manual is written once, for both Windows and Macintosh. They use a shared pool of text, which means any improvements, rewrites and fixes generally fix both at once. However, as you can imagine there are many divergent areas. The Mac version is a lot older, for one, so that means there are a lot of chapters and sections in the manual that don’t appear in the Windows version. There are cases where that happens in inverse as well. The Windows version does some things that produce chapters you won’t find in the Mac manual. So I have three streams of text that need to be blended two different ways: neutral (always there) and the two platform specific types.
The concept is simple, you just switch the label type that is being excluded. In the example, you could add a fourth unlabelled item, go back to compile, and experiment switching the exclusion from pink to blue. That’s all that is going on here, just on a much larger scale in the user manual.
Within the text itself, I also mark out phrases that should only appear in one or the other. The entire manual is peppered with those, because every keyboard shortcut is different, and often menu labels and such are different as well. You may not need that level of exclusion, but I figured I’d point it out in case you do.
Now, a caveat with that project specifically is that it uses MultiMarkdown for the actual text construction. Structurally, though, at the project and compile settings level, you can see most of the important concepts behind this idea:
- Have some piece of meta-data you can easily sort between advanced and simple sections of the book. This can be a keyword, whatever. I used label because you can tint the icon with that and it makes it really obvious which portions of the book are Mac or Win specific.
- In the Contents compile option pane, enable the filter setting and exclude out all of the items not pertaining to the compile target. They will be selectively removed from the Contents list visually, you can preview the results in the main table above.
As for excluding phrases, if you need that, I would not recommend what you see in the Scrivener manual. It’s a somewhat outdated technique for MultiMarkdown. Differently coloured annotations won’t help you out much unless you are using something like Pandoc or MultiMarkdown. Then what you compile is actually a sort of script, and you can cause it to do simple logic transforms. In other words, the document I compile, in conjunction with its stylesheet, knows how to omit Mac phrases from a Windows target and vice versa.
Without that, you could probably cook up something using Replacements. The Scapple manual will have more interesting ideas in that regard. One could for example, invent a fake syntax like this phrase only appears in the simplified version, and just cause it to vanish with a Replacement that converts it to empty. In the case where that does print, the preset’s replacement would instead just strip the tags and replace the whole range with the stuff in between the invented codes. It’s pretty straight forward, just like search and replace, but without damaging the original copy, it only happens to the compiled output. Again, check the Replacements for the Scapple project for ideas.
As for working this way, compile aside, I think it’s pretty useful within the writing area, too. You can for example filter out items with that label using search, and read through sections without them to see the “simple” view. You can’t actually directly hide elements within the Binder, but using collections and searches you can effectively do so.