@kalman and anyone else of the design team (please share), please check this research paper about Fibery.io I made today with ChatGPT4, comparing it with other second brain apps in the context of the Fibery strategy.
Because redesigning the relations likely has major impact on the whole architecture, it will be interesting to read in that context.
And I like to know, if this implementation of ‘reference entity’ will address the issues that we have with references:
The basic functionality of references, and their current diferrence with relations, in my experience give problems in common use cases.
Short case description
When I create in-text entities (such as tasks) in rich text fields, I expect them to show up as relations in the relations field of that entity. But in-line references don’t show up as relations.
Problem: that makes in-line references useless in most cases since they lack the automatic relation to the entity.
Longer case description
The issue at hand pertains to the creation and management of in-line references within a rich text field and their subsequent representation as relationships within the system. Currently, in-line references created within a rich text field do not appear as relationships to the parent entity, leading to a disconnect between the context of creation and the standalone nature of these references. This can cause confusion and inconsistency in the workflow, as these references are not fully integrated into the system’s relational structure.
Automatic Relationship Creation: The system should be designed to automatically create a relationship between an in-line reference and the parent entity within which it is created. This would ensure that the reference is not just a standalone entity but is tied to the context in which it was created.
Visibility and Management: These in-line references should be visible and manageable within the parent entity’s relations list. This would allow users to see and manage all related entities, regardless of how they were created.
Bi-directional Links: The relationship between the in-line reference and the parent entity should be bi-directional, providing context and facilitating navigation between related entities.
Integration with Other Features: The system should ensure that in-line references are fully integrated with other features, such as search, filter, and notification systems.
This issue and the proposed solutions can be applicable in several scenarios:
Meeting Management: As mentioned earlier, during a meeting, in-line tasks created within an agenda item’s ‘description’ field should automatically become related to the agenda item.
Project Management: When discussing a project within a project entity, any in-line references created to denote tasks, milestones, or risks should automatically be related to the project entity.
Documentation: In a document entity, any in-line references created to denote related documents, sections, or issues should automatically be related to the document entity.
Customer Relationship Management (CRM): In a customer entity, any in-line references created to denote related interactions, issues, or opportunities should automatically be related to the customer entity.
By addressing this issue, developers can create a more consistent, intuitive, and powerful system that fully leverages the potential of in-line references and relationships.
We have Agenda Items that relate to Tasks and Decisions. The notes (minutes) taken are written in the agenda item entity field ‘Description’, which is a rich text field. The note taker (or the people collectively taking meeting notes) want to create in-line (in-text) tasks, which is already possible using the inline references. The entity is created automatically, using as title the selected text that is converted to the task. This is a quick way to create inline tasks which tightly maintains the context and discussion which is most relevant to the task.
Apart from that, users want to create Tasks related to the Agenda Item entity in the standard way (not in-text) in the Tasks relation field. Both actions to create Tasks need to result in the same outcome: tasks that are listed in the Agenda Item entity.
The problem is that the in-text task does not appear as a relationship to the agenda item. It basically is a stand alone tasks that contains the reference to the agenda item, but cannot be handled as a related task. This creates confusion and inconsistency in the workflow.
Hey there. Yes, I’m finding that now. I was hoping some uber-users might have workarounds but I guess it’s copy/paste for the moment. The challenge I’m having is copying and pasting in different spaces and keeping track of the proper URLs for each. I think Fibery has an amazing foundation and a bright future.
You know what I’m missing the most of all after using? A developer plug-in community. I’ve seen some really bright people posting interesting solutions and workarounds (including you!) and there are certain functionalities that I would have my team build (as apps maybe, I still haven’t gone done the path of their API enough, though it appears promising) and share with the community. I’ll check out your transclusions post.
I’ve used a few apps that identified everything as bullets and found Obsidian’s way very flexible (not bullets). However, that may simply be because I didn’t use the bullet method enough. I’m thinking of using in Docs (or whatever emulates docs) and showing things as paragraphs, etc.
I merged it here because I want to keep all related conversations in this topic. I hope you don’t mind.
Thanks for your questions.
The Reference entity has the functionality you mentioned. The feature description lists all of the fields that are needed, including:
Reference source, which is automatically added when the reference is created,
One or more reference targets,
and these will make bidirectional relationships between the source and targets.
The Reference entity will be a separate database and be integrated into the search, filter, report, and notification systems. We still need to solve some riddles before implementing your use case, but the overall goal is similar to what you described.
The visual representation of the Reference entity is not yet clear, but I can clarify a few things in the document based on your question.
I think our competitors have covered this topic well. I like how Dovetail solved it, but there are still some UI challenges we need to think about. These two features will not affect any Reference entity-related questions, but they will improve the current state of Reference creation.
The integration of a token system could further enhance this New Relation/References feature in several ways:
Field Combination: As discussed earlier, tokens could allow users to combine fields from different entities, including relations/references. This means that you could display information from a relation’s fields alongside the entities it connects, all within a single cell or card.
Nested Relations: If relations can contain other relations, a token system could help navigate and display this complex, nested data structure. For example, you could use tokens to display information from a relation within a relation.
Custom Formatting: Tokens could allow users to control how relation data is displayed. For example, you could use tokens to define the format of a date field within a relation, or to control the display order of multiple fields within a relation.
Dynamic Views: Tokens could be used to create dynamic views that change based on the state of a relation. For example, you could use tokens to display different information based on whether a relation is empty or contains certain data.
Automation and Logic: If tokens are used in automations, they could also be used to automate tasks or apply logic based on the state of a relation. For example, an automation could be triggered when a relation is added or removed, or when a field within a relation meets certain criteria.
In summary, the integration of a token system could greatly enhance the flexibility, power, and user-friendliness of Fibery’s new relation feature. It would allow users to manipulate and display relation data in a wide variety of ways, making the system more adaptable to their specific needs.
The new reloaded reference will be an entity, which would allow a relation fields to contain such popup information (e.g. a summary field), as well as fields of other linked entities at the same time in one popup. Think for example when an inline task reference could show through a popup its Project, the project team members, related tasks, status, all at once.
@kalman this is great news and I just noticed your post! I have made many suggestions around references here in the forum, I hope you have read some of them. Sorry I am in a rush now, I will come back later and try to do a better job “referencing” what I’ve suggested, but here are a few: