Individual Layouts for a node, hide fields etc

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…

1 Like

We have this in mind as Important fields. Overall, we are discussing major Entity View re-work, that includes new 2-panel navigation, blocks, primary/secondary info sections, etc.

4 Likes

Ok that sounds like some exciting improvements indeed Michael. Wishing you guys big success in implementing them soon, my team could really use them!

1 Like

3 posts were merged into an existing topic: Tab Views in Entity Pages

Yes, this is planned till public beta release.

1 Like

Bumping this for additional consideration since I see its on the “NEXT: Consider for near future (1-2 months)” in the current version of the roadmap.

Specifically, I would love to see something like Coda’s “Customize view” as shown in the Fibery vs. Coda. The Power of Workarounds post.

asset-5

13 Likes

yeah, i’m excited about this

1 Like

I want to bump this now.

Still missing this feature. Showing so many fields can lead to confusion, especially when using some just for technical reasongs (calculation).

In Notion they implemented a simple show/hide function, which is better than nothing. IMHO a per view settings would be great.

2 Likes

This is in nearest future scope, right after Pin Fields on Entity View

2 Likes

Yeah! Great! I open a beer to celebrate this info :tada::grin:

1 Like

It is possible to Hide fields on Entity View now

5 Likes

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.

E.g.:

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.

1 Like

It’s possible to create Custom Relation Lists now :sparkling_heart:

(slowly improving…)

1 Like

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. :smile:

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!

1 Like

Do you mean that each user would have their own personal set of multiple layout choices, per db? Or just that a db would have a set of views which all users choose from?

2 Likes

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.

2 Likes

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

4 Likes

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.)

3 Likes

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.

1 Like

I talked about “Views per Entity” on this ideas page. But now that it is being discussed here, it may be best to close it and transfer those votes?

My use case: I manage commercial construction projects - My project entities are connected to the following categories:

  • Project Overview
    (general project info, percentage completion, upcoming summaries, critical tasks, potential cost exposure, inspection tracking)
  • Schedule Progress
    (tasks, procurement, milestones, MOP approvals, meeting minutes)
  • Trade Management
    (buyout tracking, cost logs, closeout tracking)
  • 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

2 Likes