Thank goodness. I know nothing’s perfect, but Obsidian is as close as just about any other piece of software that I use on a daily basis. It has almost all of the features that I put on a list to develop my own solution to this problem after years of looking for a tool that would work. I’m really hoping I don’t stumble into a gaping hole in my workflow, because I really, really want Obsidian to work out, both for me an generall.
One of Obsidian’s values is to be extensible and configurable to your personal approach and be as non-opinionated as possible. That’s how I’ve taken all the writing from the dev’s at least.
Btw on the topic, hierarchy can emerge in your network. It’s just narrowing the context & nodes you’re viewing.
To me a hierarchy is just another attribute/relation, just like a link is a relation. To really see the hierarchy is just another point of view looking at your notes, like the graph is a view or file explorer is a view.
So having the ability to view & explore hierarchies that are present in your network already would be a great option to have at your disposal.
3 Likes
The Obsidian editor has few features specific to writing or constructing a book etc. But there are many that would work well on the same files. Obsidian even allows files to be opened in external editor, though you don’t have to use that. For me it’s most productive to use Obsidian for a lot of early development and linking and other programs for the writing. You can have both open at the same time.
At some stage, I’d expect a plugin with such features but there’s nothing to suggest it will be any time soon.
1 Like
I don’t quite know exactly the best way to provide that option at the moment, but I think it could be done without imposing things on the user. It just relies on if the tags/notes communicate a hierarchy that emerged/the user apply via them.
I mean, if all I need to do is specify the order the folders should take in the book, as chapters, then that’s a problem that can be solved by python or shell scripts or something, as I’ve done in the past. And I can even tackle the problem of content associated with a chapter directly (like a preface, chapter quote or whatever) by using index.md or folder.md files in the build script. All I’m trying to ask for in this thread is the ability to clearly associate some markdown content with a folder.
Now that I’m thinking about this as a plugin, I’d be excited to look into the super-unstable plugin API to see how I might accomplish it.
1 Like
Do you see overlap with is plug-in idea?
To me it’s about doing “things” in possibly batch actions with folders, index or other attributes, from wherever you happen to be.
It seems like the supporting code might overlap, but possibly not the functionality itself. I don’t understand that plugin idea super well yet, but it does imply that folders are objects that can hold data of some kind, I think. If folders can be associated with / have data, then that would be enough support to insert markdown content into the folder directly, ie this plugin idea.
I could see that data being implemented in a lot of different places now:
- index.md
- folder.md, either child or sibling to
folder/ - yaml frontmatter of any of the above
-
.obsidian, though this would require any parsers to dig into the hidden project files in order to correctly assign folder markdown or folder tags.
I think one problem with the idea is that the files and folders are just constructs in the operating system. Tags are just content that can used by any program.
I see no reason why Metadata (or any other property) can’t be used to set display order in Obsidian, but I’m a bit dubious about formal folder links.
So you mean that there’s no logical tie between one file and another? Granted to an extent, but the semantic intent behind an index.md file is pretty clear, as it mirrors HTML file structures and is used in Hugo and possibly other static site generators, so I feel like that’s a pretty good bet.
But an index file is still just a file.
A program can choose to parse any index file before looking at other files in a folder but I certainly wouldn’t want index files popping up all over my file system. In fact, I really need Obsidian to leave my file system alone apart from adding, moving files and folders as I direct.
HTML certainly uses them, and I have them on all my websites, but for display and file management on the site, ie they are intrinsic to the system. But they’re not in OS files and folders. Wouldn’t be an issue if those files and folders were only used in Obsidian, but they’re not.
I think is mainly about the option to “use” folders (or any piece of metadata or condition) for “something”.
Often that something is explicitly to do with text/file content, but often it’s just a view.
Sometimes the view is so explicit/unique to Obsidian you may want it to be text in a file (such as an Index or MOC that was created via a folder) so you can use it elsewhere or interact with the text.
To me it’s just about giving the user options to do things with your files that would create value for them.
3 Likes
Exactly, and also why I moved this to Plugin ideas, so that it would be optional. I don’t want to modify the global use case of Obsidian, I want to make use of Obsidian in a way that provides is more efficient in my use case.
To @Dor’s point, MOCs are also just files. Even if you were using this Plugin, you wouldn’t be forced to add an index.md to a particular file, it would simply associate any existing index.md file with its parent folder. If the data backend is there for folders, like we discussed here, then another option could also be to use that as the place to manually associate any markdown file as the folder contents file. I don’t know what the user interface would be for that, but it could be an option for developing the plugin.
For me, the behavior that @Dor considers a bug (that the folder content is a file that exists in the filesystem, among the other content) is a feature. I need that feature, because I’ve already accepted that no markdown program no matter how advanced is ever going to build my manuscripts the way that I want, so I’ll always have to write my own build scripts. It will be massively easier for me to access the data for the folders if the data is kept the same way as all the other data. I’ve written build scripts for software like Scrivener before where I’ve had to wrangle reading their proprietary XML format to find metadata, then separately associate that with RTF files that are not clearly or directly linked to the metadata, then rearrange the data to the right oprder, and that’s not a process I would relish doing again. I’d much rather just parse the file like any other plaintext file, possibly accounting for whether the files are associated with a folder or not.
So I’d much prefer for the plugin to be optional both in that you don’t have to use it, but also that you don’t have to add folder content (however it happens to be applied). That would mean that it steps on no toes, and yet provides value to those of us who want to have some kind of content associated with their folders.
1 Like
Yeah, sounds like you have a good grasp on the a use case for folders that’s not often mentioned in this forum.
To me, folders are conceptually/metaphorically useful, albeit a bit archaic intrinsically when paired in an environment like Obsidian. (But they do allow separation, sort of like fencing or boundaries in a way)
But at the very least they’re another attribute that files can have (like a tag), and more metadata the only allows for more refined/explicit actions with your content.
Also, the vast majority of users are going to be coming from a world of folders.
It’s the native way OS file systems work.
Even note taking apps (at least the ones I used) lead to using folders, so the more options users have to “import” those folders into Obsidian and “do things” with that attribute/context the easier it will be for people to transition into the networked note taking world or get their PKM system up & running.
3 Likes
I too consider it a feature. I’ve no problem with optional plugins adding extra files to folders.
But I can’t see why you can’t do that now without a plugin. You’d have to deal with a potential clash of file names, but that should be all. Being simple files, you can do anything with them outside Obsidian.
So I think there are a few separate issues we’re discussing in this thread and it might be useful to differentiate them, for the sake of the devs being able to make sense of the proposal:
- Whether folders are valid organizational tools in Obsidian. I think most of us mostly agree that they are, and since they’re already supported in Obsidian, I assume the devs agree too.
- The association of markdown content directly with a folder, in Obsidian. This is the actual plugin proposal. It’s not asking for any further integration of folders really, just the ability to treat folders sort of like “chapters” or being able to describe a category with its own content instead of a separate, unlinked markdown file.
I think that #1 is necessary but not sufficient for #2. #2 is of course not necessary or sufficient for #1, thus it’s optional and should be a plugin if it’s includedin Obsidian.
As for #1, I can also see a use case for folders as mutually exclusive categories. There are ontologies where there are categories that don’t overlap. An instance of cat cannot also be an instance of fish (barring fantasy), for example. I deal with plenty of mutually exclusive categories in my own data, but I do also deal with overlapping categories too.
- Mutually Exclusive Categories = Folders
- Overlapping Categories = Tags
In an ideal world, I’d want to assign descriptive markdown content to both Folders and Tags, assigning content to Tags seems like it relies on backend data structures that may not exist at this point, so I left it out of the original plugin idea description for clarity and specificity.
This is not what I’m suggesting.
I don’t propose for the plugin to create any files. It’s for the user to decide what files to create. If the user wants to make an index.md file for a folder, I’d assume they do that the normal way for Obsidian.
What I propose the plugin actually do in the UI is as follows:
- hide any
index.mdfile from the file list or move it to the top of the sort order, so that it’s not cluttering up the file explorer - clicking on a folder with an index file shows the contents of
index.mdthe way clicking onsomerandommarkdown.mdwill show it in the editor / view pane. - (Optional, but high value) Allow users to link to the folder [[some folder]]
- (Optional, relies on #3 above) Allow the hover / mouseover plugin to show the content of links to [[some folder]]
5 Likes
I added the proposal to the op.
1 Like
Hello,
I am coming from Trilium Notes and because it is SQLite based it is possible that a note can also be a folder (containing child notes).
And although I do like the fact that obsidian uses simple files for the content, I do miss the possibility to have note content on a folder level. I use that a lot in Trilium.
Would it be an option to have for every folder you create in your vault a hidden md file is created in that folder (for example .foldername.md or maybe even a fixed name like .foldertext.md or so). And when you click on the folder the tree is not only opened but the content of that hidden md file is also presented.
My tree might looks like:
- Project A
- sprint 1
- sprint 2
- sprint 3
Now I have to create a sprint 1 file in my sprint 1 folder (which contains multiple files ect). That is not logically for my. Specially as you cannot force a note to be at the top of the child files.
For me this functionality would make my use of folder a lot easier and self-explaning because you define what you mean on a folder level.
I just thought this up and would lik e to know if anybody sees the value in this. Otherwise I might have to change my working habbits :-).
Let me know.
Kind regards,
JeRoen
7 Likes
- when a folder is created, a automatic virtual note is created as a hub
- when notes are placed into this folder, they automatically link to this folder/hub
Questions to consider
a. do existing links continue to exist when the note is moved to the folder
b. can a switch of some sort exist that allows you to allow/disallow the keeping of existing links to the notes being put into the folder.
1 Like
I am very much a fan of this proposal because it’s a 1-to-1 match for how basic HTML page structure works (for example, going to whatever.com/heres-a-thing/ will attempt to load whatever.com/heres-a-thing/index.html on most web servers), which would make this use also directly correspond with using tools like Github Pages that translate nested folders of Markdown files into nested folders of HTML files.
6 Likes
This is a very similar concept to page bundles in hugo. CC: @ Roadie
It’s a fantastic idea and would be an ‘official’ implementation of the work-flow that i’ve already started to create w/ Obsidian.
I have a Projects vault with each sub-dir being an actual project which leads to:
Projects/project-1/Overview.md (this has many back links to the many other notes in the project-1 dir
Projects/project-2/Overview.md … etc
The overview page is usually a quick glance of status (blocked, in progress, back burner…) and any remaining milestones and links to the document where the idea is described and the architecture fleshed out.
w/r/t the zettelkasten work flow, I absolutely expect that future notes for future projects will link to notes in current projects. For example:projects/project-long-running-thing/2020-03-01_production-issue-with-SomeProcessSpecificMachine.md might describe an issue and eventual solution. It is likely that future projects will later encounter the same or a similar issue.
The reason for using folders is simple:
- it’s how a lot of people think about taxonomies / storing their info and data.
- it’s also much easier for tools and scripts outside of
obsidian.mdto manage files this way. - file systems (and, sync tools!) can choke if there’s a ton of files in one directory. I don’t think that most people will have 100K+ files in one dir, but it’s a potential issue that goes away as soon as you split those 100K files across a few directories.
w/r/t scripts and tools that liive outside of obsiidian:
I can run a script on my Projects vault and every file that has the string TODO: $some_string_here will get turned into a todo list item where the tags/project/due-data and other meta data for the task are inferred from the folder paths. This becomes nearly impossible to do in a consistent and sane way unless either:
- every file is forced to have some sort of standard header
- an API / database now holds all of the medadata. This is why i stopped using qOwn Notes.
Either approach starts to infringe on the purity of “you own your notes” idea from the front page.
W/r/t: implementation details
I think a ‘hard-coded’ approach that always assumes 2 levels deep would work, but a better approach would be to set a regex expression to the full file path. Anything that matches this expression get treated as the ‘page’ for that folder.
I can imagine a plugin that has some setting that I would configure like this:
folder-pages:
- ${vault-root}/project-.*/index.md$
- ${vault-root}/idea-.*/index.md$
Which would only treat index.md files inside a directory that is named project-* or idea-* as ‘special’. A file called templates/index.md would not match the configured regex expressions and so it would not be treated specially.
On a side note, I would love to see that sort of option make it’s way to the template plugin so I can have a new note in a specific path automatically use a given template rather than having to pick which template i want via the command pallet.
2 Likes