When using multiple Entity Views, the default first view cannot be set as the actual default view to ALWAYS show when navigating back to the entity.
When navigating away from an entity, the last Entity View tab that was opened, stays open and when retuning to the entity will show that tab.
There is a workflow problem with that.
It is only useful when we intentionally want to return to that tab.
It is not useful when we just grabbed some info from a tab and then when returning to the entity, we want to see the default tab. Because the purpose of a ‘default’ tab is that it allows us to see that.
In order to accomplish that, we could implement that either:
The entity always show the default FIRST tab, UNLESS another tab is set as ‘STICKY’.
or:
The entity shows the LAST VISITED TAB, UNLESS another tab is set to ‘DEFAULT’.
Maybe we can brainstorm about it, since it is a recurring tension in my workflow.
Especially for new users not accustomed to random tabs staying open, it is very confusing to see other content than you expect, its not the first default tab content.
There is no such thing as ‘the default view’ except for the very first time a user visits an entity of that particular type.
It is by design that on subsequent visits, the entity view shown will be whichever one a user last visited.
It is common that different people prefer to use a particular entity view, and for those people, always being taken back to the first tab is unwanted.
It is not ‘random’, and I don’t know why you think it is confusing for a user to see the same entity view they last used when they return to view an entity any subsequent time.
If anything, I think I would be annoyed if I chose a particular entity view, and Fibery ignored that choice when I revisited an entity.
As stated here, I personally think that it makes the most sense for each individual entity to be associated with a specific entity-view, since views may often be customized for a specific “sub type” of entity:
It is in plans that the entity view can be made dependent on the value of a field, to achieve what @Matt_Blais is describing.
Until then, the view is user dependent.
At some point there will likely be a tension between these objectives (a view choice dependent on entity properties and a view choice dependent on a user’s preference) but we’ll figure it out
My other post was a request that until that “auto view selection by field” feature is available, the default behavior should be that Fibery should remember the last manually-selected Entity View for each entity, and use that as the default view for that entity; essentially that would have been a way to manually accomplish what field-based-view-selection will do eventually.
After all these years, we are this close to simulating polymorphic types albeit at the cost of having to manage all the fields of related “subtypes” in a single DB.
How would this work if the field value were to change? Either it remembers a user’s choice (per user and eventually per entity) or Fibery determines which entity view based on a field value, which could change. I can’t see that they can both be true.
Ok, but I suspect both are valid use cases, so I was kinda assuming that you meant that the introduction of ‘auto view selection by field’ would augment rather than replace any existing functionality.
Related, what I see as a design mistake, is that the entity title is UNDER the entity view tabs, instead of above them.
I get feedback that this is super confusing, since:
users expect tabs under the title to be sections of the entity,
and tabs above the title to be similar to a contextual navigation menu.
Moreover, now the entity title is under the tabs, it is mistaken by being the title of a tab or a entity section! (which actually would be great to have, a big section title and description for each tab)
This, together with the last open tab staying open, makes it extra confusing, or at least cognitively intensive. If the title is above the tabs, it would be much easier to understand.
albeit at the cost of having to manage all the fields of related “subtypes” in a single DB. 
