General discurssion on concepts

[kriptolix]

I was thinking a little about the concept of division into chapters and scenes and how it might be more interesting to have a less formal division of content.

1. Chapters and scenes are not very suitable for non -fiction content.

2. Even in fiction books, chapters are basically the grouping of scenes, sometimes with a title, sometimes with a number, sometimes signaled simply by a page break.

I like the subjective concept of "section" more, where a section is a subset of text of any kind. In non-fiction books, sessions are demarcated by titles of Title-0, Title-1, Title-2 and etc. A section may contain other sections.

In fiction books, chapters would be a sections with others inside (the scenes) and that do not have text in themselves.

My suggestion is that "chapters" and "scenes" were just types of sections, this would make the whole system more extensive and flexible to embrace less common things such as scripts and non -fiction work.

[cgueret]

Yep, I agree. We could rename Chapter into "Section" at least in the interface. Especially now that they can be nested - this was not the case pre version 1. I also see the point of having sections with or without text, and eventually containing sub-sections. But I think it is more convenient to have two distinct objects in the back-end but I'll think more about unifying them. The only "issue" that would come to mind right now is that content is tied to a specific "section" and I would not like to have the editor recurse into sub-content. So maybe then when editing a section's content the other sub-section of that section would just not be visible at all; or be displayed as some kind of ghost entry to remember they are there (like a header in pale gray). There would also be a small challenge in how to place the sub-section within the text; easiest would be at the bottom of the section's own text but giving more flexibility into that to the user will complexify things a lot I fear... :-/

That said, about your first point, I was really aiming at fiction writer for Scriptorium. I don't think it's beneficial to try to suit all audiences. For instance, I write scientific papers but would rather stick to Overleaf for that rather than move that workflow to Scriptorium. So it is not something I would aim at try making possible for other users. Just a personal preference... if there is a majority of users wanting that I would not mind re-considering my position. But for now I would consider that Scriptorium is for writing novels only (or similar content with some notion of scene and grouping of scenes).

Your second point will be expanded on in the "Publish" panel. Right now only the preview is implemented but the intent is to mimic a bit atticus.io and have there all kind of configuration options to let users choose if they want to see chapters header or not, with a specific font of their choice or not, with text, image, or no scene delimiter, etc.

[TheShadowOfHassen]

I do like the idea of abstracting the sections out to basically container and text object and have the ability to have them be nested. That way if you had a huge book like the storm light archive novels you could have your prologue text object, and then part one in one folder and all the chapters for part one are folders inside that one and all the scenes for each chapter are in each scenes.

However, I really don't think Scriptorum needs to be abstracted to a kind of general writing tool. The reason fiction authors gravitate to more dedicated tools is everything for them is already there. More specific apps made exactly for what you need are better (in my opinion, )than general omnibus apps.

That said, if someone else wants to take a crack at a scientific paper app for big scientific paper Scriptorum is GPL so they can always use it as a spin off for their own specific app for essay writing.

[kriptolix]

I wasn't thinking exactly papers or things like that. My question has more to do with the fact that I am writing an RPG book at the moment and sometimes having to deal with text sections that are not exactly a scene.

That said, I totally support the focus on fiction, I have the tendency to work all on a more abstract level because I think there will always be a case of use that I did not predict and I will be stuck in a definite structure and having to rewrite my whole software, is programmer neurosis, just ignore it please.

[cgueret]

Thanks for the discussions! I also know people that would like to use Scriptorium to write poetry books and, for them too, a poem is not quite a "scene". Though in that precise case it would be more debatable than for an RPG book, maybe. But I think we agree on having a precise focus and, as highlighted by @TheShadowOfHassen, leave other people with the option to fork and adapt the tool for other uses eventually. I do not either believe in the practicality of tools that do everything for everyone. So let's focus on making novelists happy :-)

Then we still have an open point about text objects and container objects. I would prefer keeping both separated for code simplicity and data model flexibility (clearer concept split). Shall we settle on naming the text object "Scene" and the container "Section" to make it more neutral?

We would end up with:

• "Section": can have a title and a synopsis. Does not contain text itself, but may contain pointers to other Section or Scene
• "Scene": can have a title and a synopsis. Contains text but can not contain pointers to other Scene or Section

Then when creating epub the top level sections and scenes are converted into "chapter" (as defined in the epub standard). In the "publishing" tab users will have options to decide how to render top level headers (show the title or not, show a "Chapter X" automatically created or not, ...)