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.


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– implements inline Tex attachments in their RTFD editor (also, see their demonstration–"). 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.


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

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.

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.

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,

Footnotes between lines would be fine for me but, as noted, I don’t use them much so don’t have a strong opinion.

I often use annotations to highlight text I’m going to replace later, so it’s easier for me if the annotation text is right where I put it. Before Scrivener I used bold type for this sort of thing, though, and I could easily go back if Scrivener’s annotations change in a way I don’t like.


Hmm… I’ve just been playing with this and there are implementation problems anyway. :slight_smile:

I used to use annotations like this when I started using Scrivener, but now I use the searchable highlights instead, with 5 different “flavours”. Annotations are really just annotations to the text, not the text itself. Maybe you will like the highlights as well. They can even be exported.

As for the footnotes and annotations, at first it looks strange to me to have them at this place, but then, imagining the hide and show effect it seems like an improvement. One has the best of both worlds. After all, I think I would like it more than the first suggestion with numbers.


Oh yes, far more people will complain than will praise. It’s one reason I’ve heard given for why some companies will give gifts when you’re an unhappy customer (a restaurant screwing up your meal will often give a gift certificate) because they know that if you enjoyed your meal you’ll tell one friend, and if you didn’t you’ll tell ten.

Anyway, I like the current implementation of footnotes; keeping them next to the text they’re associated with is one of the more logical implementations for the draft stage. It’s also the way LaTeX does it, and I like LaTeX :slight_smile:

I agree with the suggestion that making the text a lighter grey might help those who have lots and/or long footnotes, so they grab your eyes less when reading through the main text, but you can still read them easily.

Yeah, I think that any sort of system that moves annotations from their current position to some other place will defeat one of the positive aspects of an inline system–the ability to promote and demote portions of prose without disrupting its context. What would this look like in copy and paste? Right now annotations are just bracketed nicely. Any system of collapsing should work in place.

I had a rather silly idea. If removing the text is problematic, and it is not possible to retain the text and just make it so that it is not visible to the buffer, how about reducing its visibility through the abuse of formatting mechanisms? Set the text colour to 100% transparency and reduce the font size to 1pt. The average annotation would reduce down to a small pill size and look like an empty red box.

And to kind of reiterate some of the comments I’ve seen: I think that your development time would be better spent enhancing and creating peripheral functions, in the future. I know I’ve always been rather outspoken about hiding them, but since it looks as though it will still be a pain to do that in place, perhaps it would be better to look at things like the ability to select the footnote/annotation your cursor is currently in, or to get a list of them all. I think that over the (almost a year now), the aspect of hiding has become less important. It would still definitely be nice, but I don’t feel as though the current system is really broken anymore. I’ve become used to it.

I think the current system suffers from having a lack of “flash.” All that means is that it does not employ any of the fads or pet ideas that are currently popular, and so you get a lot of first-glance comments on blogs and comments. These past few years have been soaked in the concept of software bling. I blame “web 2.0,” whatever that means. People confuse a little zing with quality, and that is rarely the case. Scrivener’s annotations and footnotes are more like the serif font header of publishing, if you know what I mean. They have a lot of subtle power and stability. In the end they are Just Text that Scrivener chooses to view differently. It isn’t fancy or wild like margin notes or whatever else, but it gets the job done reliably and with a certain subdued sophistication.

The problem in every respect is the undo stack.

Here is another solution I have been pondering upon: if annotations or footnotes are collapsed, Scrivener could iterate through all such ranges of text and replace them with an icon. This icon would hold the text of the annotation until the annotations (or footnotes) were uncollapsed.

But this - as with Amber’s font-changing suggestion - causes problems for the undo manager. If Scrivener goes through and replaces all such text ranges with icons, what happens when you hit “Undo”? All of the text is now in different places, so the undo manager will become confused. You might suggest that at this point, “Undo” could undo the annotation/footnote collapsing… Okay, that would work fine - until you change documents. Suppose you collapse annotations in one document, then open another document. When you open that document, you will expect the annotations to be collapsed now, as the setting should be global for all documents in the project. Now, that document has its own undo stack - so maybe now you open the document and hit “Undo”. The undo manager will panic, because text that was there before is no longer there - having been replaced by icons - meaning that it could be trying to reset a range of text that is beyond the length of the text. Even if the undo manager does not crash the program, it most certainly will replace the wrong piece of text.

The obvious - easy - solution to this would be to reset all text undo managers when you choose to collapse or uncollapse footnotes or annotations. There could be a warning message the first time you do this.

And incidentally, if you don’t know what I mean by all of this undo fuss, you can already test it out - I just realised there is a bug in Scrivener which I need to fix for 1.04 along these lines. Open up a new project and create two documents. Enter text in both documents, then open them both up in an E.S. session and delete the text from one of the documents. Now open up that document on its own again, click into the text view, hit “Undo” and then - assuming Scrivener doesn’t crash - open up via Spotlight. You will see that Scrivener’s undo manager has spewed an error. This is because you edited text in Edit Scrivenings and Scrivener didn’t tell the text’s own undo manager about the change. The only way around this may well be that, upon entering an E.S. session, the undo stacks of each of the text documents in the session may need to be reset.

The problem here is really one with Cocoa, in that all of the undo stuff is handled at the view level. It is the text view that registers all of the undo stuff, not the underlying text itself. And thus the text has to be in a text view for undo to work properly.

So, to put it simply: I could very easily implement a system whereby annotations and footnotes are collapsible, but only at the cost of the undo stack for each document being reset when they are collapsed and uncollapsed. Of course, undo is hardly perfect in any app, so it may be that this is an acceptable cost for the feature, especially if there is a warning.

The other issue, of course, is that if you want to add an annotation or footnote and they are collapsed, Scrivener will need to uncollapse them automatically. The collapse/uncollapse thing would have to affect all of them.

Incidentally, another idea might be for footnotes just to be translucent until the mouse is over them. That would just be a display thing and wouldn’t have to touch the undo stack… But it would just be about softening the current implementation rather than doing anything different.


I’ll vote early and often for this idea. :slight_smile: I don’t think resetting undo stacks every time you view a footnote or annotation is an acceptable trade for the feature.


agree with amberv

also, i think current inline system is a feature of scrivener, not an annoyance/hindrance

Diminishing the visual presence without reducing the space it inhabits would be acceptable compromise. I think the main visual problem with footnotes is that they inhabit the same colour-space as regular text. I don’t mean so much skipping over them while reading the base text, as how much “distraction” your brain senses when staring at a page with a lot of mixed footnotes and base text.

I agree with dafu, making the undo system something you cannot rely on would be too large a price. It’s a pity Apple does not see the merit in adding more “overlay” style functions to a view. Things which can alter the base appearance of components, without messing with the undo stack. Like CSS display:none, which does nothing to the base text, but causes the rendering agent to ignore the element.


Probably teaching you how to suck eggs here, but if we bear in mind that footnotes are a nice to have feature, rather than a defining function of Scrivener, then I’m not sure it’s such a good idea to sacrifice the integrity of the undo stack (and now making it work completely differently to every other Cocoa application) for the sake of the footnote display.

It’s a tricky one.

May I make a silly suggestion?

Couldn’t you add a footnotes window to the inspector?

If they add a footnote, then switch to the inspector so they can fill it in. The footnotes for the chapter are displayed in a list. When they click on a footnote marker in the text, highlight the corresponding footnote in the list, where it can be edited. A nice touch would be to allow them to click on a footnote, and take them to the corresponding point in the text where the footnote applies.

The trouble with that idea is that lists - table views - don’t allow you to have attributed text. That is, text with bold, italics and so on. And I think may would not like the idea of plain text footnotes… It would also be a matter of how to represent the link, given that Scrivener already uses the blue-underline link for web links and Scrivener links, and how they would be represented… Not that it is a bad idea - I have actually toyed with it - I’m just not sure how it would work. Also, there is the issue of room available in the inspector.


No text attributes in List boxes? … :frowning:

I really, really like your idea of translucency for footnotes and annotations.

One thing that may be another reason to go with this is that you wouldn’t have to write a converter for existing Scrivener projects.


Actually, forget I said that - turns out I’m completely wrong; I’d just never tried it. :blush:

Inspector-based footnotes may be nice, although it sounds as though the folks who have posted here like inline footnotes. The other big problem with inspector-based footnotes would be how to represent which footnote is linked to which piece of text? Yes, I suppose it could be highlighted depending on the cursor selection. But then there is also the problem of keeping the order of the footnotes reflecting that of the text. Again, it could be done, but with a lot of shuffling.

So… What would people think of inspector-based footnotes?