Individual Layouts for a node, hide fields etc

Ideas & Features
1

This may be some work …
Currently the displayed layout of a Model shows all items. One good thing is, you can sort the fields. But you can not hide any.

Seeing “creation date” and other fields for example is most times useless and overloads the page.

BUT it is not a good idea to make it globaly for all views of a model anytime. It should be a way to have different layouts. Not sure what could be a good logic. Maybe it may depending on where you opened it?

In any case a toggle for “show all fields” may then help.

Another step may be in the future for a complexe customizeable arangement of fields with different coloumns, sizes etc.

3 Likes
2

Show/hide fields in the entity view shouldn’t be too hard to implement.

Depending upon what you mean, I disagree that it shouldn’t be global. In other words, I think it is reasonable that all entities of a specific type share the same settings for show/hide fields (but the choice should ideally be personalised to the user).

Airtable have a ‘hidden fields’ section that is expandable, and I reckon fibery could just mimic that.
image

3 Likes
3

With “not global” … let me expain better what I mean:

Currently the view is directly bound to the model. There is no way of different perspective on it. If you may compare it to boards, calendars etc, it is a different view on the same data. Similar idea for the model itself.

  • A default (global) view, which can be modified is great.
    • toggle of show hidden fields (user scope)
  • Additional views would also be great, depending maybe on where you open it.
    • dropdown to change view (user scope)

Example for different view:

  • A developer opens a Client and want to see his Servers
  • A sales person opens a Client and want to see his Contracts
3 Likes
4

I’m not sure what you mean by model…
Entity, type, app, view…?

5

Model=Entity

6

I understand better now.
How often does a user want to change which fields are hidden/shown? I assume not very often, so field visibility (on/off) that can be defined/chosen by each user seems to be a good first start. Multiple entity views with user-specific selection seems like a more sophisticated functionality.

Also, I note that the example you gave for views is one that is role-dependent rather than user dependent, which adds a layer of complexity. Should a developer get to decide which fields are hidden/visible for all other developers?

Alternatively, if/when the Fibery team manages to develop view-level permissions, a similar function can be achieved by allowing views (tables, boards, etc.) to be hidden/shown based on user. So a table view of Clients (with only the Server column shown) is only visible to developers, and a different table view of Clients (with only the Contracts column shown) is only visible to sale persons.

2 Likes
7

Yes, did not see it from permission perspective yet, but true, it might be a solution to hide something from the wrong groups.

We have a self-build mesh of a bunch of applications with a lot of relations. And currently they are all shown anytime. But IMHO the need to show something depends simply on the approach of what you want to do, repeating:

  • A developer opens a Client and want to see his Servers
  • A sales person opens a Client and want to see his Contracts

Means for me, if using a view in a development app may show different things and open a sales app. If the admin can adjust this for each view, it would be helpful.

1 Like
8

It is no problem at all to have different views (table/board/timeline/calendar) in different apps that show different fields, so that, for example, a user can open a view of Clients in the Development app (which shows the Servers column), and a different view of Clients in the Sales app (which shows the Contracts column).

However, if you mean that you want to adjust what relationship fields are shown when you open a specific single Client entity, then I’m not sure I understand how you envisage it to work.
An entity is an instance of a particular type (where a type has initially been defined in a specific app) so I’m not sure that is has any meaning in Fibery to ‘view an entity in an app’.
Although a table/board/timeline/calendar view can list many entities, when you click and open a specific entity, you’re not looking at it ‘within an app’.

Are you saying that you would want the visible/hidden fields of an entity to be dependent upon the route via which you arrived there? So if you click on an entity from within a view in the Development app, then you will see different fields than if you click on an entity from within a view in the Sales app?

If so, what would be the difference (in which fields are visible/hidden) between the view (table/board/timeline/calendar) and the entity itself?

9

I’m sure @AndreasHe can clarify best, but here’s what I understood their meaning to be:

I have a Type, Client, which has relationships to both Servers (Type) and Contracts (Type). If I open a given Client Entity, I will see lists of both as Related Entites. If there are many such related Entities, these lists could be long. If I am a Developer (Role), I do not care about Contracts, and if I am a Sales Person (Role) I do not care about Servers.

So what seems to be requested here is the ability to create different “templates” for viewing an Entity which show or hide different fields (including relationships). It sounds like doing this on a per-role basis might work (if you could define custom roles), but also perhaps it is desired to be on a per-user basis.

Personally I think that most of the use cases so far described here could be handled with two new features (that I would also like to have):

1: Collapsible field Groups. I don’t need them to be fully hidden, but being able to define a whole set of fields as a Group and then “roll up” (i.e. collapse) them would be really helpful for increasingly complex layouts. It would also reduce my need for more and more Types because part of the reason I define a new Type now is to reduce complexity of the Field contents in a parent Type (i.e. I move fields with some commonality into a sub-Type, but they could just as easily be in a Group).

It would be nice to have Collapse for individual Relations Entity lists, too.

2: Per-user persistent collapse state for Entity View. So if a given user collapses a given Group, the next time they view an Entity of that Type, it will still be collapsed. This would mean every user would have to manually collapse anything that was not relevant to them, but only the first time. The ability for an Admin to define view permissions for Groups would also be good, but persistent collapse state would also partially solve this, and has other benefits.

Hopefully @AndreasHe can correct me if I’m way off on what this request is :wink:

2 Likes
10

Yeah, that’s what I understood first time around but then I didn’t quite get this part:

It wasn’t entirely clear whether the use case is a role-dependent (~user-dependent?) feature, or something that depends on how/where you got to the entity from.

There can definitely be times when there is information overload for some entities, and I agree that being able hide/unhide fields (relationships or direct fields) is useful :slight_smile:

If it is a user-based feature, I was trying to elucidate whether a user needs the option to switch between multiple settings for field visibilities at different times, or if he/she is likely to be happy with the layout after it has been defined the first time. If the latter, then your #2 seems like a decent solution.

Finally, if it is a role-based feature, is it desirable that any user who is a member of the role group has the ability to change settings that will then affect every other user in the group? And what if a user is a member of multiple groups?

1 Like
11

Ah yes, I see what you mean, and it’s a good point. I took it to be an optional/additional idea, not the core of it. And while it seems interesting, it also seems complicated and fiddly to both implement and use. Better, I think, to simply define alternate views that either sit within a given app, folder, or promoted entity based on their layout and relation to a given App, etc., or to define alternate layouts that can perhaps be accessed as “tabs” in the single Entity View. In fact this is an idea I’ve had before, but more for general Views (Table, Board, etc.); rather than having each variation of a View be a separate item in the left menu, like ClickUp or Notion you could select different saved and named Field views and Sort options from a dropdown or similar.

I can only answer for myself, but this is where collapsible (but not hidden) Groups and Relations seems most helpful. That way you basically get the best of both worlds, you don’t need to “switch between multiple settings”, just expand the stuff you want to look at in any given moment.

Dear lord please no, hah. I’m not sure if anyone else would want that, but I definitely do not, and it sounds like a weird thing to have be possible. Defies general expectation of user experience, in my opinion, that one “peer” (group member) defines view config for all. Better to have admins able to do this, if it is possible at all to define on a Group-wide basis. I still favor the individual collapse/expand and possible persistent state of that per-user, but I could see some people wanting multiple pre-defined layouts for Entity View in a given Type.

12

Yep. Agree. And you’re right, when I say hidden/visible, I actually probably mean collapsed/expanded, like in Airtable :slight_smile:

1 Like
13

Hi Guys,

I believe you are getting onto the subject that has been frequently discussed: A way to reduce the number of fields that show when you have a plethora of Relations to a Type - to put it in more simple terms (which I hope I did!).

Here is one of the better previous convos on the subject, with @Polina_Zenevich in fact weighing in:

@Oshyan, when you mention here:

and touch on Notion, I think that is one of the biggest flaws of Notion, solved only somewhat by Fibery until there is a solution for handling unused Fields. Notion has the negative of a hugely long page when you add relations, which becomes redundant when you add a Linked Database, which in fact you need to do to get a lot of the benefit in Notion.

If Fibery could solve 1) the situation with unused Fields that must at the moment exist when you create a relation, and 2) more ability for “Collections” (that’s the proper term for the many-to-many groupings in an Entity’s details area) to behave like Subtables - for example inline edit - then there is a real benefit over Notion here. This is something that would really help me with my use of Fibery and the whole UX of your app.

And I can’t comment here without thinking of our old friend Polymorphic Relations, since their existence vastly reduces the need for so many fields. And again @Oshyan in that post, you said Conditional Fields would be helpful here. Very true, too! I have many instances when I have a dropdown that if I select one value, I’d like to have a related dropdown field that would either 1) only show up if that value is chosen, or 2) show some filtered options based on the value in the first dropdown. I believe Coda can handle the latter scenario with Formula Filters, so perhaps that’s something Fibery might get sooner than later?

Hope that’s a useful contribution guys!

3 Likes
14

Yep! And I’ll just add that I think Field Grouping and Collapsible Groups would be one step on the road to Conditional Group (and possibly field) Visibility.

4 Likes
15

Wanted to add to this as I think it’s the closest request to general “hiding fields” we have in the community.

I think we could really use some basics around this, to overview:

  • Ability to simply hide fields - good feature of Airtable and Coda. One use case I have: I’d like to show time in Status. My plan would be to have a formula field for each time the state moves across the workflow. If I have a development workflow, this is going to be 5 - 7 different states though. So I’ll need that many formula fields to calculate the time between each. I don’t want those visible by default on every Entity though. With these fields, I can then set up a nice Vizydrop report called “Time in Status” for my team.

  • More sophisticated functionality like Notion just released to customize on a per-entity basis how fields display Unlike Coda (to my knowledge), with Notion’s recent release here this past fall, you can now on an entity-level determine if a field is hidden or not, very useful. You can also across a table (Type in Fibery) determine if a field displays if it’s empty or not. Also something we could really use in Fibery given the reliance on fields and need to at times proliferate relations.

Thanks!

16

Just a quick comment about wanting a Vizydrop report to show ‘Time in Status’. Instead of using extra fields to calculate the time between each, have you thought about using the formulas available in Vizydrop reports to calculate these values instead?
That way, you don’t need the extra fields cluttering up the entity (hidden or otherwise).
:slight_smile:

17

Ok Chris, is that something Vizydrop can do? Look into the backend and see how much time an Entity is in a given State? If so they yes, this need would not have to have hidden formula fields to be solved obviously…

18

Here’s a screenshot of a report where a chart can be generated with the Y-axis showing the value of the date difference between creation date and modification date (just as an example, with dummy data):

image
image1694×938 64.3 KB

You can do similar things with the other Report types (Table, Metric and Pie chart) depending on how you want the data presented.

19

Ok thanks! Don’t mean to take up your time with this as we will look at this ourselves, but one quick observation - you mention “creation date” vs. “modification”. Specifically I am looking for how long an entity is in a state in the Workflow extension. So when it moves from “in progress” to “in review”, now long is in “in review” till it next moves to “ready for testing.” The only way I could think to log that info is to use a formula field that would read the workflow for just those two states, and trigger first when the entity hits the state initially, and next when it hits the next state, and then yet another formula field to get the difference between those two times, and thus give you the total time in the State.

Hope that makes sense!

20

Yeah, sorry my bad.
I realise now that I had in my head a vision of your setup that was close to this and that you already had date fields for the state change, and you wanted to report on the delta between two time stamps.
Not sure why I thought that! Serves me right for posting after a long day at work :slight_smile:
Your comment about looking into the backend should have clued me in.

Anyway, yes, I guess that you need to do something on the entity side of things (either action buttons or formulas) to get at least some of the way there. Sorry!

1 Like