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.
Katherine
Hmm… I’ve just been playing with this and there are implementation problems anyway. 
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.
Best,
Maria
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 
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 Console.app 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.
Best,
Keith
I’ll vote early and often for this idea. I don’t think resetting undo stacks every time you view a footnote or annotation is an acceptable trade for the feature.
Dave
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.
Anyway.
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.
Best,
Keith
No text attributes in List boxes? … 
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.
Dave
Actually, forget I said that - turns out I’m completely wrong; I’d just never tried it. 
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?
Keith
Okay, so this is how faded footnotes might look:
I suppose the same could be offered for annotations - just something to give them a less of a visual impact when you don’t want to look at them. I also wonder if the regular grey background for footnotes isn’t a little horrid… Maybe a lighter shade might be better.
(Just to reiterate, I’m not proposing this look for when you are editing the footnotes (eye-strain ahoy), but just as an option to fade them out when you don’t want to be distracted by them.)
Another option for the way this could be work is that the footnotes or annotations would be faded by default until you click into one, at which time all of the other footnotes or annotations would become unfaded, too… Just thinking aloud here.
Best,
Keith
Keith,
That looks great!
Agreed.
I think having a toggle would be useful as well as having them go opaque when you click to edit them.
Dave
I was going to suggest that, but figured it was too much work on your part. I use the Notes section for all my thoughts, queries, and reminders. So if I were footnoting, I could put them there as well.
However, if I want an EndNote item in a particular place, I just paste in the temporary citation, like this: {Girardot, 2001 #45} That preserves position and numbering order when formatting in Word.
You wouldn’t want to fade the footnote background too much, otherwise they could become visually confused with gray annotations. Or perhaps, if the background were reduced, some other indicator were used (such as a dotted or dashed border instead of a solid line).
I do think the fading looks good. It is much easier for my eye to find the next “base text” location when attempting to read over the notes. I also agree with your usability notes. Something like this:
A toggle exists to fade both footnotes and annotations, to allow easier reading. When in this faded mode, mousing over a note brings it up to full opacity, as does placing the input cursor within it. This solves two problems with one solution. (1) You can quickly read a note without changing modes, and (2) when you try to edit a note in faded mode, you are provided with a full opacity area in which to type.
Unfading all of them when you click or hover in one of them would probably be distracting. I am trying to visualise what that would be like. If you are focussed on one part of the page and just idling passing your mouse through text (as some do to read), having components all over the screen lighting up and disappearing might be a bit much, whereas we are not too distraught be elements doing that beneath our field of focus. I think handling this with a global toggle would be a better solution.
Yes, I think you are right.
Okay, so here is the proposed solution which I will start putting into practise tomorrow:
There will be a “Fade Annotations and Footnotes” menu command (in the Text or View menu, though? I suppose it is a View thing, but then it is Text related - I welcome user input on this; keyboard shortcut suggestions also welcome).
When the above command is unchecked, everything will work exactly as it does right now.
When it is checked, all annotations and footnotes will be blanched out so that it is easier to skip over them. They will still be there, but ghostly. (Ooh, now I like the idea of calling the menu item “Ghost Annotations and Footnotes”. )
If you click into an annotation or footnote to edit it when it is faded, it will un-fade so that you can see it for editing.
Un-fading when the cursor is hovering over an annotation or footnote could be a lot trickier, so I am not promising this, though I will look into it. (One of the reasons the old Scrivener Gold annotation system - for those who remember it - was scrapped was because of the glitchiness of mouse-over events in Cocoa.) Annotations and footnotes are text attributes (that is, custom meta-data assigned to the text in the Cocoa text system), so checking for them in a mouse-over event would be intensive. As the mouse moved, the text view would have to check the co-ordinates, look for text, then check the attributes of that text, then expand it to the whole range and then do extra drawing and formatting (for the temporary attributes assigned to the text). All in a millisecond. So on the whole, I think this last option might be a little hopeful… A click into the footnote or annotation would only be one extra step and much less bug-inducing.
All the best,
Keith
This sounds just fine.
I would be inclined to forget #5. As you say, mouse events are difficult and I’m not sure about having footnotes fade in and out as my cursor makes its usually wobbly and circuitous route to wherever it’s going.
Finally, I’d suggest an opacity level setting in the preferences. (Oh no! Not another setting! ) The reason is the variation in displays. Not everyone has color-managed displays and the opacity level that looks good on your monitor may be unseeable on another.
Dave