What I see as the general use case of the pinned fields at the top of an entity display, is that it is mainly used to navigate, for example to parent entities or categories. The pinned fields have another purpose than to directly edit the field.
I advise to make the pinned fields links instead of editable fields, but allow them to turn into editable when using Alt or Ctr.
This also relates to the needed UX improvement, that Fibery does not become just a storage system but can be more easily used/navigated. Intuitively, people look at the top of a page for navigation, but Fibery does not have that; navigation options are scattered over the fields across the entity display. The pinned fields could solve this issue (although it’s a workaround for a better top navigation feature) by making the pinned fields links clickable without Alt.
Apart from the need to reduce complicated combined clicks when navigating, the alt-click sometimes does not appear to work, and it takes me a few times to make the link work instead of editing the field. I haven’t figured out what causes this. But it adds to my motivation to make Fibery more navigation friendly.
Actually, we are experimenting with this right now. The edit-to-navigate ratio differs wildly from case to case, so simply doing a 180° with alt+click won’t do. Also, few people discover alt+click pattern on their own, even with the tooltip.
I agree what getting rid of any Alt click is the way to go.
But I understand that you suggest to have a direct link button appear on hover. That is an improvement, although still based on the idea that pinned fields are not for navigation primarily. Such an arrow button is very small. Therefore, I’d suggest to reverse this behavior: make the arrow button have the function to edit the field (as dropdown editable field) and allow the majority of the surface of the button functional as direct link.
The UX tension of this topic is about the challenge to navigate, which is one of the challenges that the Fibery design now has. For example to get to the meeting of a minute, to get to the project of a task, to a team of a user, etc. Even tags are just created once, aft that they are used.
The little arrow on hover will still be cumbersome, a bit similar to the (old and new) table view entity title column, which also appears on hover. The difference with the pinned fields and the table view is that it is not primarily used to navigate, since for that we have the list views.
It may be that we need to completely rethink how common navigation and workflows that happen are made easier for content users, which are the majority. I myself am social systems designer and give the end users priority in their workflow expience.
One option would be to allow users to modify the their default interface settings and behavior.
Your examples actually show that the ideal behaviour varies with context. If a field is a link to another database, then it may well be that more often you want to navigate to that entity. However, if the field is a select field (‘tags’) it is probably more likely that you want to change the tag (or add more tags if multi select). It is not common that you want to navigate to the tag itself (although this may be the case if you want to modify the tag’s properties, e.g. the ‘Final’ checkbox).
I agree with @Yuri_BC, I DO want to go to the tag itself. The to-many block views on entity pages mean that even a tag page is interesting. It’s a way to visualize all of the entities tied to that tag, that is very useful to visit and has the potential to generate insights or encourage you to explore further to other entities.
In my opinion, one of Fibery’s biggest strengths is that entity pages don’t feel two-dimensional. It’s not just a reference page, instead entities are something to open/visualize/dive deeper. Quickly navigating through them boosts your ability to explore your databases
That’s interesting feedback, since a lot of our users do not explore the ‘tag’ entities (based on my experience from customer calls etc.) but this could be an issue of discoverability, so it’s not necessarily black and white either way (but nothing ever is! )