Feature Suggestion: Indenting Scences (Sub-Scenes)

[chrisgrieser]

Especially for longer longform ( 😉 ), I would almost certainly create sub-sections and sub-sub-sections to organize the draft. Right now, the longform plugin only allows to order the scenes, but not to "indent" them or change their "level" (scene, sub-scene, etc.).

And further QoL features related to this are then to use the scene view as some sort of outliner by being able to fold the higher-level-scenes.

edit: of course, sub-scenes would also go with a compile option to insert heading levels according to the level/indention of the scene.

[kevboh]

I've definitely thought about this. It's not a short-term goal, but it's on my radar for sure.

[kenanmike]

I think I mentioned this on the discord just before release but this feature is way up there on my wish list for this plugin too. Probably number 1!

[jyhelle]

...and could we start at a "chapter" level, so the first level sub-sections would be scenes, etc (or alternatively have a mean to group several scenes in a chapter)
I currently use "fake" scenes to indicate chapter change

[akadormouse]

I use Writemonkey 3 with attached files jointly accessed through Obsidian (other programs too).
WM3 has longform, files (aka scenes), with the option of sections and chapters. (Also has compile equivalent).
Certainly for me, managing scenes without also having chapters (and maybe sections) would be difficult.
For the moment I can do that through WM3, but it would be useful if working in Obsidian to also have that facility there, so I support this request.

[kevboh]

To revisit this after linking here in #39: I've been thinking about this issue for a while now, and I think there are a few options here:

1. Scenes remain notes, but you can nest scenes in folders. This would mean that parent scenes would not have their own content—they would instead contain child scenes (and perhaps more folders which themselves have child scenes, etc.).
2. Scene level is tracked as metadata in the Index. This would allow arbitrarily nested scenes, each with its own content. I'm not totally sure what a parent scene with content + child would mean conceptually, though.
3. Child scenes are not notes at all, but instead headers (#, ##, etc.) correspond to scene index level and appear in the project sidebar, essentially reproducing the outline core plugin. Rearranging them in the sidebar rearranges those sections. This approach has the advantage of making it trivial to see a parent + all its children in one note, something I'm not sure I could reproduce within the constraints of Obsidian in the other two options.

I'm curious what others think of the above, and how they might fit use cases.

[chrisgrieser]

I think 2) would make most sense, since it wouldn't create unnecessarily huge folder structure when one uses sub-sub-scenes. It also has the biggest flexibility, e.g. concerning reading the data from the index via dataview.

I'm not totally sure what a parent scene with content + child would mean conceptually, though.

quite often, I do that for an introductory paragraph that explains what is going to happen in a chapter. (though this mostly concerns non-fiction writing, I guess)

---

re 3: I don't really see the value of reproducing the outline core plugin, since well, we could simply use the outline plugin. To see parent + children in one note, one could use partial compiles (i.e. compile only a chapter), or small support notes ´which embed other notes.

[akadormouse]

I have already switched to writing each project - article/book/series - in a single markdown file. This includes all the research, resources etc. I think 3 is the nearest equivalent to that.

A Scrivener file is a container which includes other files, and a single markdown file can be used in the same way.
It has the advantage of transportability (any markdown editor will recognise and understand the whole project) and simplicity.
But it can be substantially improved by adding management features. Organisation is needed whether you start with many small files and stick a manager on top or whether you start with one large file (with many sections and sub-sections) and add a manager to make it easier to work with. Obsidian itself has few features that help though the improvements in the Outline core plugin certainly help. It also has the advantage of not needing any work for printing or publishing since there are already many programs that will do that for a single file.

[ReaderGuy42]

I agree with @chrisgrieser, personally, I don't like having too much stuff in a single file.

[yogeshwersharma]

@kevboh - I am super interested in this. #2 approach seems the most flexible, and does not seem "too difficult" on the surface. Are there any technical difficulties in implementing this?

I am a programmer myself, and would love to help here if it is not a lot of work. If you have thought about this, and willing to share your thoughts, maybe I can contribute. Let me know your thoughts.

[codyburleson]

I am writing to place a vote for this feature. I'm using little labels in my scene titles to denote the part they belong to. It sounds like Option 2 is a good option. I can see just making an .md file with only a title just to serve as the Scene delimiter.

[kevboh]

@yogeshwersharma unfortunately this feature gets caught up in a general need for refactoring how project organization works within Longform (#35). Project-level index files introduce sync bugs and a lot of boilerplate (e.g. draft folders for short stories), and adding more metadata to an index file I want to move to a different format is dicey.

I'm just now getting over covid (you actually commented on the day I tested positive, ha!), but plan on beginning work on both the project refactor and this feature in the next week or so. Once I have that work begun I am happy to see if there is parallel work to do, and if so, hand it off. Familiarity with typescript and Svelte, especially Svelte stores, is useful.