I have been following two requests for this functionality from @rickcogley and @gregbacchus:
This is a great feature and to reaffirm some of what Rich and Greg are saying, the example of a group of tasks that need to be referenced could get long over time if you can’t filter out “done” items, for example.
And I don’t mean to beat the dead horse on the Notion comparisons, but this is a huge cornerstone of Notion, if you look around how most people use it for relations, they will relate a Page to many filtered views of a related DB, and this filtering has a lot of great use that I’m sure would help us here in Fibery, too.
@mdubakov I noticed you marked these both as “done” around early March. I’d be grateful if you could let me know if I’m missing something and this feature is now live? Or do you guys plan it soon?
This functionality is possible using formulas: Task.filter(Status=open) or something like that
Obviously, this would result in two fields that look like collections: the original read-write one, showing all linked entities, and a read-only one, showing only the filtered list.
I guess if there are upcoming improvements to the presentation of data on the entity card this solution need not be as cluttered as it sounds.
I would really need a “Filter” option on those sub-entity views as well.
I don’t really get the “Task.filter(Status=open)” solution and how it can be a candidate for a good UX now or in the future.
Actually, a “Sort” option option would be very helpful as well, as we have views with 100+ items.
Right now those views are almost unusable when there are more than 30 items, which is really a pity because this kind of “agile viewing & filtering/sorting” features are really what make Fibery stand out.
It would be great to not add more challenges in terms of information architecture as it is already quite complex to plan how we want to link & display all entities & fields.
However, I think there’s some interesting challenges under the hood to this apparently simple request.
For example, if a list of linked items is filtered such that it only shows linked items that meet a criteria (e.g. status = open), then what should happen when a user wants to link a new item?
Should the user only be presented with entities to choose from, that meet the criteria?
Or should he be able to choose to link any entity (of the correct type) even if that entity doesn’t meet the criteria?
If the latter, when he creates the link, does that entity then not show up in the list?
Or should the newly-linked entity be automatically updated so that it meets the criteria?
Similarly, if a linked item is updated so that it no longer meets the criteria, should it remain linked, but become hidden? Or should it automatically become unlinked?
I fear that whatever my personal preferences would be for the answers to these questions, I’m not sure they would be the same for everyone else.
I think this is the sort of thing that makes it hard for the Fibery team to figure out the best way to add functionality that keeps (most) people happy.
Well I was asking for this feature because you know, “if you don’t ask, you don’t get”
I agree it must not be a simple one but it would be very useful.
Some feedbacks on the interesting challenges you mentioned :
Ideally all items would still be suggested, because the first intent of this feature is to add a link between two entities, so the user need to be able to search for any item. I think otherwise I would be confused not to find an item, whereas I can find it in all other places via “search / #”. If the added item doesn’t show up then because of the filter, maybe a warning message could show up just as a reminder of the filter. This way the feature remains coherent with the rest of “referencing” features.
Ideally the filter only impacts the display, not the actual linking. That way it would remain coherent with the current filter feature on boards (= if we use a filter on board, it does not unlink items).
Yeah, a filtered display of linked items is definitely useful, as is a ‘filtered relationship’ I believe (discussed here Relationships filter)
Personally, the latter is actually more useful to me, but I think I’m aligned with you on roughly how the former would ideally function.
@Chr1sG , well done on bringing up some of the challenges that come with trying to implement this sort of thing. I think it’s important to try to maintain awareness of the difficulties involved in what we want the system to do. But as well, it’s always worth asking, of course!
I can fairly easily think of ways to handle the cases/questions raised, for example Fibery already has icons that show that an Entity no longer fits the current sort or filter and will change upon next refresh. The same could be done for newly added entities that don’t fit the current filter, e.g. the entity shows up, but has a unique icon that shows it will disappear on a refresh/revisit.
I also think the application of filters that limit the view of actual linked entities should be very obvious. Not obtrusive, but very clear. Otherwise it could cause a lot of confusion.
Anyway, I think these are all surmountable problems, but do indeed take work and thought to address.
Current functionality… when an item is created from a filtered view, the new item gains the filtered criteria in the respective field. Seems the devs have already come to terms with the conundrum. The convention is that you are happy enough with the view’s criteria that you are willing to persist the respective data.
As to your second point, filters determine what can be viewed to reduce search friction. Altering (unlinking) existing data relations due to view filtering changes in some part of the app would be highly counter intuitive. Viewing data (with filters) is abstract, storing data (with relationships) is persistent.
“FIND a WHERE b = c” has been around for fifty years. I personally think it is false advertising if a SaaS is claimed to be a “database”, yet you cannot filter the data selectable in a relationship field. I’m looking at you airtable, notion, coda and all the rest.
I think it’s worth noting that the original discussion relates to ‘collections’ rather than views (tables, boards, hierarchical lists etc.)
It’s an important distinction since the collection is the relationship, not just a view of it.
If someone wants a relationship to have filter-limiting, that’s different from having a filtered view of a relationship.
Nope, airtable’s relation field’s have one set of static selectable data that never changes.
I’m a cleaner, I have hundreds of locations I work at, each of these locations have a bunch of tasks. I want to record what cleaning tasks were completed today at the location. When I open the “tasks” relation field in my airtable table, I am faced with an unfilterable static array of thousands of possible selections all named similarly. I have to either scroll back and forth through this mega list, or type each task into a search bar, the friction and error risk is huge.
If only I could filter the “location” relation field by the client field and the “task” relation field by location field.
Airtable’s solution for this (you referred to) is nightmarish, hundreds of views at both the source and destination table. Hundreds of separate relation fields in the destination table to link the specific filtered views together, all hidden except for one per “location” view. It is disingenuous to call this a filtered relation.
It sounds like you’re not happy with Airtable, which is fine, no arguments from me
I only posted to try and be helpful in case you weren’t aware of the feature.
Wrt Fibery, I don’t understand exactly what your use case is but I’m wondering if auto relations might help…have you looked into those?
The difficulties you mentioned in implementing this feature request, I do not agree with.
This feature request is very important if a user wants to effectively use relational data. It shouldn’t be flippantly dismissed.
Data relations is at the core of Fibery’s product.
All the big players (airtable, notion etc) claim that this feature complicates their product too much (yet they use filters elsewhere in their product). The subsequent workarounds that their users implement leads to an even more complicated, friction producing, spider web of data views.
There is fertile ground in the market place for Fibery if they get filtered relations right. For all other features (eg page sharing, commenting, UI, automations, etc) some other big player beats out Fibery.
This is an interesting discussion with you and @Chr1sG. Maybe I’m missing something, but what I’d simply like to see, which I think is discussed at various places in this community and I don’t have time to dig them up now, is to have collections behave like embedded tables, the way this works in Coda or Notion. Some basics of this:
you can enter data in the fields, including a desperate need of mine, Rich Text fields you can type into (a big plus of Coda). This is one of the things that jumped out at me in my initial evaluation of Fibery, the fact that you cannot enter data directly in Collections.
Ability to filter and sort Entities. In both Coda and Notion you can embed a view of a table - a Type in Fibery - and slice and dice it anyway you want. One issue for my team is we have work items in Collections. It would be great to be able to either filter out the “done” items, or sort with “done” at the top, or bottom. This is also requested all across this community.
I feel like it is not a big ask to have the Collections behave like embedded db’s in Notion. Until this is done, the only way to get a nice table of data is the Table View in Fibery, one that has a lot of potential, but I consider it for the moment an orphan. You can’t embed it anywhere, and UI wise it is very limited - most of the good UI customization, such as size of cards, ability to drag and drop, etc. is in boards. But, and here’s the point, Boards, like collections, don’t have the table-like function of being able to key in data and behave like a spreadsheet. So if you want that, you have to go back to the lonesome Table view…
And since this is a big need of mine, I want to link to the reality with the new and very promising Hierarchical Lists View, which seems like to be based on the Boards UI, not Tables. But unlike Boards, you can’t customize the way data displays on the “cards” in the view, let alone actually type into them, like you can in, say, Wrike’s hierarchy View:
@B_Sp@DBG Overall I do agree that relations filtering IS important and we should add it into Fibery. I don’t think it will complicate the system, since otherwise people tend to suffer with workarounds or long UI browsing to complete the task. Unfortunately I can’t give you timeframe when it will be done.
Just for my own benefit of understanding, are you talking about being able to apply filters to limit which related entities show up in a collection, or are you talking about limiting relations based on a filter?
