Ahem, margin notes...

Scrivener Wish List
1

Hello Keith,

After struggling with Word’s interface for many years, it was a revelation to me to find Jer’s Novel Writer. Its uncluttered and writer-friendly interface immediately fired my productivity.

One decisive feature in Jer’s is Margin notes. So easy to create or delete, follow the text and, most importantly, positively entice me to jot down those fleeting thoughts that I’d otherwise lose if I had to use a more ‘flow interrupting’ way of making notes.

Scrivener’s Annotations go some way in that direction but, being encapsulated in the text proper, they are a bit distracting in the text flow, to my JNW spoilt eyes.

I noticed that you said in a post somewhere that there’s be “no margin notes” :wink: No doubt, youve considered it very carefully. But it would be sweet to have some comparable, inviting way of making text-following notes in Scrivener…

Of course you might say, “OK, structure your work in Scrivener and then export it to JNW as RTF.” But I’m very much in favour of using ONE writing environment (except for final polishing and layout) and Scrivener has such a wealth of clever features that I’d probably not want to do without, after I’ve got used to them.

Best,

Joachim

2

Hi Joachim,

Thanks for your post. I actually spent about three months a couple of years ago coming up with my own margin note system, as I, too, was very impressed with Jer’s. It is a superb program. However, I eventually abandoned this system for various reasons. Certainly, one was technical - getting it working when you can view the text in multiple views, as you can in Scrivener, was somewhat problematic. But had I spent more time on this, no doubt all of these issues could have been solved. Ultimately, though, there were other issues. Margin notes force you to keep your notes short - long notes trail on way past the text you are annotating. And if you want to add multiple notes per paragraph, then suddenly your notes are nowhere near the text - so you can’t even view them next to each other. Having them inline means that they can always be next to the text to which they apply.

Of course, having them inline has other drawbacks - some users find it interrupts the flow of their text. Jer took the route that best suits him (and many users); I took the route that best suits me. When writing in Word, I always used square brackets to enclose a note to myself about something I needed to change (and I did the same thing for footnotes until I was ready to format properly). The current system is really based around this sort of practice. I don’t find it distracting because of the way I use them, I guess: they are coloured, so they draw my eye to them and I know I have to edit them. I take a snapshot to save a copy of the text as is (so that I can always refer to the annotations later), and then I edit out the annotations and replace it with the proper text. To me, annotations are transient parts of your text - post-it note reminders which you will tear off once you have done what they reminded you to do.

Jer’s is certainly a lovely program, but I don’t want to emulate it (I think Pages has already done that - have you seen its comments system?).

All the best,
Keith

3

Have either of you seen how Celtx does it? It’s a nice compromise, a tiny little post-it note that expands to reveal text when clicked on. Maybe there’s someway to make the inline annotation collapsible? btw, what is pages…? Cheers & thanks!

4

The trouble with CeltX’s implementation is that it has the same limitations as the old Scrivener Gold implementation - namely, that you can only ever view one note at a time. A lot of users said they didn’t like this limitation in SG. It necessitates clicking and working with the note away from the main text.

Pages is Apple’s word processing/page layout program that is part of iWork. If you check out the demo, you will see that their comments feature is very similar indeed to Jer’s margin notes - and Jer’s Novel Writer was around for a good while before Pages appeared. :slight_smile:

All the best,
Keith

5

SG had a similar system, though you couldn’t see any of the note at all. You highlighted a portion of the text, and added a note to the highlight. To read the note, you would hover the mouse over the highlight.

The primary problem with this method, or the icon or partial text method, is that it reduces your ability to skim notes at the same speed as source text, to zero.

During the edit/rewrite phase, being able to see all of your notes in a few seconds can be extremely valuable. It, through various mnemonic devices (such as colour and spatial, combined with the text in the notes), can rapidly bring you back to the state of mind you were in when you last looked at the document.

P.S. Yay for cross-posting identical information! And this one definitely needs to go in the FAQ.

6

When I first started using Scrivener, I was dead-set on margin notes—having myself been a longtime user of JNW. I have found that the party line about annotations ceasing to be a distraction does actually ring true. What I’ve realized is that the key elements of margin notes and annotations are the same: 1. they are directly linked to the text they refer to, and 2. they are treated as separate from the text by the app. The fact that they are inline is one that someone very quickly gets used to.

note: Keith, in full-screen mode, if Scrivener uses its own colors for text, annotation text gets clobbered too. Intentional? If not—fixable?

7

Yes, this is intentional. This only happens if you choose to override the text colour in the Preferences (eg. if you want green-on-black etc). The reason the footnotes and annotations use the text colour when it is overridden is really to ensure that you can read them. You can choose to have annotations in any colour, and you can choose to have the full screen background and text in any colour. It is very easy to imagine a situation where annotations and footnotes would become unreadable in full screen if you are using custom full screen colours - hence they take on the text colours. Hope that makes sense.

All the best,
Keith

8

Is it relevant to mention INSPECTOR > SUPPORTING MATERIALS > NOTES?

9

Makes sense. It would be nice, of course, for MY PERSONAL set up, to have annotations be in their original colors, but obviously not a generalizable case.

Though while we’re on the subject: the default burgundy-ish color scheme for fullscreen is bloody gorgeous. It’s silly things like that that make Scrivener more appealing at first glance—not only that, but I’ve gone about and fiddled with as many other apps that I use to replicate the colors. Very well played.

1 Like
10

I rather like the way my writing desk is set up, too. It is modelled after the way the light comes in through my orange-ish curtains in mid-morning, and strikes the page on my typewriter. :wink:

Whimsical, but it does look nice!

11

So? Put your money where your mouth is, and let the great screenshot thread begin.

12

Actually I was. :stuck_out_tongue: The default colour palette in Scrivener was at least inspired by my orange curtains. There is an old thread somewhere around here on BlockWriter that went into the process in more detail. Basically the idea was to attain simulated contrast instead of literal contrast, to best emulate the appearance and amount of eye strain the brain perceives when holding a sheet of paper in your hand. There was a lot of other ideas about the quality of the type itself, to better “embed” the type into the background (as well as subtle texturing of the background itself), but that ended up getting discarded as it was really only useful for something like BlockWriter, that had no “flip side” formatting to retain.

13

Oh yeah, I remember that thread. It was an interesting idea, though in practice I do wonder how many photrealistic textures a body could take. Did inspire me to search out more high-quality typewriter fonts, though, to no real avail.

14

Inline margin notes are interesting and useful from both a writing workflow perspective, and as a feature of a published (complied) book/paper/article/essay, I love books that have layouts built to include large margins and margin notes (with illustrations, photos, graphs, drawings, pull quotes, etc.). I can imagine a system within the scrivener interface that allows the user to link/unlink such notes to specific anchors (selections/links) such that the notes flow in-line with the scrolling text in the editor (or go static as they are shown in the present scrivener release).Thinking towards compiled output, I imagine that this would already be supported in RTF and PDF protocols?

zVCaZ.png
zVCaZ.png1502×1065 318 KB
zVCaZ.png
zVCaZ.png1502×1065 318 KB

images-3.jpeg

15

Scrivener is a writing tool, not a page layout tool. I can’t speak for Keith, but I would guess that this sort of thing is well out of scope for Scrivener.

Katherine

16

Did I suggest a layout tool? I am trying to figure out how to keep track of notes specific to a specific selection within my text. I am writing a book that demands illustrations and notes in the margins. Its not about designing the layout, its about creating and storing those notes/illustrations/images/diagrams while I work and having some intuitive sense that they are associated with the assigned passage in the text. Why oh why would people who choose to work in an environment as graphical as Scrivener find it so offensive when someone suggests yet another way to make Scrivener more intuitive and supportive of the writing process? Zero sum? Yes, some books are written to have margin notes and illustrations. I am writing one such book. Would be nice if the workflow in the writing environment was more closely bound to the output. And yes, I understand that Scrivener already faciltiates in-line notes and links,which is great, but the existing note affordances don’t allow illustrated notes that scroll in line with the text. That and the ability to compile for margin notes would be amazing. Again, I am not asking for a lot of control over the the specific layout of the margin notes as output to PDF, RTF, etc, just that there were some facility to do so such that my publisher would have a better programatic idea what my notes are and exactly which text they are supposed to be assigned to. Imagine that such notes could be assigned to user defined layers. I might for instance define an inline notes layer that is margin notes and illustrations that are to be included in the published book. Another inline notes layer might be workflow notes to myself. One layer might be for footnotes. Another for words/phrases/concepts to be included in the book’s index and or glossary. Yet another for bibliographic citations. I might define another in-line notes layer that is there only to communicate with my editor or publisher or a glossery colleague or co-writer. Filters would allow selective showing or hiding each layer or layer group.

Such a system would allow for unlimited flexibility and workflow and might go a long way to demystify the current legacy bound system which seems to present so many arbitrary note taking affordances each with their own variously confusing display, use, and intent idiosyncrasies.

17

I think what Katherine means is that this does fall under rather advanced layout. Achieving the sort of thing you post in your screenshots is far from trivial technically. I’m not even sure how that would be achieved in RTF - I don’t think it’s possible, and if it were it would require a complete rewrite of our RTF engine (because I use a modified version of Apple’s RTF exporters). It would be possible in PDF, but would require a whole new page layout system built, because it would involve having two rectangles on each page (one for the margin and one for the text) with a different layout in each.

It’s certainly not offensive to post such suggestions, though! It’s just that Scrivener is the work of a single coder (me), whereas big layout tools such as Word and InDesign have whole teams behind them, so this sort of thing has to be left to dedicated tools.

All the best,
Keith

1 Like
18

It may also be worth noting that this thread was started in 2006, and was a response to the type of annotation that existed in Scrivener at that time: purely inline. Inline annotations still exist in Scrivener, though now as a separate notation layer (as you put) to the inspector based comment list (see §18.3, Linked Notation, pg. 454 of the user manual PDF). The latter form is the implementation response to requests like this one made all of those years ago.

If you are aware of that mode of notation already, then my question would be: what material advantages are gained by pinning a comment’s text into the surface area of the editor, anchoring it visually to the text it relates to, and constraining its overall shape and size by the limitations of the area of the text that defines its context? Right now I can attach a 1,000 word comment to a one-liner stub document. While a page layout based margin note system could conceivably allow for that flexibility, I think everyone would agree the functional and visual result of that would be awkward. There are other scenarios that defeat the layout approach, such as packing fifteen notes into a single sentence, and having eighteen such densely remarked upon sentences in close proximity to one another. A non-spatial stack like ours doesn’t miss a beat—it’s designed for scalability and author-centric notation, not page-centric output.

Most word processors do work the way you describe. Footnotes are at the bottom of the physical page in a tiny font, notes are in little boxes along the margins. It’s an emulation of the constraints of paper designed for an environment that is built entirely around the constraints of paper. Scrivener has no such constraints; its model of text transcends output medium boundaries, and as such its models for approaching annotated content can be thought of a little differently as well. A linear but non-spatial stack of reader and internal annotation (footnotes and comments), which doubles as a bookmarking system for rapid navigation and is capable of collapsing all such comments down so that each instance takes up the same amount of space—to my mind these capabilities are all superior to the systems found elsewhere.

I think the aesthetic appeal of what is shown in your screenshots is undeniable. But aesthetics like that do come at a cost in most cases. Publications like that are going to most often by proofed page by page, just to ensure that all of the content boxes fit, that contextual information isn’t on the wrong page, that there are no collisions between boxes, etc. These are non-trivial problems to algorithmically solve—even sophisticated systems like LaTeX that can do the above, and might have, by the looks of it, in a non-real-time sense (minutes of compiling between edits!) will still require human operator proofing and oftentimes days if not weeks of tweaking the result—inserting a hyphen here, a vspace there, etc.

…point being: you probably aren’t going to get something as nice as that out of a real-time text editor.

Although I don’t think it is what you mean, we do indeed support the standard RTF comment on compile (and it should be a default in fact). You will get a result much like described above though,—little colourful boxes on a page in the margina area. I don’t know of anything that attempts to make notes look as nice as published output, for all of the above reasons and probably many more I am not thinking of.

19

Again, why the weird hyper protective objections to suggestions no more outrageous than any of the affordances that make scrivener stand out in comparison to other writing environments? “I don’t even think such a thing would be posible in scrivener”??? What does that even mean? What is it supposed to mean? Why was it said? First of all, I wouldn’t suggest a new functionality for Scrivener if it already existed. Second, every functionality in scrivener or any application only exists because the developer of that application wrote code that caused that functionality to function. To make inline notes scroll with the main text does not qualify as a metaphysical godlike act. Any vertically scrolling table or spreadsheet stands as sufficient example. Down at the foundational level, text field display routines are driven by far more complex logic and algorithms.

Again, I am not asking for layout control. I am asking for a simple one size fits all means of displaying notes that scroll with the main text of the document editor such that it is clear which margin text/illustration/image/URL/graphic/pull quote is associated with which linked selection of text in the main editor. I am suggesting that the entire confusing suite of existing species of notes could be replaced by a user defined note layer system where each layer is subject to its own attributes and that some of the attributes could control how such notes are handled in compile mode. Standard preset note styles might include 1. footnotes, 2, index / glossary / key words and phrases, 3. bibliographic reference citings, 4. notes to colleagues, editors, publishers, and co-writers, 5. workflow process and status, 6. margin notes, 7. margin illustrations, 8. pull quotes, 9, internal references (to other parts of the book), and, 10, Any user defined note type. All of which could be displayed or hidden, filtered, and compiled or not according to appropriate settings.

20

Not trying to speak for KB, but when the guy who designed Scrivener a decade ago and has single-handedly written the code for it says (effectively) “this is not a trivial problem” and points out he’s a single coder, not a dedicated team, that’s a big hint that the world’s greatest expert on Scrivener is saying something important and we might want to listen.

That might be the first disconnect. Scrivener, as with pretty much every other piece of software, is not written in a vacuum. It is written on top of a palimpsest of code, routines, functions, APIs, and layers. The scrivenings view – one of the core concepts in Scrivener – exists (as I understand it) because the Mac OS text system (the basic routines that allow a programmer to create, display, and manipulate editor controls with very little effort or code; lots of basic functionality comes for free by using that text system) made it fairly trivial to do. Not too many programs before Scrivener had made use of that capability, that I am aware of, but KB was able to focus on this new functionality and NOT having to re-invent the wheel as far as rich text editors, typeface controls and pickers, font controls and toolbars, etc. because all of those elements were already there. Windows doesn’t offer the same kind of text system with the same kind of features – so porting Scrivener to Windows involved a lot of extra effort (and choosing to use the Qt programming framework on top of native Windows so that Qt’s text system at least got the devs part of the way to where they needed to be) re-creating functionality Mac gave intrinsically.

There are many other cases – Mac spelling vs. aspell on Windows; Mac package format vs. Windows folder/files, etc.

So, Scrivener stands on the shoulders of those who come before.Each one of those design decisions and goals comes with its own set of compromises that in turn make certain other tasks/extensions more difficult. Using the RTF text system limits some of the stuff KB can do, because he doesn’t want to have invest the time to re-invent the wheel for some new rich text editing system that can do all (or most of the things) the current system does just to get the ability to more easily add on some of the plain text-favoring features that have been requested. There are only so many hours in the day. Is it in Scrivener’s best long-term interest to completely rip and replace code to do this new thing, with the investment in coding time (and no new features/bugfixes/etc. in the meantime) or say “no” to some features?

That’s KB’s call to make.

It’s not that you don’t have a vision of one possible way Scrivener could be, and could perhaps be made better. You do have such a vision, and it is a glorious vision. Nobody is saying that it isn’t. But when you share that vision, and long-time Scrivener staff and users respond in anything other than, “That’s amazing, get right on that!”, maybe something else is going on that you don’t yet have the perspective to understand. Is it really easier to interpret the feedback as “weird hyper protective objections” and make yourself feel more unique and special and clever, instead of maybe thinking that folks here have perhaps seen suggestions such as these before, have done the hard thinking required about how they would need to implemented and the cost/benefit ratio of that work and decided that while it’s a really nice vision, it’s probably not congruent to KB’s vision and the roadmap he has already publicly stated?

Nobody is trying to rain on your parade, friend. Nor are we trying to be obstructive. But there’s a whole vast, rich history with Scrivener and new suggestions, no matter how pretty or clever they are, are going to be judged against that whole tapestry.

It’s a fun tapestry, too. Looks like you’ve been part of it for almost a year now. We’re glad you’re here!