Provide Context for Duplicate Names

When # referencing documents and views within a document, there needs to be more context provided to know more about the document when there are duplicates. This can happen pretty often for views as well, since the smart folders can produce a view for each entity shown.

For example, many of the templates use a “” document in the root of the folders. If you have multiple of those types of files, you won’t know which is which.

I’m working on an app for managing meetings with organizations and 1-on-1 meetings, and have a folder structure to provide little zones for when I interact with a particular organization. I found that using these files are helpful to contain process documentation. When referencing these files from the root file, I found that I don’t know which is which.

So, there are two potential features here:

  1. Show more context when selecting a reference (so I know I’m selecting the right one)
  2. Show more context after the reference is selected (within the document, so you don’t have to manually add the context)


Yes, this is a good point. Do you have any thoughts on the best way to indicate this in either situation?

It appears that they are already providing context for smart folders, which I didn’t realize until after I posted this. See the “Tasks by Priority (Product / Marketing - 2021…)” view in the list? That is a view within a smart folder. It appears we just don’t have the context for any other folder.

As for the context when in the document, I can see that being somewhat complicated to do at this point, and there is the workaround to just manually add additional text, so I’m less concerned for that feature. But, as for ideas:

  1. Use the same context that is shown in the screenshot for the Tasks by Priority view, but allow turning off showing it. So, <document name> (<parent folder name>) or <document name> (<parent's parent folder>/<parent folder name>). I’m not sure how far you could take the path up though, so displaying the parent folder name could work.
  2. Use something like what Roam does for namespacing, which allows you to configure how to display it. It either provides the full path /path/to/entity or /p/t/entity or entity.
  3. Allow overriding the display name where it is referenced?
1 Like

I totally agree with this. I often have recurring weekly meetings for projects. I’ve been manually putting the meeting date in the name and also including a date field in the entity. If you were able to include 1 or more fields in the item finder view, then you don’t have to put in redundant information in names. Fibery already allows you to do this in reference fields:

I think it would be fine if you could choose the fields to show at the app level.

What would make this even more powerful is when we have full text search as well as the ability to search all the other fields in the entity. I am hoping that the overhauled search allows for a more complex/hybrid searching of free text along with dates (and date ranges), numeric values (larger, in between, less than …), etc.

1 Like

Did you consider using a formula for the name?

1 Like

Great suggestion @Chr1sG. I do use name formulas for some entities. However, the pattern for the name isn’t always constant for my meetings. I also wanted to avoid adding another text field. But I may still go with the name formula option for now.

I actually really like the way Fibery shows other relevant fields on the right side and think it is a good pattern to follow if you are able to customize how entries show up in line and in the search area.

This is a good request, and one simple thing I’d like to see, which is very important if you are using Fibery to track work items, would be seeing which items are closed in the list:

Also, @Oshyan has request right here:

That has additional related solutions, like this one:

You are talking about generally the “#” dialog, which I otherwise refer to as the “Ctrl + K” dialog - it could use a definition by the Fibery team so it gets a universally accepted way to be referred to, too!. The fact that you can see Entities, Views, and Docs is useful, but does create these needs, since only Entities can have a state and other attributes, while Views and Docs don’t really have any aside from their names.

And while on the subject, on a daily basis my team has told me - and this happens for my own use, too - that they instinctively want to click on a “Type” and see a list of the Entities in it. This is a very common navigation in work management tools. But now, you only get an auto-generated table for each Type, and if you move the Type to another app, that doesn’t work. So I’d really like to see Types in searches, too. And it would be great to be able to find an App also in that search, for quicker navigation to each of them.



Do you mean that they want there to be a (persistent) list of types somewhere, each of which can be clicked on?

When using search (Ctrl-K) or mentioning (#), all the different Types are shown and are searchable (and when selected apply a filter on the entities that can be chosen).
Do you mean that you want the search/mention function to return a type?

Good to hear from you!

Re: your question here:

Yes that’s exactly right, and some sort of default list of all the Entities in a type is returned, that can then be quick sorted/filtered. This is a very typical behavior in just about all other work management apps, and nocode as well when things are organized in tables, and you can easily get to a view of a whole table’s rows/entries. So like Tasks in a certain list in ClickUp, a Project’s tasks in Asana, etc. etc. In Fibery, it’s not overly intuitive right now to do that. My team sees a Type “Tasks” in the App where it lives, they know they can create one, they know its color, but they can’t simply click “Tasks” and get a list of them. Would be curious @rothnic your thoughts, too, as this is very much both a UX issue.

And yes re: this point, that’s right. So instead of being forced to create a view, that can get renamed, or as I mentioned, get lost if you move a Type to a different App, you could get a Type in a search result. Again, this is a fundamental feature of other work management apps. When searching in ClickUp, you can “jump to” a List. So perhaps that would be how Fibery handles it, a bit different way to navigate if you want to search for the type, vs. how the search would handle if you simply want to find an Entity.

The problem right now is that if I simply want to go to that Type “Tasks” and see all of them, initially unfiltered and with some default sorting, I can’t do that necessarily without first creating a Table. That table can then get sorted, filtered, etc. to create a custom view, and then I have to create a new Table with no Filters, rename it, make sure my teams knows that’s where you find everything in the Type, even though I can’t write notes in the Table as its a view, nor does it have any ability to pick up References/Highlights, which is a limitation in Docs as well right now.

Thanks again!

1 Like

Just so I understand, do you mean that Types could be included in the search box as search results and if a user chooses the Type, he/she gets returned the default list of all the Entities of that Type?
It sounds almost as though you’re advocating for the default table view to be persistent/locked (can’t be deleted, have filters applied etc.) and for it to move with the Type if that gets moved to a different App. Am I right?

Or do you mean a jump list as was discussed here, that wouldn’t actually take up any space in the side bar?

Yeah, I agree. I’ve been manually implementing a pattern of having a folder called Types/DB/Data as a subfolder in the app that owns those types and having a single view named for each type owned by the app. This makes it somewhat easy to get to a table for a type, but there is the potential to get messy due to people changing settings on that view.

What you seem to be describing is something similar to JIRA’s advanced search. It gives you a read-only view where you can search across the types in JIRA, along with filtering, showing/hiding columns etc. Then you can save that as a saved search. I think Fibery could potentially use something similar that is leveraged as a place to send people who want to see a type without selecting a specific view. So, you click on the “Tasks” type, then are sent to the advanced search view with a filter applied of Type=“Tasks”. You could then add more filters, or adjust the Type filter to search for Type=“Tasks, Issues”, etc.

From a story point of view, I’d say that these aren’t well supported at this point:

  • As a newer user added to an existing Fibery workspace, i’d like a simple directory of the types within the workspace that support non-destructive browsing, so that I can understand simply which types exist and explore the content without impacting existing views
  • As a power user, I’d like to be able to explore the entities within the workspace with the same filtering that exists for views and perform actions in bulk on the entities, without having to create a view first, then also remember to delete it when I’m done
  • As a general user, I’d like to be able to click on a reference to a type (e.g., when viewing entity details, or referenced directly in a doc, etc.) that takes me directly to a view that can be filtered without impacting existing views

This probably is kind of an extension to the Mention or links to types request.


Do you really mean a directory of types? If so, doesn’t the App map provide a good read-only overview of the various Types?
Or did you mean a directory of Entities? In which case, I agree that being able to browse all Entities of a given Type without the need for dedicated views is quite useful.

You mean the same filtering options, right?
Out of curiosity, how would you imagine that a user would reach this ‘explore entitites’ page?
Maybe by clicking on the Type in the directory of Type view you wrote about?

I think that we’re all basically agreed on the need to be able to create references to a Type (where Type = collection of Entities) but without necessarily having to create a specific View to be pointed at.

Also, I actually think it would sometimes be useful to create a reference to a Type (where Type = specific configuration of fields/extensions). I sometimes write a Wiki document to explain how Types should be used, and in this case, I’m more interested in pointing the reader to the Type definition rather than a list of all its Entities.

The user stories listed out are pretty generic, but it could potentially provide that. However, I don’t know if that view is the best for non-power users. It also doesn’t give you access to non-destructive browsing, which i mean as that you can filter entities without impacting a current view that exists. Basically what I’m describing is that a typical user is simply going to want to jump and view all entities of a particular type, then filter them down further.

For example, think about a new team member that is like, “I wonder if we have a Topic type defined.” If they go to app map, that isn’t going to help them view entities for the Topic type. They could only see the definition of what the Topic type is and potentially modify that. Instead, they could search for “topic” and they’d see what I think is the only true simple directory of types on the right. If there happens to be a view with the same name as the type, they would discover it via search. Otherwise, there is no way to go view entities of that type quickly. Even if they do get to a view, then unless they have some kind of read-only permissions they’d be modifying that view or they’d have to duplicate it and remember to delete it if they want to explore them further.

If I understand correctly, I thought the desire was to see the type in search as a result, which when clicked on would take you to go view entities of that type. Right now it shows up, but is only used to select which type you want to create.

Well, both really. With some clever design work, this view to filter all entities would have a “Type” filter, which would contain the potential types to filter on. The filter could serve double duty in also being a list of the types. The search functionality pretty much has that simple directory of the types, but it is focused on entity creation, instead of filtering and would need an expanded advanced view to add more filtering options.

Yes, sorry, the same filtering. It could potentially be viewed as an advanced search. Or, there could be an “Explore” area called out in the left nav.

Yep. For the reference, you could think about the types as an entity of the Type class. In other words, each Type (Task, Story, Epic, etc) are an entity of the Type class. If you could have a details view for a specific Type, in the same way we have that for a specific Task, it could show relationships such as “Documents”, “Views”, “Entities”, etc.


Chris, appreciate all your time commenting and explaining details here. I think what you said above best summarizes what would be good to have. And I’d like to be able to navigate there quickly with “ctrl” + “K” at any moment while working in Fibery. @rothnic you are also going into nice details, but as you said Chris:

I think we all want the same thing!

Thanks again!

1 Like

And along these lines, I just noticed that References now have the same full context that is visible when referencing inline with “#”!:

It is great to get yet another area where you can see context of other Entities that are related right inside the entity that is the “destination” of the relation.

Maybe this has been released sometime but I just noticed today, very helpful when tracking tasks & projects as your can see the state of the Entity doing the referencing.

This is where Fibery really shines. The Networked Thought tools are all about referencing, auto-linking, etc., but they have virtually no way to add attributes to their Pages that are the atomic unit. The Nocode and Project Management guys allow for all types of attributes in their atomic units (which are Tasks, Rows, “Items,” etc.), but they are all very weak in reciprocal linking and referencing. Fibery has the best of both!

This is a key way you guys can shine when compared to Roam. And I mention Roam as one of your competitors as I see increasing use of Roam for Product Development, like here:

What you guys are doing really shines when compared to Roam, because in Roam a page has ZERO attributes of this nature. If you want to make a list of Features in Roam, then reference them in your Stories, and see the status of each reciprocally, forget it! You can’t have a status, nor assignee for that matter, period in Roam!

You guys need to get word out about this stuff we need more Roam converts here! Maybe do a comparison blog post Fibery vs Roam even, alongside the existing ones you have re: Notion, ProductBoard, etc.?

I’m guessing @Oshyan would also be intrigued to see you guys do a side by side vs. Roam!

And I hope I just got us some SEO juice right there for people searching Google for “Fibery vs. Roam Research” :slight_smile:


I find the idea of trying to use Roam for product management to be rather extreme, personally. I would never consider it for that myself. And I would guess the number of people who would actually be paying Fibery customers and would also consider Roam as an alternative may be small… So I’m not sure the Fibery team will want to make a direct comparison themselves. Would be great to see a fluent Roam user who also uses Fibery do a comparison though, just to see how they handled it.

1 Like

Thanks for that!

I think the point is that Roam has gotten so widespread that people are finding uses for it in Product Development, not to mention Product Management. You are probably aware you can do a makeshift Kanban board in Roam, etc. I would also not use Roam for Product Management, but me and you are in the minority as a lot of people are doing just that, and I can see how they might make it work, granted with its flaws. Let’s be honest Fibery is full of flaws too, but I’m here because it’s better than anything else out there in spite of that for my use!

What I wanted to focus on is those using Roam for Product Management. The reality is there are so many Roam users that there could easily be a subset of them using Roam to manage Product that is x times larger than the entire Fibery user base right now. So I think those users would be great converts over to Fibery, but my guess is they don’t even know Fibery exists.

Now, to this point:

I agree 100%, as I think you’re suggesting that if you’re already in Fibery, you wouldn’t consider Roam for this use. But my point is to get the Roam users over to Fibery!

And in fact, to expand on this point, I think that if you are in Fibery already, you would not move to any of the tools that Michael published “Fibery vs…” articles about. If you’re in Fibery, you’re probably here because all those tools were inadequate. I have used all of them extensively - AirTable, Coda, Notion, Aha, ProductBoard, and Fibery does more than any of them, there is no risk of me going back. But if users of those products can find those articles and try Fibery, there’s a great chance they will convert! Same goes for those using Roam for Product Management, which, to add context, from what I read is usually some PM’s who want to connect feedback, ideas, etc. together to guide a Roadmap. And Roam is great at connecting things.


Interesting, yeah I see your point more. I mean I understood from the first that you hoped it could attract Roam users here. I guess my perspective was that most Roam users I’ve interacted with are using it for one of two reasons: they need (or at least think they need) block references/transclusions/etc., or they have bought-in to the Roam cult fully in some way and think nothing else can be as good. If either of those things are true, it seems like a hard sell to get people into Fibery because it doesn’t have block references or indeed blocks of any kind, and it’s not an outliner in any way. I also think that if people are bought-in to the “Roam for everything” mentality, then a good part of the reason they’re using it for this non-ideal purpose is the integration. They know there are better, more purpose-built tools for project/product management, but they value all-in-one enough that it’s worth the compromises.

Anyway, I just think it’s difficult to penetrate the “Roam cult” on merit alone. But I also recognize that you see Roam-like capability in Fibery’s referencing, backlinks, etc. So indeed I could see it being described in a Fibery comparison article demonstrating that to get benefits of block linking, etc. in Fibery you use these other functions, and that there are even some advantages in the referencing itself vs. Roam, not to mention all the other functions. I’m still not sure it’s a niche worth the time of a full comparison, despite the size of the overall Roam community, but I don’t know how long it takes Michael to write those either. Worth the discussion in any case.

1 Like

Very well said as always, I have no further response. Thanks for chiming in again on this subject!!

1 Like