I would like to revive a subject from the April 20 Changelog re: customization of the great inline mentions we have in Fibery (one of the best features, please guys don’t change this it’s good as is!)
My request is only about what you can see about the Inline Entity, following on @mdubakov assertion here from that post:
My team makes great use of the Inline mentions, and at times we are seeing that we could definitely use some customizations. For example, we reference Users a lot, and they always bring in the name of the Avatar if they’ve uploaded one, so that takes up space in your copy unnecessarily:
Also we have some other Types that could use the customization.
Just wanted to get this out as an official request in case others wanted to support it. Cheers!
I wanted to add another use case around this request: Entities that are used as “Tasks.” A typical use of this would be to create follow-on tasks in Meetings, this may be done by the note-taker inline. It would be super convenient to be able to see the fields of “Due Date” and “Priority” inline and not have to open the Entity to scroll through the details and select these fields after first creating inline, which we found usually takes some time as the Entity details window can take a moment to open, and not everybody has memorized where those fields are. If you could simply have them available inline, it would make the filling out of those attributes very quick & easy.
This would truly be a unique feature of Fibery that I have never seen any other app even come close to. Others do have inline mentions, just none allow this type of customization.
The way I would prefer to see it handled is an option for every field to “promote to/display on in-line mentions”. That way everyone could display whatever they wanted in-line. Some people will want a lot, while the majority will not, but a system like that could equally serve both needs.
Yes and thanks for proposing an excellent implementation, hadn’t thought of that! This would also nicely keep this at the Type level. 100% what I had in mind with surfacing the request again!
The only comment I would add to this discussion is that it will be interesting to hear where you think the choice about which fields to display should be made.
I believe, for example, that when an entity is shown in a collection, you can choose which fields to display, but the setting is applied to every collection for that type. This means that your choice is tied to the type, rather than being determined by the referencing entity
This has some disadvantages, since one might want the choice of visible fields to be different in different places.
The same will be true for inline mentions. Will you always want the same fields visible in all the the rich text places where an entity of a given type is mentioned?
That is certainly an interesting and valid point. I know that there must be limits to the customization however and so personally I feel like a single global setting would be sufficient. Not perfect, but it would be up to each admin to balance the needs of the various areas where they use entity mentions. I could certainly envision a way to do it more flexibly, but I question how much value it would bring for the dev time and UI complexity involved. How many people would ever actually find and use that setting?
The way I’m getting on in Fibery is that I think I’d be Ok with being able to customize how each Type shows up when @mentioned across other Entities in Fibery, per @Oshyan ’s solution here. I have things like:
Tasks as I mentioned, I’d like the basics for Tasks that you get in other apps - assignee, due date, priority, etc. I don’t think I’d need to have some Tasks with that showing, and others without that - in other words, be able to control per Entity as I think you are wondering about
Some services (vendors, software, etc.) my team uses. These have states, but I don’t need to see the state when referencing. We have states like “on a trial” or “Purchased,” but I don’t need to see that in the references.
It would also be great to limit this from the default, as right now in fact because I get all those fields, the Rich Texts get overloaded, in particularly if I have added an assignment extension, but haven’t assigned anybody, I get a blank “circle” next to the referenced entity which just takes up space and makes the Rich Text busy. Likewise with the aforementioned State if I really don’t want to include it.
I think Collections are another animal with a lot more to talk about and improvement needed, like showing differing views in that area a la Notion, something @Oshyan also has talked about. But with mentions, I think there is a lot less need to customize.
I’m curious, when would you have a need to customize per entity which fields in an @mentioned entity are displayed?
This was one of the first things that came to mind when I started trying Fibery out. I really liked the inline mentions of entities, but found that often you are forced to overwrite the Name field with a formula to expose information from the entity without this feature. This results in an odd user experience where you add a new entity quickly in some view, but can’t set the name. So you have to open it up to set the values that are used to create the calculated name field.
I’d be ok with a starting point where there is some global configuration for how each Type shows up when they are referenced anywhere. Then, later on down the line worry about having different configurations in specific contexts.
In your specific approach to addressing the ‘show custom information’ problem, by using naming formula, if you assume that is the best approach moving forward (i.e. let’s assume no additional customization options are added for in-line entity info display), then how would you want the “can’t set name from inline mention” problem to be solved?
I was thinking about inline references in the context of blocks and I thought it would be worth it to bump this thread up again and hopefully get it tagged as related to “blocks” and linked to the block-based rewrite of rich text fields [IN DEV] Migrate Entity View to Blocks.
Current State
As discussed in the thread above fibery currently shows inline entities in a very particular/fixed way:
While the inline reference is quite powerful, the inability to customize it is a real paint point for me. One of the suggestions/workarounds has been to either manually include some of the details in the name or use a name formulas so that the information at least remains dynamic. I think this approach is very problematic because now the entity name is not really the entity name but an amalgamation of a few different fields. There can also be different contexts in which the entity needs to be referenced where some of this information is not needed or desirable to be visible. Finally, I think this approach adds additional complexity, duplication and an opportunity for contradictory and out of sync information to be added.
Possible Future State
General Idea
Provide users/admins/designers ability to define some templates/styles for each entity type that can be used in rich text areas/documents and offer different information in different context.
There could be a default template that is used by default but when a reference is inserted, the user has the ability to change the template used.
I assume this means that a template id will also have to saved alongside the entity UUID but hoping it doesn’t add a lot more complexity.
I know building a tool to develop the templates visually is no easy ask. However, I am thinking that a starting point might be a basic text-based template language (or something html/css based) that allows some of the power users to start with customization.
Inline Reference Possibilities
The above approach enables some really helpful customization such as:
Controlling display of the text (i.e. enable/disable strikethrough when not appropriate) or changing display icon (text, icon or nothing):
Showing entities as texts only:
Controlling the attributes that are shown inline:
And of course enabling some items to be quickly editable (like dropdowns similar to workflow items):
Block View of Entities
When creating new entities in documents and rich text fields, one of the biggest pain points is that after you created the entity, you still need to click through to populate it and so you end up breaking your flow.
This is particularly problematic with entities that have formula generated names as you absolutely need to add some details before the new entity makes any sense
However, it would be great if when you created a new entity:
While the item is still in focus, you would be presented with select (preselected fields based again on a template) to enter additional details you generally capture when the entity is created:
Once editing is over and focus is moved, then some of the information is shown (again based on a template) without the field editing boxes:
Or to keep things more simple, something like (with ability to fold the details):
This allows users to maintain the context but ensure that the relevant information is captured in the entity where it makes sense rather than in another field somewhere else
I think a template approach would be the best way of addressing this so that the admin/designers can determine what makes sense for their users.
These are some great ideas! Seems to me like 3 related but different features:
Customize entity references. These need almost certainly to be single line, and collapse/expand is probably not easy to support since they can be in-line. When an entity reference is within a larger paragraph, how do you sensibly expand its contents?
Expandable in-line entity embed. This could work similar to a reference as-above, but would likely be its own block.
In-line pop-up “quick fill” for entity fields when created from e.g. selected text.
I think these are all good concepts, and I have some further thoughts on #1 (though some of my concerns may be irrelevant; I’ll leave it to Michael and team to determine that ).
I think the most obvious and hopefully easiest thing to implement here would be using the variables for each field name, much like the formula editor does. In fact a formula editor-like experience would be great, but even just a one-line input field for specifying each “template” (with a separate field for the name of the template I guess), and in-line search/auto-complete would work well I think. So it’d be something like [Name][Creation Date][Created By] would produce e.g. Task one 13/7/2021 Oshyan or if you wanted to get a little fancier, [Name] created on [Creation Date] by [Created By] = a reference that reads: Task one created on 13/7/2021 by Oshyan. And any field where it makes sense to allow interaction would do so (this could be something additionally controllable, but it seems overkill in my view).
It’d be even easier if it were a dedicated UI like the formula editor, with a list of available field names, etc. I imagine that should be easy enough to implement as well. But basically I favor a super simple implementation of this, akin to what programs like Lightroom have done for their variable-based file output naming options. Something that is flexible and powerful and simple enough to use, but won’t take a long time to implement (hopefully).
Probably you’d want it to just default to the selected default template. Which would be specified in the Type definition somewhere I guess. And then have an option on every reference (in e.g. a rich text) to change the template used for that particular reference.
).