Thanks MM. I actually typically do everything that you suggest; that way of workign has been fine when only using footnotes with a default of white. But the constant loading of comments and changing their color in the inspector is less than ideal.
I agree, the problem is how to remove the link during compile stage. I am not exactly sure how the inline annotations are removed during compile stage (depending on your compile preferences), but it seems like this might be feasible to do. You could potentially structure the symbolic link to work just as inline annotation, but the link would just be a static symbol… not text you could change. In that way, I think it would be even easier to isolate and delete (or replace with the inline comment/footnote) during compile.
There are three more things that I want to point out which I think could be real advantages to my suggestion:
-
Scrivener is all about non-linear editing, which is why we love all love it. But somehow, the footnotes and endnotes seem stuck in a very linear way of working, because they are tethered to the words in a sentence. I suggest you break them free of that restriction and use your same non-linear workflows to work with footnotes/comments. Specifically, if each footnote/comment is a symbol in the text, then I can copy, paste and even drag and drop it as I please. This would be nice, because I often use the same reference at several different places in the text. If you place the link to comments/footnotes to a symbol in the text, then you are no longer tied to the word itself. This also solves the great annoyance of when I want to change the last word in a sentence (the one that is underlined as a link to a comment/footnote). I can’t just delete the word, because I will lose the footnote/comment. So I have to go inside the link, and carefully replace the word with a new word in order to keep the same link.
-
If Scrivener ever wanted to simplify the redundancy between inline and inspector footnotes/comments, this would be an ideal way to do it. When clicking on the symbolic link in the text, you would go to the inspector as you usually do with the text link now. However, you could also potentially right click on it so as to expand the link into an inline annotation/footnote. In other words, with a little extra coding (and if you wanted to), you could share the content between inline annotations and inspector comments; similarly inline footnotes would be the same as inspector footnotes. You would be left with footnote and comments, very simply. How the user chooses to view those comments/footnotes is up to each user.
-
Finally, if you feel that you want to provide users more options for document markup (you would essentially go from 4 different types to only 2 different types with this strategy), I think you should generalize the whole approach to notes and allow users to add more categories. In other programs, this would be done by adding endnotes to comments and footnotes. For Scrivener, though, you could do something different.
I would suggest that you generalize the very concept of the footnote into a generic in-text note. Forget about all the these minor differences between footnotes and comments, let alone inline vs inspector. Just make a note in the text. Let the user define how many different types of notes they want to use (perhaps a maximum of 4 or 5 different types to start). Allow them to assign defaults for each type of note. They might assign a default color and symbol for one type of note, and a default symbol or color for another type of note. Some they may wish to display inline and some they may wish to display in the inspector as defaults. In either case, they would be able to click on the symbolic link and get to inspector, or right click to open the content of the note inline.
Finally, users would be able to assign each of their note types to an output during compile. Red notes might go into comments, white notes with an fn symbol might go to footnotes, those with a superscripted en might go into endnotes. But this way of working would actually be much more powerful than that. For example, a user might create a series of three different fn symbols in three different colors. At the time of output, they might output all three Scrivener note types to footnotes, but the black fn would result in regular footnotes, the red fn outputs footnotes that are in red text (to remind them they need further editing) and the yellow fn outputs footnotes in yellow inline text as references that need to be double-checked.
I think this way of working would be very much in line with Scrivener’s non-linear editing style. Rather than trying to replicate what other programs like MSWord do, it would provide far more functionality in a much cleaner, intuitive design. You would get rid of your four types of markup at present (inline/inspector comments/footnotes), and have one button for a “Note”. You could perhaps replicate this button on the toolbar in a different color if you chose to add different types of notes in different colors. It would provide a completely generalized perspective on note-taking from the user perspective. At the same time, compiling the draft would be used to reduce the richness and variety of your Scrivener notes into the stricter confines of MSWord Footnote/Endnote/Comment.
Could be great, especially for academic writers and anyone else who is extensively commenting their text.
