Longread.
3 Likes
I was trying to explain this to a friend a few days ago. I’ve passed this along.
I really like this series, it’s helpful for determining what tool to use for upcoming projects. @mdubakov will we see one for Fibery vs Coda in the near future?
Big thanks for mentioning the API and the eventual Graph API move. It’s been a concern of mine, since I like automating things.
I agree with @helloitse, have been waiting for Coda. I noticed the first comment you have @mdubakov over in Medium is a reader also asking for that! I think Fibery will have the greatest appeal to users of Coda vs. Airtable or Notion, as you guys handle easily a lot of what Coda can do, too, but not unless you are a very advanced developer who can master formulas, lookups, controls, etc. None of that skill needed to create an amazing solution in Fibery!
Easy in Fibery… terrible in Airtable:
1 Like
I thought this was a feature request
@webinit if you’ve cracked this could you show how to pull it off?
If this what you’re looking for @helloitse?
@webinit It is an awesome workaround! There are such field in Fibery, but indeed you can have it this way since Fibery filters dependent relations automatically. Great find.
1 Like
Hi guys @mdubakov, @helloitse (thanks for the mention of the request!) and @webinit:
I wanted to add that what I was referring to is within the fields such as “multi-select” and “single-select”, which I think are the closest thing we have to “tags” in Fibery. I understand this solution, but @mdubakov in particular I am curious about your view on how this can lead to proliferation of Types. I agree fully when you mentioned in the Airtable article that Types are like tables, and my point here is that I’d like a more lightweight way to categorize actual entities, without having to create Types.
Perhaps the recipe/food was a bad example, I don’t actually have that in my workspace! One real-world example however is something like this:
Type: Vendors
I have vendors that I treat as “suppliers,” and “partners”
However some of my partners are also my clients.
So if I chose “Partner” from the first drop down, I’d like to also in a subsequent drop down be able to select among a certain type of Partner “low budget” or “critical” etc.
I’d like to avoid creating Types for all of this, as those Types will have just a few entities and that seems overkill.
I will add that of somewhat relevance, Coda can do this. Michael I know you are working on the Coda comparison. Coda does this with a filter feature between these fields within an actual Table, or “Type” to us here in Fibery.
So I think if we had the ability to do that, we’d meet this need without the need to get into extra Types.
I will also add that I don’t see this as a high priority, more like a “nice to have” that I hope you guys can consider for the future.
Thanks for listening!
@B_Sp one option for now could be to just create all the Types you need (even if they only have a couple of entities in each) and then just store them all inside a single folder (dragged down to the bottom of your app). Then simply keep that folder closed from view while your working (out of sight, out of mind). That way they would not clutter your visual workspace and be easily accessible when you need them. It would be an easy and relatively low maintenance solution, particularly after the initial setup.
Thank @antoniokov, not me! 
Thanks for the response! You raise one of my bigger dilemmas in Fibery - how to handle Types that are used for different needs, as I’m finding there are times when I will use them to “categorize” other Types. At other times, I think I use them more in their “intended” purpose, that is to represent “things” in my work management: clients, product components, initiatives, etc.
It’s a viable question @B_Sp.
My preferred solution to that is to think less and build more. Just create what you want to have happen in any way at all. Just shoot for the goal and keep shooting for it. Create a plethora of Types. Build it the way you think it could possibly work, break it, build it again. Create a mess, clean it up, get fed up, create a new app and try again. Reach out to support, post here, then try again.
Action purifies.
In no time you’ll figure out what works and what doesn’t. Don’t block yourself with trying to get it right. Instead, create a new Type and see if you can make it work.
Simple rules… what’s the process you’re trying to map? For that, create an app.
What are the Types that are meaningful within that process? Create them. Unsure? Create it anyway.
What are the stages the work goes through? Create the workflow steps and display it on a board view.
That’s my take anyway. Hope it’s helpful @B_Sp. 
4 Likes
Thank you @webinit, yes very helpful!
1 Like