#1

Use case or problem

I posted a comment on the below linked feature request, which I feel should be it’s own request as that request is somewhat old and this idea is different enough.

I’m proposing an alternative to nested vaults that should be much simpler to implement than the linked request and avoid adding too much cognitive load for new users.

Proposed solution

It’d be nice if, in any workspace other than the default workspace, the graph and link auto-completion don’t show any notes that haven’t already been opened or created in the workspace.

I.e. if I switch to a new workspace, the graph would be empty, and typing brackets wouldn’t show any autocomplete results (other than the current note). The files would show up, however, in the file-open modal as usual, so you could search for any file in the vault

The file browser would have a toggle to only show files in the workspace, and when toggled off you could bulk add multiple files to the workspace without having to open all of them by right clicking and selecting the option in the context menu. Potentially, the search view and graph view could have the same toggle, so you can switch between the workspace and global graph/search without having to switch workspaces.

Related feature requests (optional)

2 Likes
#2

I certainly feel that this alternative idea has more merit. I do not personally like the idea of nested vaults at all as it makes the concept of a vault ambiguous and brings with it a lot of unnecessary complexities.

In my use case I would like to be able to switch to a clean workspace of the type you describe when I start on a major project. While in that workspace I only want see what I have added to it as default but have a hotkey/button override to see links to the wider universe of notes when I am collecting information from the vault. IMHO it extends the concept of a workspace into something more useful than its current implementation as a form of stash.

2 Likes
#3

I see no reason to pose the request as an alternative to nested vaults. It should stand, or not, on its own merits.
Nested vaults are not a feature of Obsidian, they are simply a possibility in the way it is used. And they offer possibilities that expanded workspaces do not. People choose to use them or they don’t.

#4

Noob question: what is a “workspace” in the sense that you’re referring to? Is it a user-facing concept? (I’ve seen it in the plugin API, but as far as I can tell there’s just the singleton workspace there.)

In any case, what you’re suggesting sounds like exactly the sort of feature I’m hoping for. (I recently posted about it here.) Presumably it would be easy to create a workspace from a folder.

EDIT: I did some digging and figured out how to enable the workspaces plugin. I’m not sure I 100% grok how workspaces are supposed to be used, but it does seem like tying a workspace to a set of “files I’m interested in” would be a sensible approach.

#5

Such as? All I can think of is using a different set of plugins, which could also potentially be workspace specific (much like vscode has workspace specific settings)

I pose it as an alternative because that’s what it is, a safer alternative that accomplishes the same goal in a simpler way than other suggested solutions

#6

Workspaces are pretty much just a way to save a view layout. IMO it makes more sense currently to call them layouts than workspaces, and making them true workspaces (as they are seen in various other applications) is part of the motivation for this suggestion

#7

What you’re saying here resonates with me a lot. When I think “workspace” I think of my desk — where I might get out some papers, rearrange them, put some away…and then, the next time I come back, I expect everything to be the way I left it. It’s weird that when I load a workspace it’s just a snapshot of the first time I saved it.

1 Like
#8

Just a few off the top of my head:

  • Faster
  • Much better interoperability with other programs
  • Enables multiple windows

Your suggestion doesn’t achieve the same advantages as nested vaults, and nested vaults are perfectly safe with a modicom of knowledge.
There’s nothing wrong with your suggestion, it simply isn’t the same type of thing as nested vaults.

#9

What do you mean by faster? Why exactly would workspaces be slow? Files outside of the current workspace could be lazily loaded and evicted when switching workspaces, no need to process the whole vault. And I don’t see that being a problem in the first place unless you have a very large vault on a slower machine.

Nested vaults don’t, themselves, make interoperability with other programs better, the file structure does. One could easily have all files in a workspace under one directory, so that’s not really a distinction between the two, and in fact, the proposed workspaces would be even better as they allow linking across directories which doesn’t work well with nested vaults.

Enabling multiple windows on one vault is potentially something the devs could allow, but they haven’t for a reason. Yes people can be safe with a ‘modicom’ of background knowledge of possible snafu’s, but that’s bad UX. This is a general application for a wide range of users including non-technical people who have expectations for how workspaces should work derived from experience in other applications.

There may be other use cases of nested vaults that workspaces can’t accomplish (I doubt it) but regardless of what technically can and can’t be done with either at this moment in time, I do think that most users looking at using nested vaults are doing so with the same objectives outlined here, which is why this is suggested as an alternative. I.e. they may not be the entirely the same thing, but they’re intended, and would most commonly be used, to fulfil the same purpose, and I believe this is a better way of doing it. But this is just semantics at this point and it really doesn’t add anything meaningful to the conversation to argue about whether or not it’s an alternative or it’s own thing.