I think allowing multiple layouts per-DB/entity type (not necessarily unique to each entity!) has at least two very strong general use cases, that could be broken down into perhaps more relatable and compelling needs:
- Complex entities/databases
- Strongly differentiated needs based on role/workflow (either by position in company, department, or the type of contribution they make to a workflow/process)
Having e.g. Tabs for unique Layouts has a number of benefits that should all be considered:
- Reduces visual clutter while maintaining fairly easy access (similar benefits from Hide, but that has less accessibility to those fields vs. e.g. moving them to a Tab)
- Allows for quicker access to Fields which might otherwise be far down a large Entity view (i.e. I can click a tab to see things quite quickly which might otherwise be “below the fold”)
- Workflow or role-specific Layouts/Tabs make work faster for those workflows/roles
- Explanation of collective purpose, e.g. “These are all fields that relate to if we sell the item this Entity represents” (for the same reason that e.g. View or Space descriptions will be useful, higher-level descriptions of multiple fields can be valuable, not just individual field descriptions)
- And to be clear, I am not talking necessarily about per-tab descriptions, but rather that the mere act of collecting fields into a tab and naming that tab is a form of “description”, e.g. a tab called “Sales” vs. a tab called “Maintenance”, both part of a “Property” entity
Put simply, I think multiple, valuable results arise out of a very few simple added capabilities: Multiple Layouts, accessible in a quick way (e.g. Tabs), and ability to move/copy Fields to each Layout as-desired.
Complex Case
This obviously has to be focused on entities where a majority of the fields/content are not Relations, since Relations now have a decent solution with multi-view. The exception to this is if there are lots of different relations, which is in fact the case for me with many of my entities. For me I often need to document that something is related to something else, but very seldom need to actually adjust those things. I don’t want to Hide the fields for that (the need to view or edit that info is random and unpredictable), but it would be nice to actually have a Tab for all the potential Relations of these Entities (e.g. a Property which may have multiple types of owners, service providers, related projects, Sales activities, etc, etc.).
Note that Polymorphic relations would help address the need for this in some of my specific cases, e.g. I could have a single “Owner” field where I could link any of: Individual, Internal Entity, Partnership, etc. Right now that has to be done with 3 separate fields since each of those types of owners has significantly different Fields in their own, respective Databases.
Another perhaps even better use of Tabs in some of my cases would be to separate by “type” of data, again for quick access and having everything I need for a particular “mode” of interaction in one place. So for example Financial data and Relations for a given Company could be usefully separated from Contact Info, etc. Currently we assume that we want to find Contact Info more often, so we put those fields at the top, but when we are looking for Financial Info, not only do we have to scroll a fair bit (and when checking such info for multiple entities in sequence, this is especially annoying), but we also have to deal with the visual distraction, etc. of all the other fields unrelated to our current purpose.
I should also address the fact that some of this complexity could potentially be handled with separate Databases and Relationships, but this has its own issues that e.g. Tab organization of Fields on Entities would not share. We already have the ability to break things down into multiple related Databases and yet we don’t in all cases, because there are challenges, limitations, etc. So the Tabs suggestion has its own, significant utility.
Entities where a majority of Fields are right-side are another case where Tabs could be useful. You could even have a more efficient layout that might interact better with Pane Nav, especially on <4k screens (I am finding Panes a lot less smooth and useful on a 1080p laptop screen vs. my 4k 32" desktop display where two panes side-by-side both have to have their right-side Fields collapsed all the time). This is of course a further extension to the concept, and yet more work to do, but it also speaks to the possibility that unique Entity layouts might play into further long-term optimization of multi-view, panes, etc. which hopefully speaks in its favor.
Role/Workflow Differentiation
This one hopefully needs less explanation, it seems quite clear in my mind. If you think of the different needs of a Product Manager vs. an Engineer (developer) both looking at the same Feature entity, the PM is quite likely to want access to different fields than the engineer, most of the time, and having unique Layouts/Tabs for each would streamline both their work.
Organization Makes Capability Accessible
Bottom line I’d say this would be a notable Quality of Life and UX improvement, making Fibery more pleasant to use. It is not a game-changer as far as what you can do, but I think there is already plenty of power in Fibery. The challenge to me now seems to be more about how to organize and make that power most accessible to “average” people. To my mind this would be a notable improvement for many.
Misc. Features of Tabs/Layouts
- We should be able to link to a given Tab/Layout of an Entity.
- Set a Layout as a Default
- Share only one Layout (i.e. publicly)
- Be able to Pin Fields but hide from the Layout itself (effectively creating 3 areas where fields can live, left and right column plus pinned header)
This is an interesting and great idea to go along with all the above!
Exactly this! And with Fibery’s aim to encompass so many processes from other tools, it is all but inevitable that Entities will become complicated with Relationships and other Fields. Being able to manage this without just hiding them, or having each user collapse things on their own, would really be advantageous, and all the more so as any given customer’s Fibery setup matures.
Woah, can you give an example of how you’d use this?