Don’t worry about it! So far it’s always been the case that I grumble at first and then end up being satisfied with what you’ve all produced.
Focusing on one tag without displaying other tags contained in the same notes that also contain the focused tag is not particularly useful to me. I can see the visible structure just as well when I unfold the tag in the sidebar.
Displaying the other tags outside the hierarchy opens up fantastic possibilities that can then also determine how I structure my tags. A simple example. I have the main areas #work and #personal. In addition, I have a tag such as #person. If I now focus on #work, I am shown notes that are also displayed in #personal. You already mentioned this example in your opening post. It is also advantageous if all persons belonging to #work are displayed under #person. But now I can also go the other way: I focus on a specific person such as #person/mister1 and can immediately see whether they belong to #work, #personal or both. As you rightly said at the beginning, real workspaces do not offer this option. That would indeed be a terrific feature.
Something completely different that’s on my mind: Have you already considered or discussed that in focus mode, a newly created note automatically and always receives the focused tag? If the note remains untagged this would mean that it does not appear in the sidebar at all, which would be completely contrary to expectations.
Yep. The feature as currently proposed encourages the use of tags as folders, when their power are in making ad-hoc unions. My vote is for the feature to show all tags that are applied to notes that have the focused tag.
I don’t know if it would be unexpected. I would expect the sidebar to show all tags that are applied to the notes shown in the notes list, even when focused on a tag. This would keep the same sidebar behavior, irrespective of modes (ie focused or unfocused mode).
Actually I consider bears system of nested tags as both: as folders and as tags merged together in one tool.
I also think that nobody would expect those tags to be hidden. It even would be confusing not to see them. Just a simple example: being in focus made and tagging a note with another new tag (outside the hierarchy of the focused tag) without seeing that tag in the sidebar goes against everything we get used with bear.
After further thinking about it, what if I want different tags focused? Such as School/cis210 and my Resources/book tags? I would rather an implentation of saved searches to just be able to pick which tags I can and cannot see and be able to combine it with other search terms such as @last7days… Then I could make a saved search thats #school/lectures + @last7days + #review + @todo, showcasing my lecture notes from the week that i still need to review for example. I feel like it fits the minimalist vibe significantly more than workspaces as we can choose to use it or not use it and tailor it to our needs. @trix180 is something like this even being considered?
I strongly believe that focused tags are a feature for the left side bar while saved searches for the second pane. I wouldn’t confuse both features even if you think the left sidebar would be a better place for saved searches.
Hmm … that’s not really what I was getting at. I actually agree with the devs’ concern about out‑of‑scope tags “bleeding” into the current focus. If I focus on #work but still see #people and #goals in the sidebar, I now have to infer that some #work notes also have those tags. That’s a pretty heavy mental indirection, and it undermines the whole point of Focus as a “scoped workspace” view.
To me, Focus should keep the sidebar constrained to the focused tag (and its subtags), rather than surfacing unrelated tags via overlap (even if that technically means hiding tags that happen to be present on notes within the focused set.).
More broadly, my original point was to highlight what I believe to be the constraints of relying exclusively on nested tags, especially in the context of this feature. Nested tags already do ALL the organizational heavy lifting in Bear; “proper” workspaces might offload some of that burden and let tags be used more freely for ad‑hoc organization.
ive been reading some of the comments and there all interesting and lots of valid points made.
I think though as well is that many people have been creating three own workflows around the lack of ‘workspaces’ and so this concept throws a bug into those existing systems. So that can feel frustrating from a user perspective when you have an established system.
That said this idea doesn’t seem like it would actually break anything unless you actually wanted to use it.
I like the idea, though it’s not what I expected. it provides what I expect would be a lot more flexibility than ‘standard’ workspaces. you could essentially create and rip on the fly silos of data based on tags, no need to create folders, no need to click File → create new workspace, no need to File → open workspace / close workspace.
its a nice idea. i think it would need to be fast and easy to use though, to be able to switch tag ‘focus’ fluidly without fuss would make it more usable.
To your questions:
Does limiting search to the focused tag work for you, or do you often need to also search across everything?
a global search is useful, or at least a way to flag a global search vs a focused search, or maybe even focused + linked / external tags
How often do you switch between contexts; many times a day, or do you mostly stay in one?
personally I switch between different base tags often, personal information, contact management, project / topic specific, work, notes, etc. I think it would be important to be able to easily and fluidly switch between contexts without cognitive cost.
Is there something important you think this approach would miss?
it might throw a spanner into the popular kpm ‘systems’ out there. this isn’t good or bad, but maybe it means requiring some concepts showing how this kind of system can be adapted into existing workflows people have.
I’ll probably be stirring the pot here, but switching between workspaces in Obsidian has already worn me out. There are vaults there, each with its own windows. It becomes quite heavy when you switch between them often. In the end, I put everything into a single vault. But Obsidian offers many ways to manage content within one vault.
In Bear, it would honestly be enough for me to have smart folders based on filtering tags and file dates (possibly with the option to group them into something resembling folders). Unfortunately, the Bear community tends to react almost angrily to the word “folder”, and the developers don’t seem very fond of it either.
In any case, smart folders would allow for much simpler tagging of notes.
For example, instead of monsters like this inside a single note: #wiki/afterfx #favorites/afterfx #wiki/afterfx/expressions
Agreed! I would be such as natural complement for tags as they are right now I find myself having to create many subtags that would simply not exist if I would script folders that combined two or more tags together.
Ex. “movies/2026” and “books/2026” wouldn’t be necessary if I could just have a #2026 tag and then a smart folder that combined “2026“ and “books“.
To what extent it undermines heavily mental indirection. As long as I am not missing a point I don’t’t see any value in hiding other tags. Such a feature has no real value: it does nothing else than mac finder which takes you one level deeper in the file hierarchy.
While that makes sense in filebased browsing (unique place of each file) in bear it indeed would break my mental indirection. I already mentioned some points. Everyone who tags a note had the experience of seeing this tag appearing in the left sidebar. That would break. Another point: What else should I expect if I click inside a note onto a tag that doesn’t belong to the hierarchy of the focused tag than switching to that tag in the left sidebar?
Actually I don‘t get the point why someone would those tags to be hidden: If I want to see just the hierarchy of a tag i just would unfold it. It‘s up to you to create double taxonomy like #home/person and #work/person. But people who really want a replacement for workspaces would have no workaround.
In that sense hiding other tags would be a missed opportunity to satisfy all the needs people which wished workspaces for so long time
Guys, I’ll say one thing — at this point I honestly don’t understand what you’re all arguing about anymore. It really shouldn’t be this complicated. A simple app should remain… simple. If introducing tag focus or some other way of switching workspaces creates so many problems, then maybe… we just shouldn’t introduce it.
I think that well-designed smart folders wouldn’t have many opponents.
Honestly, if other tags don’t get hidden, then I’m genuinely struggling to understand the point of a “Focus on Tag” feature.
If I focus on the #work top-level tag, then my natural expectation is that all other top-level tags are hidden while in that focussing mode. Otherwise, what exactly am I “focussing” on?
I’d also welcome some more open-minded discussions on the subject of organization alternatives to nested tags (which currently do ALL the heavy lifting in Bear). With Bear’s robust search system, “Smart Folders” (or maybe we call them “Saved Searches” to avoid the word “Folder” ) seem like a natural fit! I suspect we might have gravitated toward “workspaces” mostly because it seems to be the only idea which has apparently gained any form of traction in other discussions here.
Independent of that, though, I still see potential value in a “Focus on Tag” feature and am happy the devs invited us to brainstorm this creative idea with them!
This is really good news!!! The proposal fits my needs very well, especially because it would let some notes appear in both workspaces simply by adding both tags if I understood correctly. That would be really useful, since I wouldn’t need to duplicate my tech notes or other shared notes.
Does limiting search to the focused tag work for you, or do you often need to also search across everything?
To me it is a fundamental requirement. If I need to search across everything, I assume I could just disable Focus on Tag.
How often do you switch between contexts; many times a day, or do you mostly stay in one?
For me, it’s mostly a device-based choice. Most of the time, I’d want to focus on my #work tag on my company computer, while at home I’d prefer to keep all tags visible.
I also hope this will be supported in the web app sooner or later (I use linux at work).
Is there something important you think this approach would miss?
One thing that could make this even more powerful would be the ability to expand from focus on one tag to focus on multiple tags. That would let view and work within more than one tag at the same time. I think this could be especially useful for building more granular workspaces and for implementing PKM systems with greater flexibility.
You shouldn’t just assume what the feature is about based on its name alone. The point of the feature is clear and was introduced in the opening post as an alternative to the highly requested workspaces, whilst remaining within Bear’s familiar framework without adding unnecessary complexity. Ad-hoc workspaces so to speak. Not displaying tags outside the hierarchy of the focused tag might appeal to some, but then this feature really has nothing to do with workspaces anymore and represents something else.
If I use the focus-tag-feature in the sense of workspaces ad-hoc why would I not want to see all my tags? For same reason I want the search to be limited. And to repeat myself: the unexpected side effects of hidden tags would break the user experience.
That’s highly attractive to me as it would make progressive browsing possible. However I wouldn’t expand the focus-tag-feature to exclusions like -#tag
Fair point - and I’m not trying to infer everything from only the name (though it shouldn’t be understated how important naming is for usability). In fact, this is exactly how the feature was originally presented:
It’s completely fair to debate the merits of this approach. But it is the vision originally presented by the devs. For my part, I happen to agree with it - and I’m voicing my support for it here (for reasons I’ve already outlined in earlier comments).