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 “Read.me” 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 read.me files are helpful to contain process documentation. When referencing these read.me files from the root read.me 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)

3 Likes

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.

Did you consider using a formula for the name?

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.

Thanks!

1 Like

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!

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.

1 Like

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.

2 Likes

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!