In a creative organization, work management is knowledge management. The architecture you choose shapes the way knowledge is captured, discovered, and shared.
How has your knowledge structure changed, once you migrated to Fibery?
Great post @antoniokov! I have been evaluating project management apps for way too long, and this is one of the greatest dilemmas I face when trying to model for my team. As time goes by, I have found that the “Vertical Hierarchy” solutions like Asana, ClickUp, etc. are very limiting as you don’t have relations, which become very important if you want to start to represent not just tasks, but actual “tangible items” as we refer to in my team - Customers, Software features, laptops, etc. These are all “nodes” of a sort that you speak of…
I think Fibery could use some additional Hierarchical handling on the vertical level. To answer your question, I was used to using tools with the Vertical Hierarchy set up, and tried to structure my system around that: Things like “Department - > Marketing, Sales…” etc. In Fibery, I can only do this with setting up two types and relating, but that seems to be overkill. In some cases, I feel like I really need to just “group” Entities that are in a Type. But the Groups really have no metadata necessary, it seems it would be sufficient to almost put them in a "folder’ type container. Granted, you guys have things like single-select that can serve this purpose as far as tagging “types” of entities within a Type, but it gets hard to visualize those where I’d like to - in reports, dashboards, etc. - none of these views are really developed yet in Fibery, but I’m confident you guys will make that happen!
I think I’m repeating some of what I’ve already forwarded to @mdubakov and the team, but I hope this is useful to your thread here.
And of course, the Highlights/bi-directional @mentioning capability is even another way to relate entities that provides further capability, which you guys are on the cutting edge of now. I noticed you pointed this out as a specific way to relate, agreed! I can see situations in my team where @mention is sufficient, and I don’t want to have the @mentioned entity relating, or a child, to the “mentioning” entity.
For example, in an entity that would be for “updates”, like an Email-type communication inside Fibery. You could @mention a client you want to refer to. But that client could be an Entity in Fibery of its own. And it doesn’t seem in this case that the Client Entity should either relate horizontally, or vertically to this “Update” entity - it’s sufficient just to make the @mention and pick up the reference. Which of course is a type of relation, but I think you could argue that it’s a useful “variation” of your “typical” one-to-one relation. Kind of like a “relation lite.”
That was really a great post, one of the best I’ve seen describing the problem and how various apps handle them. And I think none have it solved, but you guys have a great chance to be the first…Thanks again and curious for your thoughts on my comments!
You are hitting on here something very fundamental that I think all the apps you talked about have missed out on, and I would love you guys to pursue: I think the tool can actually have just one “Entity” type that handles all of these needs:
I think “Database Record” you have hit as a fundamental with Fibery. Particularly well thought out is how you guys have included a few of what you are saying are key attributes - assignee, status - as “Extensions.” I have thought that you guys could build out an extension “library” that could be added as needed, if you want to use an Entity for different purposes.
For example, I’m experimenting with a set up where in CRM and Vendor Management internally, I have both a “company” - the vendor or actual client, and an “account” that’s related. Sometimes we have a Vendor with multiple accounts we need to track separately: Google for Google Ads, Google Analytics, GSuite, etc. It’s not really accurate to just say that’s all “Google,” which you might do in a typical accounting program like Quickbooks. And you don’t need things like “estimate” for those type of entities.
In fact I’ve suggested some more extensions that I hope you’ll consider! In particular, your example of “due date” I think would be very useful, as right now you have to do some work to get the concept of “due date” working, like filtering, etc.
I think another useful would be Checklists:
Your example of “estimates” would be a great extension too, perhaps part of Time Tracking? This is another key piece of Work Management that has specific handling when done well in tools like Jira, Wrike, etc. and is hard to set up for non-developers if you are forced to use Formulas and Automations in nocode tools.
You guys are ahead of Coda/Notion here as they don’t have any concept of the key attributes around these dB records you point out. You have to create your own Due Dates, Status, etc. and generally that means you don’t get good handling of these key Work Management features. As you guys know well, if you were to compare how Asana/Wrike/ClickUp handle due dates vs. Notion & Coda, it’s clear what I’m talking about.
And one more point re: the Database Record assertion: I think you hit on one of the biggest problems with Coda, that Michael also pointed out in Coda vs. Fibery: In Coda, there is a lot of emphasis on Pages/Sections. But these are not Database Records. So you’re stuck with trying to figure out in your schema how to use the Sections/Pages, which it appears Coda is developing fast to emulate Notion’s Pages, and how to use Coda’s dB elements - the tables. That used to give me a real headache! Notion for its part has got this right - like you guys - in that everything is the same type. That said, I think you have them beat - and closer to what you are describing - because in Notion a page often isn’t really a “Database Record,” but more of a Folder.
You guys are moving along with Knowledge Hub, as an Entity can be all a Doc needs to be. Most apps have Docs separate from “tasks” or “issues.”
You have Dashboards well in hand with Context views - although I could really use some SmartFolder functionality since when I click “show entity of this type in left menu” that menu can get looooong!
What’s particularly intriguing is the “Discussion Room” point. I have spoken with @mdubakov a bit about this, and I believe there is huge potential to get this right - it’s something a lot of apps have not thought through. Things like being able to have a discussion or meeting as an entity of its own, that would in turn relate to other “nodes” around the tool as freely as anything else. With a few more functions, like threaded comments, requirement to “comment” on close, and a couple others that could be added via Extensions (like assignments and workflow), I think you guys would have this 4th need covered.
But I fully agree that how you’ve laid this out to those four purposes. Another thing I’ve done in Fibery, since coming across you guys, is to start to see how superior it is to be able to use an entity for just about anything - Except as a “folder” to group other entities per my previous post.
Another example for you: My team used for a few years the Confluence/Jira combo many teams use. It was a constant mental struggle to figure out what goes in Confluence, what goes in Jira. You could relate the two, which was in fact my favorite feature. And the desire to do more relations has led me to search for tools like Fibery that appreciate this need. But in the end, we had a pretty messy set up, with stuff partly in Confluence, partly in Jira, and I always felt that it was hard to distinguish, most of the time, when something should be a Confluence Page, or Jira Issue. You guys have completely solved this already!
Thanks again for the post and eager to see what you publish next on this excellent subject!
@antoniokov, I wanted to resuscitate this post and get your input on this re: your guys’ approach to Hierarchy. You have mentioned in Twitter and in the Monthly updates that working on that view was on the short term roadmap, and it would really be great to get it soon as this continues to be a big pain point for me in adopting Fibery.
I am starting to build an approach around trying to both group sets of Entities, as I discussed above, as well as leverage your guys’ benefit of having the One-to-Many relation differentiated vs. just a “regular” many-to-many like in Notion, or arbitrary like in Jira, where you just link one issue to another.
I have thought that in a sense, when you build a One-to-Many, this is effectively a Parent-child hierarchy, although you are defining it as a “relation.” Given that you have no cross-Fibery concept of Folders or other ways to group, I have had to use this to do things like tag entities into business areas like Marketing, Sales, etc. that further break down. Task/Subtask is another mini-relation I have used to represent that typical hierarchy you’d see in other Work Management Systems.
If you take this approach though, you wind up with Entities that are acting as “Folders” in your structure. In many cases, if you are simply trying to group Entities, that seems like too much substance as you wind up creating a whole Type just to group Types “below” in your relation. Single-Select and Multi-Select seems better suited for this need, as they basically tag Entities around Fibery. And because of the ability to use the same such fields cross-App as discussed here: Cross Entity "Tags" via using Single Select and keeping names identical?, you can try to set up “groups” through all of Fibery.
However, in order for this type of Tagging to fully provide the Grouping capability that is omnipresent in a lot of Work Management tools that use a Space/Folder/SubFolder hierarchy, you’d need to be able to more naturally use this tagging capability. So I wanted to get your thoughts on things like:
A feature that would allow some way to see Single or Multi-Select views across all of Fibery, not just in one App?
Implementation of Dependent Drop-Downs so you could have a hierarchy of these Tags. This would allow for creation of a sort of sub-folder structure. Coda can do this via Formula Filters.
I think if we had more use of this existing cross-Fibery tagging, you would have within Fibery possibly the most flexible way for teams to handle the challenge of walking the line between using Top-down hierarchy to structure work, or relational flatter structures. This would get much more ability to use the tags where One-to-Many relations are not really suited.
And since we have all been chatting about this a lot of late, would love to hear from @Chr1sG@Oshyan on this if either of you still have the patience to weigh in again
I agree for the most part with what you’ve outlined here. At this point my head is spinning a bit with the various potential ways to handle this and related things, and it has received a lot of discussion, both recently and some time ago. My feeling at this point is those of us who are most invested in these possibly overlapping feature areas (dashboards, grouping/folders, folder views, hierarchy and navigation, relations and polymorphism, and even embedded views) have put our thoughts out there and done our best to explain both the goals and our visions of how to potentially achieve them with feature requests. Now it’s up to the team to implement, hopefully incrementally so we can see the direction they’re going and give feedback along the way.
In other words I don’t think I have much more of value to add until we see how they are planning to go about this. For my part I am fortunate that I can wait on dashboards and better navigation, but I can understand it being a blocker for others, so I do hope it is a high priority given how capable Fibery already is in other areas.
That said, I think the team has one of the best theoretical approaches to feature prioritization, so I trust whatever comes next will be good.