Full Screen Conceptual Issues

Hi,

There has been some talk about the new full screen mode, and whether or not it will allow user-customisation of the font colour as can Scrivener Gold. Although I have said that it will, I would just like to share the conceptual issue involved here:

To the best of my knowledge, all, or at least most, other writing programs that have a full-screen mode do not allow the user to edit font colours in any mode. Scrivener, however, allows full rich-text editing, and in the new version this is enhanced further by the implementation of annotations and footnotes. Annotations and footnotes are displayed inline and then exported as comments and footnotes or endnotes; when they are displayed inline they mainly rely on colours to distinguish them from the main text. Here are a couple of pictures I posted on the old forum:

Footnotes and annotations in Scrivener:

Exported to Microsoft Word via RTF:

Now, when you launch into full screen, implementation-wise there are two options:

1. Override all font colours and replace them with the temporary colour that the user has selected for full screen.

2. Do not override any font colours.

The first option means that in full screen you will not be able to differentiate between annotations (you will be able to distinguish annotations from normal text because annotations have a thin outline around them). You may have some annotations that are coloured red and some that are coloured blue, and these colours may mean something to you - but in full screen these colours won’t be there. And of course, any other text that has a different colour will be displayed using the full screen colour in full screen mode.

The second option means that you are limited on background colours.

I think the best option would for all of this to be covered in the full screen preferences, but would welcome opinions.

Geez, Keith, you are making me nuts with having to wait for this program. You don’t know how long I’ve waited for something like this—to be able to do footnotes, annotations, the ability to do project-related research with multimedia, all of it, all in one program with this kind of format! Okay, maybe you do, since that’s why you wrote Scrivener.

As for writing programs and customizing font colors, DT Pro isn’t really a writing program, but you can customize font colors in full screen as well as background. Not sure about others.

Anyway, an interesting situation. Of the two options you presented, I’d pick option 2, understanding that it would limit my background options.

Option 3 would be to be able to change font colors for annotations as well in full screen, but that could be adding too many layers of customizing.

But I would absolutely want/need to know what is what in full screen mode. One of the reasons I can’t really use WriteRoom all that much is that I need footnoting in my non-fiction writing.

So, I’d be willing to have limited options for backgrounds to have differentiation for annotations, while for others who don’t need annotations, they could select whatever they want. That would work for me, anyway.

Alexandria

This is, of course, where the idea of having annotation labels as well as colours would be handy, but as I think I recall you saying, implementing labels was too difficult for round one?

If not, I really do think they should go back in. I doubt I’m the only one that has more than two types of annotations. I am probably extreme in that I have over two dozen static ones (and perhaps a dozen further which are specific to each novel). Colours just aren’t going to work in that scenario.

Back to the issue, it would solve the “monochrome” problem. Sure, they do not pop out as well visually, but at least you can see when something is a footnote/endnote or not. But, yes even barring labels, I would prefer monochrome myself.

Hmm, what about making footnotes/endnotes border a dashed or dotted line instead of a solid one?

del

Well, I can appreciate that many writers don’t need the footnoting in Scrivener. I myself have dearly wished for a program such as this that can implement them. If I have to do really extensive footnoting such as what Maria described, it wouldn’t be in the kind of thing I’d be writing in Scrivener. I see this program serving my fuctions for all fiction and short non-fiction monographs, which is where I’d need the footnoting. I write quite a bit of the latter and would very much prefer to use Scrivener for these. Anything more extensive, such as something involving complex footnoting, and I’ll be using Mellel.

So myself, I really look forward to footnoting in Scrivener, inline or via some other system.

As for full screen and annotations, as long as there is a way to tell what is what, it will work for me! I know others feel differently, but I’m not really all that concerned with changing backgrounds, etc. Font size, yes. Margins around the text, yes. Colors, no. I like the white/off-white background, dark font approach. I liked AmberVs whitish/pinkish coloring myself (posted in another thread).

So that’s more of my two cents! I guess that makes it four cents!

Alexandria

del

The original documents describing the future annotation system, and the addenda on Keith’s implementation, are unfortunately not on this new forum system. In the original concept, an annotation or footnote had a label at the beginning, which was offset in a nice looking OS X style “pill,” and could be changed (with auto-complete) while adding it. Footnotes would simply be a special kind of annotation, but functionally no different. The key thing that allows an inline system to be useful is whether or not you can hide the extra data. Part of the original model was an intuitive system for hiding, part of which I never finished drafting because the implementation was becoming too complex for version 1.

The whole concept of footnotes was a bit of an after-thought to the original idea, which was designed to replace the need for margin notes or the style of note that SG has. We just thought, if we have typed annotations, we might as well allow special functions to be applied to certain types, why not just pipe a footnote system through the existing framework. I think this way of doing it is, like you said, better for light usage, such as in fiction. There is no connexion to any bibliography database software, or anything, and I certainly wouldn’t want to write the House of Leaves with it.

I have mixed feelings on the lack of hiding. In my opinion, it definitely should be a temporary situation. While I do not footnote as much as you do, Maria, I definitely do annotate 60%, and that probably is not an exaggeration. So I am mildly concerned about what my documents are going to look like in version 1. On the other hand, I understand it must be a pretty complicated thing, and I’d rather have a beta at the end of the summer without hiding, than a beta in December with it.

The idea for a system of hiding would be “tri-modal.” You could either have all shown, all hidden, or manual. Manual would be persistent, which means if you manually opened up a footnote, and then chose “hide all,” the next time you went back to manual mode, it would remember its state. There were a lot of details such as the visual model for how this would look. When manually closing an annotation, the label would have remained visible, with a little arrow to help indicate its state. Clicking on it would open and close it (with keyboard methods too, of coarse). However, in “hide all” mode, every annotation and footnote would be reduced to a small bullet, so you could see that something was there (for purposes of bulk operations on text), but it would be completely out of the way, visually speaking. In “hide all” mode, hovering over a dot would open it until you moved the mouse out, like a tool-tip. There were a lot of other ideas too, and areas that needed to be refined as far as intuitive operation goes. Having three modes could be confusing if implemented poorly. Right clicking on a label type and choosing to hide/show all of that type. Things like that.

And of coarse, none of this was ever fully ratified as going into the software (in fact, like I said I never even published the full details of the above paragraph). So I am certainly not speaking for Scrivener, just what part of the original concept was when we hashed out the “inline” idea a little under a year ago. What you see in the screenshots is about a quarter of that idea (from the users standpoint).

But, hopefully once version 1 comes out, and K. has the time, we can get proper hiding and labelling.[/u]

When I work full screen, I tend to think of it as switching from color to black and white (or white on dark blue, in my case). It helps my eyes, and my concentration. So, I would suggest that when the user switches to Full Screen, all the colors are rendered either: 1. As the customized font & background colors, ignoring nuances; or, 2. As shades that go from the background to the foreground. I like the first option better.

del

Hmm… Annotations and footnotes. They will be inline, end of story, I am afraid. The reason for this is simple: Scrivener will not offer a page layout view (because it is not about layout), so it doesn’t have pages at the end of which to put your footnotes.

Although I did consider Amber’s excellent suggestion of “pill-buttons” that you could use to collapse or expand footnotes and annotations, I decided against it. Primarily this is because it would mean an enormous amount of customisation to the Cocoa text system. Getting a roughly-working prototype I did in a couple of days; but I soon realised that it would take weeks or even months to get a fully-working version going.

Moreover, I thought about how I saw annotations being used. I can see that they might get unwieldy if you want to leave them in your document forever and ever. But I don’t see annotations as beign used like this - even if you do want to keep them so that you can track the progress of your work. Instead, I see annotations as working like this: You draft your document, and use an annotation to make a quick note about something you need to change, or an idea you want to put in. Then you print off your document with a mind to editing it, with the annotations inline if you want. Next, you go back to edit your document. You take a snapshot before doing so, so that you have all of your old annotations available in an old version so you can go back and check what you changed in the future if you so wish. And so on…

Thus, the annotation and footnote system will remain inline for the foreseeable future - although that doesn’t mean that I will not consider improving it once users have had time to test out and use the new system.

Hope that clarifies things a little.

All the best,
Keith

I just realized I could greatly use more than one kind of inline annotation. The reference management software I use (Bookends) will not scan “\citep{key}” when scanning a .tex file for purposes of generating a bib file. Until Bookends implements that, I think my route forward is to use “\citep” but to make the “p” an inline annotation. Then I can compile a .tex without including annotations, and use Bookends to produce the bib file. Finally, I can go back to Scrivener and recompile the final .tex file but this time including inline annotation, so that the final .tex includes the “\citep” commands where I placed them. Problem is, there are other inline annotations that I would not like to include in the compile in any circumstance.

Did this capacity for different kinds of annotation ever make it into Scrivener?

This is very, very old thread you are responding to. It might be better to start a discussion on tactics in a new thread, so I’ll limit myself to describing where things went.

But no, inline annotations always remained something capable of casual typing—in that you can use different colours to establish visual distinction between types, or text codes (both conventions are supported loosely by the Edit ▸ Find ▸ Find by Formatting… tool). I have always used a bit of a combination of the two. Since colours are a lot more difficult to change than simply typing in some marker text, I reserve that for broad categories of annotation. I use one colour for all post-compile proofing marks, another for problems, etc. Within those colour groupings, I use text tags to indicate stuff in greater detail. “TODO//” versus “RWRI//” (for rewrite), both of which would use the “problem” colour. So overall, consider the types of things you’d put into annotations as a singular class of object. We can make distinguishing marks and conventions within that class—but ultimately they are an all or nothing tool, and thus best for all of the kinds of internal notes we might “scribble in the margins”. When I compile for production, I don’t want either todo lists, rewrite notes, screenshot guides, internal link anchors or anything of that nature in the output.

As for what you mean to do however, take a close look at what the Styles pane gives you, in the compile format design interface. Everything an inline annotation can do can be done here, and more, including deletion and prefix/suffix—but since each individual style can have its own settings, this effectively gives you what you’re asking for. You can have three or four different styles that are designed to hold different kinds of “inline comment”, and selectively choose which, if any, should be compiled. Maybe you have a set for the publisher, and another for proofreaders, or one for LaTeX output and another for simple PDF proofing.

Hopefully that gives you some ideas.

Yes, THANKS! That does just the trick. Pretty much decided to dedicate this book to you