FEEDBACK REQUIRED: Footnotes

Scrivener Scrivener for macOS
1

Hi,

One of the most moaned-about features in Scrivener is the footnotes (and annotations, for that matter). Before continuing, I hasten to add that Scrivener will never be Word, Nisus or Mellel, and will never do any true page layout (well, never say never, but it’s not in my scope for the foreseeable future), so don’t expect WYSIWIG footnotes or annotations. However, for 1.04, I propose the following, but would like some feedback:

(NOTE: This proposal has been updated here: literatureandlatte.com/forum … 1868#11868 - please read the new proposal before commenting.)

  1. I will rename annotations to “comments” or “inline comments”, which may be less misleading. Technically, annotations can be inline, but most people seem to associate annotations with marginal or linked notes, so I think “comments” may better represent to such people what this feature does. The way annotations (or comments) work, however, will not change - they will remain inline. I know not everybody likes that, but hey, you don’t have to use them. :slight_smile: Many programs have nothing in the way of comments at all.

  2. Footnotes: currently, the only difference between footnotes and annotations (aside from the way they are coloured) is how they are exported. A lot of users bemoan the fact that the footnotes are inline, and I think they have a better case than that against annotations. However, Scrivener cannot do “true” footnotes until the export stage. So the question is, what would a better system look like? Something that is somewhere inbetween the current system and “true” footnotes, presumably. Well, I am thinking of implementing something along the lines of how MultiMarkdown footnotes work. This is how it might look:

Essentially, you would select “Insert Footnote”. This would insert a unique number between square brackets at the insertion point, leap to the end of the text and insert the same number between square brackets with the cursor after it waiting for you to type the footnote. After you finish typing, you would hit another key-combo to return the insertion point to the place of the footnote marker.

So far, this sounds pretty much like any footnote system anywhere aside from the squared brackets. Except that you would be able to continue typing after the footnotes if you wanted - that is, they wouldn’t have to appear at the end of your document in Scrivener. Also, if you had the following text:

[code]First sentence.[1] Second sentence.[2] Third sentence.[3]

[1] First footnote.
[2] Second footnote.
[3] Third footnote.[/code]

And then you edited it, by cutting and pasting, so that it looked like this:

[code]First sentence.[1] Third sentence.[3] Second sentence.[2]

[1] First footnote.
[2] Second footnote.
[3] Third footnote.[/code]

The numbering system would not be updated inside Scrivener. This is because the numbers in the brackets are just unique markers, and not real footnote markers. Upon export, this text would become:

[code]First sentence.1 Third sentence.2 Second sentence.3

1 First footnote.
2 Third footnote.
3 Second footnote.[/code]

The only implementation issue I see so far is the whitespace that surrounds these footnotes - how to know which whitespace should be retained and which should not.

So… Thoughts and suggestions much appreciated. Please do bear in mind that resources are limited and that Scrivener cannot and will not do “real” footnotes, so please don’t ask. What I am asking for is how you would like to see a better pre-export footnote system to evolve, within certain technical boundaries.

Thanks and all the best,
Keith

2

Well coming from someone who does not use a lot of footnotes: My vote is for keeping it inline, I really like that system. Have you done any working tests of this method yet? It seems that in some situations, it might feel a little awkward to edit around a footnote block that is in between paragraphs. Hard to say without trying it.

3

No, I haven’t done any working tests yet, and it may be difficult to implement - this is just thinking out loud for now. Indeed, it may be post-1.04 if it is difficult, as 1.04 is slated to come out in the next fortnight - this is one of the last things on my list aside from several niggling bugs.

I’m surprised you vote to keep them inline - it seems a lot of folks hate the inline system. The system I have in mind is really a mirror of the way MMD does footnotes. One issue, though, is determining where a footnote begins and ends. Perhaps the inline system should remain for now…

Best,
Keith

4

I rather like this. It has Scrivener-style to it.

What would happen though, if you do a footnote right after a paragraph, add a paragraph and then go back to do another footnote for the first? In the suggested system your first footnote would be right after the paragraph but the second would be after the second paragraph.

How about simply making the footnote delimited by the []: marker and a paragraph return?

Another possibility would be to use the marker system but have the footnotes as “metadata” like document notes? The footnote repository would be in another panel of the inspector.

Dave

5

Hi,

I would like to have footnotes below the text. As for whitespaces or lines between text and footnotes the setting for whitespaces between documents in Edit Scrivenings or during export seems a logical setting to follow.

As for numbering, I see the reason for keeping the numbers static, and it may be that they won’t become mixed too much in short documents that will normally be set up in Scrivener. Still, it is puzzling, and I think only a try will show whether it is too puzzling and I would prefer the old inline mode instead.

Although asked not to ask, one might think of implementing a re-numbering command in a later version.

Although asked not to ask, would a change of the footnote system be a good chance to establish different footnote streams with a different marker system (just yes or no is OK 8) )

Finally I wonder whether setting up annotations / comments in a similar would not be a nice extension of this feature.

Best,
Maria

6

I vote to keep it as is as well… I think numbering, especially if it’s not updated when you move the footnote, will become more confusing than the current in-line method…

i think the current method has a good flow to it when editing, because having to go up and down (or even split window) between the place in the text and where the footnotes are would be a pain

at least keep it a preference to keep it as is

7

Interesting… It may be that I have taken a few vocal posts from users who hate inline footnotes as being more representative than they are. Certainly, the current system is easier to maintain and the new system has problems, and there is no real way that Scrivener can provide “proper” footnotes given that Scrivener doesn’t do pages. It may be that the current system should stay…

8

Personally, I dig the inline too. It’s a good way of keeping everything conceptually together.

Keith, what about tying it into the number-tagging schema? that way they get updated properly. For example, [$n]?

9

This is another vote for keeping them the way they are. If the footnotes appear out of sequence, then folk will just get confused.

If that is no longer on the cards, then how about something a little bit more straightforward.

If someone wants a footnote, then just open a dialog box and allow them to type the text in

If they want to see it, then hover over the marker and display it as a tooltip or something. From the posts I’ve read, the problem with the current system is that it appears to be too intrusive for a number of people. So the text of the footnote needs to be hidden until they request to see it.

But really, I prefer them the way they are …

10

Hmm… I am very sympathetic to the calls for reform in the current footnote implementation strategy, since I use footnotes extensively for academic writing. However, I would have to agree that this solution seems like it would cause more confusion than anything. I can definitely wait (as long as necessary) until another strategy can be found.

In the end, I use Scrivener to help me structure my dissertation, and the environment that Scrivener currently provides has made it much more enjoyable to WRITE, which I guess is the whole point. Given this, the current strategy is more than acceptable. In some way it might even be better this way. It has helped me cut down on longer footnotes and focus on the main text. This way footnotes are little more than citations (which is what I prefer them to be) and so little distraction when my eyes skim across them in Scrivener.

(I realize, of course, this doesn’t work for everybody, espeically in those disciplines where footnotes are considered part of the text, tend to be much more substantial, and as such can constitute a bit of a distraction in the current implementation.)

Chris

11

As I mentioned in another thread, I use Scriv for legal writing, which uses footnotes like a car uses gasoline. So really, perhaps a better tactic would be a sort of global “hide annotations,” “hide footnotes,” “hide both” toggle --apologies if this already exists, I never noticed it – and replace them with a little icon, flag, whatever telling me that there IS an annotation/footnote here, and if I want to see it, I can expand them.

But I really, REALLY like the way scriv does footnotes, because it means my eye doesn’t have to jump around the page when writing. So chalk me up for a “keep it as it is!” I mean, I like this so much I even started to lose my love of margin notes (a la Jer’s Novel Writer).

12

I don’t have much stake in this discussion, because in all my academic writing, I have avoided footnotes, preferring instead to write internal citations, endnotes, or bibliographical essays. Most book publishers loathe footnotes because of their cost and typographic ugliness.

Much of the time, you can make a primary-source citation like this (MD, 270). Or a secondary reference like this (Blount 1995, 234). That is preferable to a system that makes readers search the bottom of a page or the end of a book. As for footnotes that are discursive and argumentative, forget it: if the point is important enough, pull it into the text.

So I don’t mind if footnotes in Scrivener stay the same or change, since I won’t use them. In my view, they move us away from writing and into the Dark Side of formatting. :smiling_imp:

13

I haven’t needed to use annotations or footnotes in Scrivener yet, though it is something I’ve had to do extensively in the past when editing the English in various textbooks to explain to the original authors why changes were necessary or to pose questions.
To begin with I was doing it in-line, 'cos early versions of NWE didn’t support footnotes, and although conceptually I liked that, (i) it buggered up the page layout more than footnotes would have done, and (ii) I found my colleagues found it more confusing than when I could use footnotes.
On the other hand, we’re talking about Scrivener, not page-formatted documents like Nisus produces, and the functions are for whoever is using the app for their own writing and therefore are presumably mostly for their own benefit, not for the benefit of other readers.
I think that, if you do go the route of static numbered markers and separate notes, the possibility of confusion resulting from a large number of footnotes whose order has been changed is something to be avoided if possible. Furthermore, IMHO, the notes would have to be at the end of the paragraph where the associated marker was; having them at the end of the document, or in another document/the notes pane sounds nice, but I think could only lead to greater confusion when the paragraphs had been moved around. Disruption of the main text would only be slightly reduced on the one hand, but on the other hand, the footnotes would be less immediately accessible to the eye.
On those grounds, in spite of the fact that I haven’t used either yet – and thinking about it now, I could have saved myself some effort if I had used annotations or footnotes while working on the Nanputuo Temple translation – I vote for staying inline. But I guess that those who use lengthy footnotes would prefer them split out a bit, those that write short notes would prefer them inline.

Mark

14

This is really interesting!

Both sides of the discussion have valid points. The design goal is fluid writing (c.f. Blount et al) and you can truly justify both in-line and separate footnoting as contributors to it.

Since I now find myself veering toward the in-line camp, it occurs to me that the complaints voiced about it have to do with the interruptive nature of the citations. What if, rather than trying to hide them completely by whatever means, you radically reduce their graphic impact? Drop back the enclosing bubble to a 10% gray and drop back the font color to 40%. This way, you still see them and their contribution to the argument but visually they have nowhere near the “force” of standard text.

Dave

15

I don’t use footnotes as they are, since most of the venues I publish in use endnotes instead. For those, I’ve found that tucking the note into a separate document works very nicely: I can keep it with the text it references until the very end, then drag it to the Reference section.

Having notes appear in a block at the end of the text would be fine if I used them at all. The numbering is a problem, though. If you aren’t going to autorenumber correctly, then don’t number at all. No numbers is easier to deal with than bad numbers.

Katherine

16

I use footnotes extensively, and discursively. They are essential in my work to avoid distracting readers from the main structure of the text and thrust of the argument, as well as for mandatory (intellectual-property-related) citations and acknowledgements.

I think that Scrivener’s current implementation has worked very well in my recent work. I especially like being able to toggle whether text is a footnote or not, and being able to easily separate them into a separate Scrivening.

I would prefer leaving them as they are to having them appear below the text in any haphazard way. One thing that might be nice would be if they would collapse to a symbol or embedded image of some kind. For example, I like how iStorm–http://www.mathgamehouse.com implements inline Tex attachments in their RTFD editor (also, see their demonstration–http://homepage.mac.com/sryu/istorm/movies/babytexmathsmall.mov"). I wouldn’t want footnotes to appear in another pane unless rich text editing were allowed there.

I have some difficulty in the current implementation (1.03) trying to get the selection lined up with footnote text when I want to convert it back to regular text or move it elsewhere. If footnotes were markers of some kind, then perhaps I could just drag them to move them, or right click on them to get a contextual menu that would allow me to cut/copy/view/edit the contents of the note, or convert it to regular text. Still, I would not want to have to hunt for the note text somewhere below the text.

–Bryce

17

I have seen the argument to and fro and my two pennyworth is:

  • status quo
  • plus the inline footnotes being metadata so they can be seen together (like Keywords HUD) and re-used as necessary. In reports we usually have an appendix of referenced docs and this automatically has to include all those referenced as footnotes.

The same metadata suggestion also applies to comments: it’s v useful to include reference sources in text - but not export them. Again a pick list would save masses of time and referencing same doc in different ways

18

Before Scriver, I had always used word processors to compose text. Compared to something like Word, inline footnotes is a simple hassle-free system: no formatting or jumping into another pane or to the bottom of the page or another window or having to magnify your text because your footnotes are in a smaller font than regular text, etc, when you want to add or edit a footnote. Of course, this is the part of the point of Scrivener. Write and don’t format.

My general sense has been that people liked the inline system, but that it in some situations it could be too intrusive to the flow of the text, especially when many footnotes are required, or long footnotes. Better stated, the inline system facilitates writing because it is an elegant, uncluttered solution where footnotes can be written and edited in the flow of writing without any fuss; that is, right up to the point where footnotes become too long or too numerous that they frustrate the benefit of flow and simplicity which is the inline system’s strongsuit. Ideally maybe footnotes should be limited to cites. But in some disciplines footnotes can constitute half the text, not as any writer’s stylistic choice but as the customary or required practice. I think its really at the extremes like this where it becomes a problem. Aside from using Scrivener for writing fiction (where I don’t use footnotes though of course some do) I use it for legal writing. As has been mentioned above, legal writing requires a lot of footnotes. The cites themselves can be very long, and certainly numerous, to say nothing of regular footnote text.

Of the people who don’t like the inline system for reasons other than the problem of the intrusiveness of numerous or long footnotes, there seems to be a certain contingent that objects for formatting/layout reasons. For me, I don’t care. On screen, I just want the text to look simple and uncluttered so I can write without hassle or aggravation. Mostly the inline system accomplishes this. If you are an expert at formatting in the word processor of your choice, formatting/layout concerns while drafting are irrelevant because you are going to dump all that text into a template anyway, to be formatted very rapidly (assuming that you will be importing the text into a word processor). This is why power users of Word typically work in Normal view (as opposed to Print Layout view); they know what the document will look like in the end, so they don’t care what it looks like now. People that don’t use their word processor with this proficiency (and I’m not disparaging them; learning Word, or any word processor, was a maddening process that I only ever mastered because I once had to work as a technical writer forced to use Word) have a certain amount of discomfort when what they see is not what they get.

Dafu’s idea is an interesting one (reducing the visual impact of footnotes) because it gets at what is at the heart of the problem (distraction, difficulty in reading). But to go further, the ideal footnote system for me for Scrivener would be an inline one where footnotes could be globally shown/hidden with an unnumbered placeholder of some kind (like an “f”). Even better would be if each placeholder could also be toggled to show/hide the corresponding footnote. If this is not possible, I would vote to keep the inline intact (though maybe with Dafu’s suggestion implemented). I would also vote for a system that did nothing more than show/hide footers.

I was confused in your hypothetical where just three footnotes were used. Of course, when it comes to numbers, I tend to stop paying attention. But I think it would get confusing. It’s better to have to skip over footnotes if you don’t want to read them – which you can train your eyes to do – then to have to think about non-ordered numbers and corresponding non-ordered numbers. Then there was the issue of the white space in the draft text and where the footnotes go (again, I’m less concerned with what happens on export), and that the appearance of a nice, clean paragraph would be interrupted and interspersed with some ugliness. It just seems un-Scrivener-like.

To sum up, I vote for as-is unless footnotes could be shown/hidden either globally, but ideally globally and locally. The inline system is great except in extreme circumstances.

19

I am an academic for whom footnotes are integral to all of my writing. Scrivener’s footnoting feature is what has allowed me to make this my primary writing app - I love it, live in it, need it! I am sympathetic to the proposals for various ways to hide or toggle on/off footnotes if desired and would support something like that sometime in the future. But between the current system and Keith’s proposed modification, I would vote to keep things as they are (inline). The potential distraction to the eye caused by large blocks of gray notes (in the current system) seems preferable to a system that would potentially interrupt the flow of writing itself (using key combinations to shift back and forth between note and main text, not being able to easily see both together at the same time) since that ease is part of what makes Scrivener so powerful and effective. I would rather live with the gray blocks than add any additional steps or required thought or additional distractions to the writing process. For those who use footnotes extensively this could be a significant issue.

20

This has been very interesting so far, and not at all what I expected. I guess it shows that - until asked in a thread like this - the most vocal about a particular feature are those who do not like it.

It is also interesting that most users would rather a hide/show feature. This was, in fact, the original plan, but technical limitations have so far made this impossible. So, right now, I am pondering on other options. On further reflection, I do think that you are all right, and that the proposed non-updating numbering system would be confusing and clunky - and, from my point of view, somewhat problematic to implement.

So, here is another proposal. Most users, it seems, would like the annotations and footnotes to be collapsable, to have the ability to hide them. The technical limitations involved here are as follows: hiding or collapsing any text within a text view is incredibly problematic. The undo stack will look for text that is no longer there and will throw exceptions. Workarounds to this are hideous. Keeping a backing store of hidden text and trying to track the location to which it is attached whilst text is edited can be be expensive processor-wise, and otherwise generally hideous.

However, there is another option. Rather than the annotations and footnotes being perfectly inline, they could appear between lines. Take the following piece of text (excuse the “one one” typo, which should read “on one”):

This text has one footnote, which is represented by a simple superscripted “F”, and one annotation, which is attached as meta-data to the “RWRI” text. The footnotes and annotations are all collapsed in the above example. If you uncollapsed the footnotes, this is how it would look:

As you can see, the footnote text is displayed directly beneath the line to which it is attached. Further footnotes attached to the same line would appear beneath the first footnote.

If you uncollapsed annotations, the text would look like this:

The reason this would (probably) be easier to code than collapsing footnotes and annotations as they currently appear is that it is relatively easy to create extra space between lines into which to insert annotations. Of course, there are other problems, such as keeping the annotations and footnotes in the correct order as you edit the text, ensuring there is no slowdown in the text system created by this, and the issue of whether you would be able to click in the annotations and footnotes to edit them or whether they would just be there for display and a separate editor window would appear when you clicked on them to edit them (simply because, being displayed between lines, they would not really be part of the text stream). And of course, there is the issue that they do not appear directly after the text to which they are attached, and will break up the sentence that follows it.

Thoughts appreciated.

All the best,
Keith