It does help. You’ve been a great help here.
I don’t see much advantage, however, to this feature. It would seem that if one has Scrivener, that it makes it somewhat of a no-brainer that they would have that on every device they intend to edit on. So having text files available for other platforms? I don’t see the advantage.
If the goal is having the project available on multiple platforms owned by you, having the master project resident on Dropbox does that (and much more). Unless multiple collaborators are editing the same line of text in a doc simultaneously (which I really do not recommend), the doc will instantly be in sync, and there will be no sync problems or multiple versions. ‘Sync with external folder’ can’t do that.
If there are others who you wish to collaborate with, it makes no sense for them not to also have Scrivener installed, meaning they also do not need non-Scrivener access to text files.
If there are people who you simply want to have read something you’ve written, it can be compiled in a matter of seconds using Scrivener to any platform they might need it on. So they also don’t need access to the text files.
Plus I see this feature as problematic. It does not retain the hierarchial folder/document structure when saved to an ‘external folder’ using this method. IOW, everything is all jumbled up.
There are 653 separate documents in that 180K-word novel I mentioned. If I try to access that in the external folder Scrivener ‘synced’ with (which is a complete misnomer), what I get is all of those docs in no particular order, other than how the Apple Finder can sort them. But they can not be sorted in the order they appear in in the novel, or in the Scrivener binder. IOW, this process takes the novel and literally makes a jumbled mess out of it.
So to me, this relegates this option to nothing more than an emergency backup folder. A last resort if every Scrivener version of the project is lost from iCloud, Dropbox, the local HDD and all archived external HDDs, which is a doomsday scenario with a microscopic possibility of even happening.
So this begs the question: Where is the advantage of having separate, loosely-organized RTF text files representing the documents inside a Scrivener project? If you and your collaborators and editors have Scrivener, it seems there is no advantage. If your collaborators and editors do not use Scrivener, it might be time for better collaborators and editors to join your circle, not to mention that the ability to compile in whatever format they might need is built in to Scrivener already,
And yes, I’m quite aware that this is not a backup method. It quickly proves itself not to be.
The project-resident-on-Dropbox method does everything one needs other than presenting the documents as RTF individually so they can be accessed by platforms other than Scrivener. Again, that seems like an ‘advantage’ not really necessary if you install Scrivener on the devices you own and use.
That ‘Dropbox first’ process actually has no disadvantages as long as the internet is available and separate loose-leaf RTF docs are not required, unless you decide to have lunch in some taco shop without internet and want to write or edit a scene while you eat. (Please don’t). If you are going to ‘meet the parents’ for a weekend and they actually have no internet, here in 2020, simply make a local copy to your HDD before you get on the plane.
And it also makes the project accessible to any device you own, simply by going to the internet. Plus it is a very solid backup method. And it does not have any cumbersomeness regarding delay in synced versions of the project documents or due to simply listing the documents in an order not congruous with how they are arranged in the Binder.
If none of that seems immediately obvious, I’d suggest Googling the Kübler-Ross paradigm and trying to understand the concept of denial.