When I was a young, callow aerospace engineer, I worked for a supervisor named Neil “Out of Scope” Bergstresser. When the customer (NASA or the Dept. of Defense) came calling with elaborate features to add to whatever rocket engine we were developing today, Neil (bless his heart) would say “Out of scope.”
What that meant was that a) it wasn’t in the contract and b) it would be far too expensive to implement and maintain profitability. At that point, it was up to the customer to either give up or go to our sales department and negotiate a price.
What I think the official answers here boil down to is “Out of scope.”
L&L are not producing a page layout application. (Not in the contract.)
nor are they producing a substitute for MS Word. (Not in the contract.)
Even if they wanted to, the resources needed to develop and maintain an application that can do what you suggest are far beyond what L&L could bring to bear and remain profitable at this time. (Infeasible.)
It’s not about technical possibility—heck, I studied at a school where we did the technically improbable before breakfast; the technically impossible just took a little longer. It’s about feasibility for THIS software code base and resource availability for THIS software development firm.
And what I learned from old Out-of-Scope Bergstresser is that out of scope means out of scope. Period. I’m sure that L&L will take into account what you’ve asked for the next time they do a major upgrade, along with all the other feature requests that hopeful users post here (including me ). But at that time, it’s going to be a decision for them—they won’t have the resources to implement ALL the requests, because that is the nature of the universe. And they will pick and choose what they implement depending on where they see Scrivener fitting into the application market, the founder’s vision of where he wants to take the application next, and available resources at that time.
Are you personally willing to pony up the tens of thousands of dollars to get ‘er done?
It means that the world’s leading expert on Scrivener, its designer and developer, thinks he would have to create a brand new RTF system in order to do it. This might not equate to rewriting Scrivener from scratch, but it’s pretty close.
It’s hardly a “weird hyperprotective objection” to be reluctant to throw away 10 years of development effort.
Indeed, I was trying to explain that this particular suggestion does in fact require advanced layout features and it is not in fact one problem, but several, because any addition to the editor has to work not only with scrivenings, regular mode and page view, but also with each export format. So yes, this is indeed “out of scope”. I was trying to explain the reasons why this is out of scope, but I think I would have been better simply saying: Thanks for the feedback. We’ll take it under consideration when we think about future updates.
None of what I have suggested requires any layout features at all. None. its just a display and user input affordance. That and a compile protocol that can be shared to any pre-press or layout program that can handle margin notes, foot notes, bibliographic referencing, back matter index/glossary/etc. and in-line pull quotes, illustrations, etc… At the coding end you have two user modes; one is scroll, the other is edit. During scroll, the user edit features are locked out. During edit, what is presented are objects. One is the main text editing field, the other, any side margin editing rectangle that notes occupy. The user selects text and asks for a note. The note box appears in an algorithmically determined position in concordance with he selected text to be annotated. The user types in the not box (or drags in some other media or linked media). The user selects from an in-note menu which note type they would like assigned (footnote, headnote, displayed margin note/illustration, pull quote, index, glossery, bibliographic reference, appendix, note to editor or collaborator, and or, any user defined note type), and from a secondary affordance, any settings specific to the note type selected. When the user goes to scroll or to edit the main text, the margin note is put in display mode where it can be scrolled along with the main text field it is assigned to. Scrivener decides how to display the notes, how the notes are edited and positioned. But the resulting compile can include publishing specific meta-data which can later be manipulated if the PDF or RTF or DOC default that Scrivener exports isn’t aesthetically applicable to the author or publisher. There would also be a display toggle that would allow the user to choose how the side bar displayed such notes, one mode would be the in-line margin notes that scroll with the main text, another would be the view now provided that allows all notes to be seen as horizontal bars (independent of main text scroll position).
Note: This is a suggestion, a “wish”, and has been posted to the “Wish List” section of the Scrivener Forums. It should in no way be construed as threatening or disturbing or fear inducing or demanding or coercive or not respectful or appreciative of Scrivener or the good people who have built it or who administrate its marketing and distribution and support . It has after all been posted by a customer, a person who choose and has purchased scrivener to be used as his ONLY writing environment, a person who is not writing suggestions to any other writing application forum wish lists. No one who reads this wish should have any worse of a day as a result of reading it. The world remains much as it was before I posted this wish. Scrivener itself has not been effected as a result of my posting this wish. These are simply words. They are words chosen and sequenced as a wish, to be posted in a wish list, a wish list provided for that purpose.
I’m not sure how this has an impact on what you are describing, but that isn’t how the Mac editing component works at all. You can try it—load up something with a bunch of text you don’t mind accidentally damaging, and scroll while pounding on the ‘d’ key. It’s all live—there are no modes.
That aside, I still don’t understand the nature of what improves with your suggestion, over what we already have. Pardon me if I misread, but I feel you dismissed my entire argument with the offhand statement “First of all, I wouldn’t suggest a new functionality for Scrivener if it already existed.” Granted, but my point was perhaps not understood, so I’ll break it down:
What you are have suggested is something that has been suggested before.
The current system we have now is a direct response to what you are suggesting.
Hence, in what way do we have it wrong?
These are constructive points and questions toward your ruminations: what could be improved about the current system that does not diminish its current flexibility and power, that would make it more like what you are thinking of?
Articulate what advantage there would be in binding note presentation to the current scroll view. I can think of some, but maybe I don’t understand well enough what you have in mind—because to my mind, the following advantages of an independent scroll view for notes outweigh any of the benefits supplied by binding note scroll views to the anchor text, by any means or form of presentation:
The ability to see notes outside of their context. If I’m looking for a figure that needs work in Photoshop and I’ve tagged it in a previous editing sweep, I can see it at a glance in the sidebar, click on it, and be taken straight to the image.
The presence of that metadata—the awareness that one gains by looking at a note that reminds them of Photoshop work, is something I acquire no matter what portion of this text I’m working on. With the fixed attachment model I must scroll the viewer to the very figure itself before I am made aware of the need for fixes.
The ability to jump from one note to another by kind. Using colour or other text-based markings, I can readily identify a sequence of non-linear notes that pertain to a thread of edits or thoughts—whatever I need of such a capability—and leap frog through the source text by that particular strain. I can even do this with the arrow keys when the focus is in the comments pane.
Because of some of these capabilities, our comment system can be used to go beyond mere comments. They can serve as a bookmarking system, an object referencing system (mark all tables in orange, all figures in red) and so on.
The many advantages I listed in my prior message that haven’t been remarked upon in your response:
[list][*] Lack of constraints in note size to body text ratio.
Decreased lack of constraints in note density to body text density ratio.
[/*:m][/list:u]
You might say it is possible to have both—I think Word does in fact, have a stacked comment viewer along with the spatial marginal model. Yeah—one can do that—but I feel there should be a very strong advantage to having such a duplication in the feature set. To my mind, word processors that have a subsidiary stacked viewer somewhere hidden are basically just responding to the limitations and weaknesses of the strict marginalia approach—it’s a concession. Scrivener cuts out the fat and just provides the interface that works simply and elegantly.
And to be clear about another thing, I am very well aware of the counter-cases where some of the above aren’t desirable. I for one am a very strong proponent in surface layer notation that cannot be easily avoided, and notes that are obscured by the bulk of the text they pertain to, rather than being omnipresent. That is why I myself use a huge mix of inline annotation and sidebar comments. I use the sidebar when the above advantages of very much desired, and I use inline footnotes when I want notation and text to be very tightly coupled.
Would I prefer inline notation off to the side? To be honest, and rather emphatically, no. I like being able to use the full editor width for my notes—the same formatting context you might say. I like being able to type as much as I want. I like being able to slip in and out of notation while writing with no more friction than can be had slipping in and out of italics while typing. I never have to reach for the mouse to switch columns are text controls. I never have to click on a tiny triangle to open a bubble. I very much like that anchor text can become notation with a simple toggle and vice versa. And after around twenty years of using various inline notation mechanisms and implementations, I have no problem at all reading around them, either.
So from where I sit: margin notes would be a downgrade for either inline notes or comments as they currently stand. If one system were to replace both, and all of the necessary design, development and testing that goes into such an endeavour would embarked upon, I would hope at a very minimum that the result would not be less than what was started with.
So—again, I must ask, “…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?”
This isn’t a hyperbolic defense of what exists. This isn’t a shut down. This is a conversation. That’s what we do around here. We talk about ideas, and sometimes these discussions lead to material gains in the software.
The strange comparison to NASA rocket parts production… talk about" out of scope". Such projects had a defined and ultra narrow focus, and that focus was static and defined in the past. The market was a directive from a president or some such resources allocation committee on a per project bases. Compare to scrivener which is a consumer application that is successful to the extent that consumers choose it over other competing products. There is no “scope” as defined by a president or authoritative committee. There is simply the prediction of market demand in a marketplace that will include products produced by other producers behind closed doors. Success in such markets involves meeting future demands in a future marketplace where any one producer can do no better than make educated guesses as to the products offered up by competitors. Right now, in the low bar market place dominated by Microsoft Word, and by other minimalistic linear text editing environments, Scrivener offers workflow affordances and environments that set it far afield of most of its competitors. Sitting pretty, as it where. But the future of the marketplace will certainly be occupied by new products that attempt to do what scrivener has done… which is providing tools that map to the specific needs of long form writers. The “scope” a consumer facing company must constantly pay attention to, is that difficult to predict and constantly more-sophisticated and more elegant products introduced by other groups trying to out-predict each other. The project scope isn’t defined and static. Such a process is very much NOT “rocket science”, It is actual science, it is driven by prediction. Prediction assumes ever shifting and ever accelerating change, in an environment that becomes ever more fluent in the process of prediction.
I simply can’t imagine the productive incentive involved in going through these wish list posts and criticizing the wishes posted or the authors of those wishes… for being too wishful.
If you would just expand your ideas beyond a couple of pithy one-liners and explain yourself in at least a little detail, maybe it wouldn’t be so easy to scroll past your posts without noticing them. :mrgreen:
Apparently this needs to be re-read by some so I will repost it:
None of what I have suggested requires any layout features at all. None. its just a display and user input affordance. That and a compile protocol that can be shared to any pre-press or layout program that can handle margin notes, foot notes, bibliographic referencing, back matter index/glossary/etc. and in-line pull quotes, illustrations, etc… At the coding end you have two user modes; one is scroll, the other is edit. During scroll, the user edit features are locked out. During edit, what is presented are objects. One is the main text editing field, the other, any side margin editing rectangle that notes occupy. The user selects text and asks for a note. The note box appears in an algorithmically determined position in concordance with he selected text to be annotated. The user types in the not box (or drags in some other media or linked media). The user selects from an in-note menu which note type they would like assigned (footnote, headnote, displayed margin note/illustration, pull quote, index, glossery, bibliographic reference, appendix, note to editor or collaborator, and or, any user defined note type), and from a secondary affordance, any settings specific to the note type selected. When the user goes to scroll or to edit the main text, the margin note is put in display mode where it can be scrolled along with the main text field it is assigned to. Scrivener decides how to display the notes, how the notes are edited and positioned. But the resulting compile can include publishing specific meta-data which can later be manipulated if the PDF or RTF or DOC default that Scrivener exports isn’t aesthetically applicable to the author or publisher. There would also be a display toggle that would allow the user to choose how the side bar displayed such notes, one mode would be the in-line margin notes that scroll with the main text, another would be the view now provided that allows all notes to be seen as horizontal bars (independent of main text scroll position).
Note: This is a suggestion, a “wish”, and has been posted to the “Wish List” section of the Scrivener Forums. It should in no way be construed as threatening or disturbing or fear inducing or demanding or coercive or not respectful or appreciative of Scrivener or the good people who have built it or who administrate its marketing and distribution and support . It has after all been posted by a customer, a person who choose and has purchased scrivener to be used as his ONLY writing environment, a person who is not writing suggestions to any other writing application forum wish lists. No one who reads this wish should have any worse of a day as a result of reading it. The world remains much as it was before I posted this wish. Scrivener itself has not been effected as a result of my posting this wish. These are simply words. They are words chosen and sequenced as a wish, to be posted in a wish list, a wish list provided for that purpose.
Randall, did you read AmberV’s very gentle, non-combatitive and nuanced post, or if you did, did you understand it? We have had this same conversation many times, and even so, you have got detailed, thoughtful and open replies from the core of the Scrivener team. Shouting the same thing irrespective of what others are saying is not the optimal way to engage in a dialog, nor is not being willing to listen to people that have different needs to you, or assuming we are all thought-police patrolling to enforce the status quo.
I dislike inline annotations, they do not work for my way of working. But I appreciate they work very well for others, and though I think I argued to be able to displace them from the text many moons ago, I accept that would have blocked other users preferences (we could add a prefs toggle, but Scrivener cannot just add every feature imaginable). I do use inspector footnotes and comments extensively, and I like that I can control these at compile (especially in V3). So a question: would the footnote/comment inspector interface work if it would auto-scroll to match the current location? Or do you really require a visual hook of the same “page”? There are many problems with laying out margin notes, even in the editor and this is really not a trivial task (I’ve used Tufte’s designs several times for Scrivener projects and auto-layout often breaks for anything that is not a brief entry). The inspector may be a workable half-way house, although even there there are some problems (only limited formatting is available due to technical limitations of the RTF editor that Scrivener uses)…
Side-margins do require layout. The whole of Scrivener’s editor and page view modes already use lots of layout. Perhaps we’re hitting a terminology barrier here? In order to show text, Scrivener has to lay out that text. In order to show a page view, as it currently does, it has to lay out many boxes, each representing a page, and lay out the text inside those boxes. In order to show footnotes, it has to lay out extra boxes at the end of each page and work out which footnotes fit on the page where.
To show margins next to the text such as you are requesting, my code would have to do much more lay out. It would need to add an extra box to the side of each page, and keep the two sides’ content in sync.
And it is far from trivial to incorporate this feature into exported documents, as already explained.
Yes, this is a wish list. No one has perceived your suggestions as threatening or as bad or anything else, so I’m not quite sure why you are getting so upset, and I’m sorry that you are. But the way we work is that we read and evaluate each wish, and we try to respond to customers and let them know how likely it is that their wish is to make it into the software. As I’m sure you can understand, as a one-man coding team I simply cannot incorporate every single user wish. And even if I could, it would be undesirable because Scrivener has certain design scopes. In this case, your wish is, I’m afraid, out of scope because of the complexity it would add and of the completely different internal layout engine it would require based on your description and screenshots. (Again, please do not get stuck on the term “layout”: I’m using it to describe what would be required internally, not as in a layout or design app.)
Please do not let this put you off posting other ideas or feedback. We are grateful for all feedback and take it seriously. Scrivener has incorporated a great deal of user feedback over the years.
And yet the person who writes the actual code says otherwise.
Until you’ve demonstrated that you’ve written Mac OS and iOS applications at the level of complexity of Scrivener, your assertions are just that – assertions. Unvalidated.
So stop arguing with those people when they tell you it’s a much bigger request than you think it is. You are essentially arguing with them when they say, “That’s a bigger request than you think,” and try to take time to explain why. They don’t have to do that. So they’re taking time out of their schedule to explain stuff and you’re essentially pulling a toddler moment of “nuh-uh!” How is that in any way respectful of their time and expertise?
If you really think the way you are coming across is respectful…you have a different definition of respect than most people do.
I am in no way arguing anything but that it would be really really helpful if the notes, footnotes, metadata, bookmarks, comments, links, research materials, citings, bibliographic notes, index notes, related images, illustrations, tables, URL’s, pull text, asides, working notes, notes to colleagues and co-authors and editors and proofreaders and publishers, if side stories, technical material, equations, structured data, etc. would scroll with the body text as it is being composed and edited, and if the author could filter which categories of were shown or hidden, and which were to be included in compiled exported published documents.
That it would be difficult to provide such an interface and behavioral affordances (I assume it would be difficult, all software building is) in no way impacts my preference to have them be a part of the scrivener environment.
I would also like it if scrivener provided searchable graphical overviews of writing projects that would include but by no means be limited to timelines, word and synonym occurrence and occurrence density, character and multiple character occurrence and occurrence density, geographic graphing of events and characters and things, semantic interaction mapping, so that the author could really get a 10,000 foot overview of their work in progress and its many components.
And again, that such preferences would require a whole lot of work by the scrivener development team in no way effects whether or not I want them.
Seems all of the arguments against margin notes that scroll with the text that they are linked to are implementation arguments… problems that arise from one implementation or another. But there are most certainly solutions to most any implementation problem, that is the purview and responsibility of the interface and interaction design process. Criticisms posted above mention the problem of large notes (solved by scrolling notes boxes, or by truncated notes, or by stacked notes, or some combination of all three and many more), mentioned the problem of many notes densely linked (see solutions above), mention the problem of consistent behavior across several body text writing modes (the solution of course involves the proper model/view/controller separation and articulation), and mention the preference of some users to write notes directly inline within the text proper of their manuscript (the solution is, that this always of course remains an option). Also, the user of course could indicate a preference for or be provided with an option to view their notes any which way they wanted (the way they are currently displayed, or scrolling as margin notes). Granted, the actual implementation of this gestalt in any real software project is not trivial. Introducing it into a mature product even more problematic. Real software projects always of course drift afield from every strict adherence to architectural best practices rules.
As you said, there are potential solutions to any implementation problem.
On the other hand, all implementation decisions must balance a series of constraints, notably developer resources and the ability of the existing interface to accommodate the proposed feature.
The author of the program has already explained, in detail, why the need to balance those constraints makes your requested feature unlikely. Continuing to belabor the point is unlikely to change his evaluation.
I do wonder whether allowing the comment/footnote inspector pane to update position based on where the active editor focus is would be easy to implement? I know I would certainly happily use such a feature if it was available, and though it ain’t full “margin notes”, at least it may be attainable…
I sat down and began writing my own code to track and then live align the vertical position of margin notes to the body text those notes refer. Not that insurmountably difficult in the test environment I chose to use. I’d like to hear the actual reasons why Scrivener is considers such a feature impossible or unreasonable from a development perspective, or unimportant from a user’s perspective. The closer my content creation environment mimics the look and feel of the finished product I am trying to create, the more fluid the creative process becomes. This is why I have chosen scrivener in the first place. This is why I recommend scrivener to others.
PS, one relatively easy way to implement such a feature is to apply a blind “Scrivenings” structure under the hood which effectively splits a text block into two virtual blocks at the beginning of any user-defined selection that the in-line margin notes are meant to refer. That way Scrivener could use an already implemented chunk of its own code to accomplish live display of in-line margin notes (vertically bound to the text to which they refer).
A gentle reminder to all that we are guests in KB’s house – that is, we are paying customers paying for the product as it is. Any updates, improvements, or additions that KB makes are entirely up to him.
Making a disconnected proof of concept to demonstrate any single feature in isolation is easy and straightforward. The real test comes when trying to integrate that change with all of the rest of the existing code, and KB is literally the topmost expert on the planet on the Scrivener codebase.
“It wouldn’t” is not an invitation to argue. It’s a judgement call we need to respect.
Let’s not make KB sorry he ever decided to write this thing, shall we?
It’s about feasibility for THIS software code base and resource availability for THIS software development firm.
I like being able to use the full editor width for my notes—the same formatting context you might say. I like being able to type as much as I want. I like being able to slip in and out of notation while writing with no more friction than can be had slipping in and out of italics while typing. I never have to reach for the mouse to switch columns are text controls. I never have to click on a tiny triangle to open a bubble. I very much like that anchor text can become notation with a simple toggle and vice versa. And after around twenty years of using various inline notation mechanisms and implementations, I have no problem at all reading around them, either.
