Hi, I know I’ve discussed this with you guys directly, but it’s such a big point for me I wanted to post here as a separate feature request, I hope this is a good place for this comment.
I have multiple instances where I am seeing the need to have entities in a few places in Fibery, most readily with multiple types applied. Here are some examples:
Idea entity. This is an item of any sort my team will quickly put into Fibery, such as “let’s explore partnership x,” “Run through of server set-up,” or “Add new pricing tier.” These ideas should be grouped into the areas they belong - so “partnership” or “Infrastructure,” which I’d have as types.
Website feature entity. This may belong to a part of the website platform, say FrontEnd, which would be a type, but also to a Project Type that is being built out to create the Feature.
I commented in the thread on tagging, but I really don’t think tags make sense given the great flexibility we already have with Fibery. I’ve always found tags/labels a weak point of other apps - they can’t be organized into hierarchy, don’t usually have any metadata and are hard to report on. With Fibery, we have the types which can serve the main purpose of tags, but bring true structure to the work in Fibery.
If I’ve missed something here and you can actually add multiple types to entities, I would love to hear how. And if this is a fundamental piece of the Fibery philosophy and is not allowable for a reason, I’d be glad to hear about that as part of my continuing Fibery education.
@B_Sp From technical point of view this is almost impossible to implement. Even conceptually this is hard to grasp, since there may be conflicts. Imagine you have two Types: Project and Idea. These Types have different fields. If you want to apply both Types to some entity, it is required to show all fields merged and this is very hard to do. Also what if both Types have State field? How to deal with it? I afraid Fibery will be much more complex… This is something like multiple inheritance in programming languages, it may sounds good, but program becomes very complex to improve later.
@mdubakov Michael, thanks very much for that context. That makes a lot of sense and I suspected that I was looking at this too simply. I am not overly technical, but consider myself a good “lego builder” within PM apps that I work with extensively, but due to the fact that I’m not a programmer, no code apps have been challenging for me. That said, I am on a mission to find a tool that can meet my team’s true needs, and all the others out there that “figure out structure for you,” like Wrike, Asana, Monday, Clickup, Hive, Teamwork, etc., etc. and even Jira - and I would also say Targetprocess from what I experimented - apply too much of their own beliefs around how structure should work. I have been drawn to Fibery because you guys clearly have the approach to build something that is not a huge challenge to configure, all the while being definitely a “no code” type solution, which allows the user to really configure to just about any need, without superimposed structures. And I also will repeat here that so far, I find you way ahead of all other no code stuff I’ve tried on ease of use, UX and UI, familiarity for team members who are not admins and need to use the tool, and speed around navigating and manipulating entities. I will count on your guys excellent support to help me with the more challenging parts of my set up such as this one. But in the end, that all makes sense what you wrote. I am curious how you will implement other “categorization” tools such as tags and so forth.
So once again thanks for that explanation, I will carry on with my set up realizing entity in two types is not logical. I have in fact in the meantime already started to figure out some other way to handle what I was hoping to achieve by putting an entity in two Types.
Cheers and thanks as always for taking the time to respond!
I just wanted to follow-up here. I am about a month in to my Fibery set-up since I posted this thread, and it didn’t take long for me to understand better how to handle some of the situations that may typically fall under “task in multiple projects” scenarios from other Work management apps. “Tasks in multiple projects” is a common use of Asana and Wrike, since both apps offer that. In fact, ClickUp, which is coming on as an alternative to those two apps, is working hard to bring in that functionality:
I think this whole topic is a really great way to illustrate the benefit of Fibery over those other solutions. So I wanted to share how I am now approaching this since I first posted when I was in the mentality of thinking I needed to put an entity in two Apps, or the equivalent of two folders in other tools.
Let me explain what I did in this case I asked about originally:
So here, I thought I should have this “Website Feature” ideally in two Apps, or “containers/folders” - "Website Platform, and “Projects.” In reality, my “Website Feature” entity is in fact part of the “Website Platform” I mentioned. It “lives” there permanently once I build it. So it should go in the “Website Platform” app. It will no longer be “located” in my “Project” after it is built, correct? As I expand my “Website Platform” app, I want all my “Website Features” to be represented there. However, my “Project” Type is going to be used for all kinds of work. So with this in mind, it became clear to me that a great way to handle this is to simply put the “Website Feature” into the “Website Platform” app as a Type, then relate to my Project in which I’m building the feature. In essence the “Website Feature” is in both places and full trackable in boards, reports, etc. However, you can see here the benefit over a simple “have this entity in two folders” approach. What I’m doing by thinking through where the actual “item” entity resides in my company structure, I come up with a more accurate representation of the work. If I just had this in two equal folders, I don’t have this level of detail.
So this is an example of where you guys have really figured out a solution that shines.
I hope I made sense. I am really starting to see the sophistication of how you guys have structured Fibery, really forward-thinking and very eager to see what you come up with next!
- apply too much of their own beliefs around how structure should work. I have been drawn to Fibery because you guys clearly have the approach to build something that is not a huge challenge to configure, all the while being definitely a “no code” type solution, which allows the user to really configure to just about any need, without superimposed structures. And I also will repeat here that so far, I find you way ahead of all other no code stuff I’ve tried on ease of use, UX and UI, familiarity for team members who are not admins and need to use the tool, and speed around navigating and manipulating entities. I will count on your guys excellent support to help me with the more challenging parts of my set up such as this one. But in the end, that all makes sense what you wrote. I am curious how you will implement other “categorization” tools such as tags and so forth.