I’m interested to hear users experiences and self-made solutions to have structured documents/pages that consists of multiple entities, such as ‘paragraphs’ or ‘blocks’, which appear on the same page display.
Challenge:
When a large document contains multiple sections (either pages, chapters or paragraphs) the current rich text field and TOC is not suffiient for a writers an readers experience. And when such document entity is split up into entities and sub-entities, the creation and display of such hierarchical entity bundle is cumbersome.
Option: Feed view
What comes close, is inside the document entity to display a paragraphs field as a feed view, but this has the following limitations:
Cannot change its sorting using drag-drop
Cannot be printed together as one document
Scrollbars apear when paragraph is long
Not possible to display feed view title in H1 H2 header format.
Use cases
Project Documentation: Streamlines updating and organizing project reports.
Educational Content: Facilitates the creation and revision of educational materials.
Business Documentation: Aids in managing complex business and technical documents.
Imagine that your “document” actually consists of data that is in many entities; in a sense, your entire Fibery Workspace is a “document”, with distributed content. So the challenge is how to organize all of this distributed content so it is accessible/searchable in useful ways.
Fibery Views are one tool; Fibery Search is another; and creating custom Rich Text documents is a third way to expose specific views into this vast, distributed information store.
Each of these modes has its strengths and limitations.
Right now a Rich Text allows us to insert a link to a specific entity, and the entity Name will be displayed. It would be useful to extend this ability to show other entity fields besides entity Name. The abstraction of this would be to insert an arbitrary Formula which could include references to any entities and fields.
You can “sort of” accomplish this now by adding an “Update” Button that (re)creates the content of a Rich Text field from a template which includes fields from other entities. This can also be partially automated to happen in response to changed fields.
But Rich Text is not (yet?) a fully generalized platform for creating arbitrary constructions and views of any data. It continues to gain more capabilities in this direction.
Just for the benefit of anyone who hasn’t discovered it yet, it is possible to configure entity mentions to display other fields in addition to the name. Just click on the db icon for the mentioned entity and choose which fields to show.
It will apply to all mentioned entities of the same type though, and currently doesn’t support rich text
This is one of the great features that I use all the time (and I am so glad many of the things I really wanted eventually made it into the design). The one thing that would really supercharge this is the ability to create and select display templates for the mention. Right now clicking the db icon lets us change the fields that are to be shown (which applies everywhere there is a mention):
However, if you could define the display templates at the db configuration page and use this menu to select a template, that would really be great (e.g like this):
There would be a default but the user has the ability use a different style/template to show different fields. One use case for this is including people/contacts. There are places where you just want to mention the person’s name (default case) but there are instances where you might want to also display their title and company (e.g. a bullet list of contacts). It would be very helpful to be able to just simply select a different display template in those instances.
In line with the other discussion in this thread, it would be amazing if you were able to include entities as blocks/cards within rich text & documents (see also Inline reference - card view also the process flow described here). I think this is really the most viable option for embedding rich-text fields from entities into documents:
That would be one possibility; what I have done in the past is use a Button automation to overwrite a RTF from a template, completely recreating the RT content from scratch. In this scenario the RT field is treated as read-only (even though there is no good way to actually prevent users from changing it).
The RT template in the Button automation can include whatever references and code are needed to recreate some “Dashboard like” content for the field.
