Great point Matt, we need a whole group around this subject…I really wish the team would at least think seriously about grouping requests. I know they won’t do votes as has been discussed many a time, but at least grouping would help organize this board. There is only so much relying on simply searching around in Discourse will do…
I might draw the loose analogy of using Gmail with no folders, and having to rely on search only to find stuff…
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