And we likely need even more relationships.
Having this on every page makes no sense.
If we minimize the relation block, one cannot see if there are relations in it.
The relation blocks cannot be hidden.
There is not insight in more than one relationship level deep. For example, if I have a project with a page, and that page has a subpage, the context of the project is not visible. (this indireclty relates to this issue but will post it separately also. The idea is that the current display has no real support for efficient navigation of relationships.
Fibery allows to connect everything, but when doing that results in confusion and lack of insight in context and absence of a smart way to navigate relationships, thus the whole purpose of connecting everything loses its point. I think Fibery is currently not useful for real organiations but maybe for a small team with a simple project. Sorry that say it like this, but I spent a month on Fibery trying to make it work but I think it requires the developers to have a good look at fundamental needs…and indeed in the Fibery blogs is mentioned, a good look at the priorities.
One way to make the many to many relationships more insightful when actually working with it, is to have a visual knowledge graph available, which allows to see at least three levels deep in relationships.
When doing that, we could also implement relationship strength as a way to prioritize visibility in the graph.
For example, when working in a project and an entity is three relationship hops away from the project entity, Its association with the project could be kept in the visual context.
Relation fields can be hidden (as can all fields). Hover over the database icon, it will turn to three dots, and hide is an option (if you have the necessary privileges).
You can enable any number of levels of linked items with a list view. So if you e.g. have a relation to projects, and these have relations to tasks, you can enable project and task levels in the relation view.
You choose the levels to show in the same way as you choose the database levels to show for a standard list view.
This might not be obvious, but just use one or two relationship blocks with additional views on those blocks to visualize the other hidden relationships. A view on a relationship block can be used for any relation that entity page has, it doesn’t have to be for just the block titled one.
Our project pages have way more relationships than you are showing and we visualize all of it through about 20 views on three different blocks. There can definitely be some improvements to entity pages (node layout or tabs first of all), but I actually think the entity pages feel very navigable to deeper levels of connected relationships
Indeed. This is something that a lot of people don’t discover/realise (and can feel a little counterintuitive to some people). I often don’t mention it unless/until I know the user is already comfortable with all the other ways in which relations can be managed/manipulated/represented
Don’t know if I understand it correctly. Do you mean combining multiple databases via a list view? That is something I currenlty do in the ‘Sales activity log’ per contact
I’m currently looking into ‘how can we make things as easy and simple as possible’ for users. So if there is something I can discover, please let me know @Chr1sG
Basically, other than the block name, to-many blocks on entity pages aren’t tied to their named database at all. You could have a Task block and change the shown database to meetings. In your example, you could hypothetically remove ‘sales activity’ and still show everything else.
This offers a crazy amount of flexibility. The biggest downside is the block name. I really wish you could change this without changing the relationship name. Which would basically turn these into generic blocks to view any database tied to that entity.
Note also that any given relation ‘block’ can support multiple views via the drop down:
So imagine if your db A is linked via many different relations to dbs B, C and D, and B is linked to E, and E is linked to F.
For an entity of type A, the relation field which is called ‘Ds’ can actually be configured to offer a board view of Cs, a timeline view of Ds and a hierarchical list view showing (indirectly) related Es and Fs.
As said above
!!!
But is often also a bit of a brain melt for some users
I did it the other way around I created ‘Sales activity’ to have the right block name. It doesn’t have a relationship with all the other databases; it’s only purpose is to show all data in one list.
So if you are struggling with the block name; you can simply create a database for the block name like I did🙈
Yes, first I thought ‘no way’ and then I thought ‘oh my god now I can literally do ANYTHING’
I’m glad that I already discovered it and that I’m not the only one with all these weird workarounds
I created ‘Sales activity’ to have the right block name. It doesn’t have a relationship with all the other databases; it’s only purpose is to show all data in one list.
