I had commented this in the wrong thread, I add my idea/suggestion here as it’s more fitting:
I give an example:
Let’s assume I have a dataset of documents. There are different categories of documents, indicated by a single-select field “Document type”. Depending on the document type, I might want to see different fields, and even different rearrangements of the fields.
I continue with a suggestion:
Let’s assume you could rearrange and resize fields within entity view.
You could have any view you want, always just for this entity. However, if you could also save the “entity view” now, give the “entity view” a name, you could:
Simply select the desired, pre configured, entity view from the list of saved entity views (within an entity)
Automate entity views via automations by desired criteria.
If entity field “document type” updated,
then entity view (for step 1 document) = A, if “document type” = X
= B, if “document type” = Y
else, do nothing
Something along these lines? Hope it’s understandable. Not sure if this has been suggested like this before.
Just wanted to note that I saw this is next, and it’s a bit exciting:
However also wanted to note that my visceral reaction was “Dang, just collapse? I wish we had full, unique, savable layouts per-DB”. I know, it surprised me too, but that’s what I wanted.
Which is to say, individually-remembered collapse states per-DB layout is great, and it may be that for many roles a single state will represent their needs fairly consistently. But for me as a “jack of all trades”, interacting with a lot of different data in different ways at different times, I’d love to see more fully articulated and separately displayable (even linkable?) view setups/templates.
I think this would also apply well to e.g. publishing of Entities, where the configuration if the view wouldn’t necessarily be desirable as an end-user feature, and yet you want to be able to show particular view configurations to the general public, vs. different ones internally, etc.
All that said I’m still excited collapsible “left pane” fields are coming!
Probably more the latter, though perhaps it might interact with the per-entity Permissions system in some novel way. But that’s not my main interest. I think if you could setup views and let other people access them, without each person having to set it themselves, that would be a benefit. It could also remember each person’s last-selected layout, and an admin could set a default, that kind of thing. The collapsible sections and remembered per-user preference is a nice first step, don’t get me wrong, and seems simpler to implement. I just hope we eventually get beyond that, and some way of having multiple, selectable layouts seems like a good intermediate-long-term goal.
I love the idea of selectable layouts. Would essentially be a way of doing tabs for different workflows within an entity.
With the ‘entity view list view’ add, my team has started using our user profiles as a personal homepage. So many different databases flow to our user profiles. Being able to quickly select an entity layout and all other fields collapse (and ideally disappear) - would save time scrolling and looking for what we want
Bumping this for visibility and greater consideration.
Just like we can currently create purpose-driven views in Fibery, Coda’s “Customize view” and Airtable’s “Interface designer” let you create purpose driven record/entity views, and is a feature sorely lacking in Fibery.
I can create a Table view and someone totally new to Fibery can pretty quickly figure out what its for and how to use it. But the second they open the record view from that Table they get overwhelmed with fields and need training on what fields can and can’t be edited. Even though I created the entity view I find myself hunting for specific fields when I do a repetitive workflow (eg. onboarding a new client, creating/updating a task type record, etc.)
We discussed several Views per Entity, but so far did not go into implementation. One reason is that it will make Fibery more complex, since now you will have a selector for Entity View and we are not sure it is a good idea to have it. You can hide fields here now, but do you really need several Views per Entity? Can you provide your use cases?
We also try to solve explanation problem with Fields description. It was released last week. You can add a Description for any field and explain what it means.
Lessons Learned / QAQC
(a place to capture new and review automatic connections based on project data)
In my opinion, most entity pages do not need tabs, but the ones that do need it, really need it. For example, our task entities don’t need it, but our project entities really do. In my use case above, four tabs is a lot easier to manage than ~20-30 blocks on a single page. Company pages is another example that I would definitely use ‘views per entity’ for.
With the to-many relations block update, we are using entity pages a lot more than we used to, but with so many to-many relation blocks on one page it is very easy to get lost and waste time looking around.
For user complexity - the drop down view selector is great for to-many relations blocks, but in my opinion drop downs would not be ideal for ‘views per entity’. Big tab buttons that scrolled with the frozen header at the top would make it more intuitive
Yes its great for hiding “helper” fields that shouldn’t or rarely need to be edited, but because it hides it in all views of that DB its not useable in cases where you occasionally do need to see/edit the value for that entity.
I’ve though about this a lot the last few days and if there isn’t the time or resources to create something like Interface Designer for Fibery what I really want as an alternative is
the ability to create custom entity views that let you specify which fields to show/hide and maybe their order and…
for each Table/Board/etc view, the ability to specify what custom entity view is pre-selected when the entity view is opened
For a use case example, we are a code & no-code dev agency and we have a Client database that has a 1-to-1 relationship to a Status Check database. The main reason Status Check was created as a separate database is as a workaround to not junk up the Clients entity view with irrelevant/excessive fields. This workaround has the downside that I now need to use Lookup fields which aren’t directly editable so I’m Alt clicking a lot to update multi-select fields that are in the other DB - and something I then need to train other users to do.
I would much rather have an “All Fields” entity view that shows all fields and then a custom “Status” view that just shows certain fields related to checking/updating a clients project status and is the one that’s selected by default if view the entity from the Status Check Table view.
Because right now when we are adding a new client or updating their info we have to use the entity view so it makes sense to have all those fields at the top. But then here is what other recurring workflows look like:
We completed discovery, so record the client budget/our estimate/etc. → open up Client entity, scroll past and ignore all the irrelevant fields, try to remember which fields need to be updated when discovery is complete
As a project manager, do the daily status check for the client → only use the Status Check table view that’s created for this type of workflow, don’t open the entity view because its overwhelming
As a third party example, we setup some service integrations for an Airtable consulting/setup agency that strangely enough used Fibery for their CRM & project management. This client had a far more complex Fibery setup than us and their entity views were a long and hideous mess - as an outsider even after a few hours I had no idea what I was looking at and what entity fields were associated with what workflow. I later found out this client decided to migrate their workspace to Airtable - although that might not be just because of the entity views.
In summary: It shouldn’t be intimidating to open up entity views. Someone new to Fibery doing a specific workflow (ex. adding a new contact) should be able to open the entity view and easily see what they should and shouldn’t edit with minimal training.
And I would add, it would also be super useful if the “default view” for a particular entity could be defined by a formula. So the “view selector” would have an entry for each manually created named view, plus one for “Auto” (a formula), and another for “Show All Fields”.
Also, regarding the current ability to hide fields (which is awesome) – I would find it very helpful to have a “Show All Fields” toggle in the fields selectors, which would TEMPORARILY (and only for the current user) show all fields… and which could simply be un-toggled to return to the previous selection of fields. Or perhaps this should be in the “View Selector”?
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:
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.
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 relationswould 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.
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?
It’s yet another polymorphic make-do attempt: You have a single-select (or formula) field that defines the “subtype” of each entity, which allows the appropriate view to be automatically presented by default.
This is such a good idea that seems obvious in hindsight. Just wanted to highlight it - I would use this a lot (and sending public Fibery pages to outside firms seems like a great way to introduce Fibery to more people).
We really really really miss something along those lines!
It’s become such that we have to arbitrate between creating new relations (but increasing the clutter in some already barely manageable entities) or work using references only (but renouncing to most of what relations are bringing - formula, lookup et automations).
Not being able to organise entity views according to an external context (piloted by a view or the value of a field for instance) is a real problem. Since polymorphism (which would be by far our preferred solution) seems dead in the water, this becomes very important.
I can provide a specific use-case to illustrate our problem: in our setup some entities are universal and shared across the organisation like Project. However, what you put inside a Project could very much be specialized by work domains. A software dev team will want to link it to features, bugs and commits while an accounting team will need totally different abstractions.
Either we stuff all those relations inside the same Project entity and we get an unmanageable monstrosity with everyone risking collateral damages whenever someone changes an automation or a field
Or we use specialized projects but losing the unifying Project abstraction that we use extensively in our common processes between teams.
A intermediate solution we are exploring is to have a sort of project pair (generic-specialized) keeping both projects partially synchronized through automation but it is exceedingly complex and frail.
Other option is to have the generic Project linked to specialized projects only using references but then it becomes quite complex to get information like metrics from the specialized projects into the generic one.
This is all about maintaining the right balance between “separation of concern” (a team should have relative freedom to organize its work tools without impacting other teams) and “shared processes” (which is the minimal structure shared by all teams to enforce efficient collaboration and prevent teams from becoming isolated islands). This is especially crucial for any organisation that works in a decentralized way (Holacracy, Sociocracy, Teal, etc.) as is more and more common.
If Fibery wants to be the unifying tool it tries to be, it needs to be able to address this need IMHO.