I have been using Fibery to run meetings, where I take notes, convert notes into Tasks, Issues, etc. However, I find that I don’t convert text to entities as often as I’d like due to the amount of time it takes. While it is reasonably quick, when you are running a meeting it ends up causing a lot of waiting. Here is a summary of the issues I’ve noticed. Ordering One issue I have is just that the most common type of entity I create in meetings are Tasks, but even though the Task type is part of my Meetings app, it isn’t recommended as one of the first options. It seems like it is ordered alphabetically by app, then type, then Fibery types at the end. This ordering doesn’t bubble up the most likely to be used types. Too Many Options There are types that I have created that are helpers for other types and wouldn’t be something I’d typically want to create from a meeting. It would be nice if we could limit the entities that can be created in the rich text per Type. So, my Meetings type would have certain types that don’t make sense, but it might be ok for other Types. Too Many Clicks Another related issue to sorting is just that all of the types you can convert the text into are treated equally, even though you are more likely to be creating a small number of them. In each of these cases you have to highlight the text, choose create entity, then choose the type, then hit create. If there was quick actions or a menu of often used or configured options added directly to the menu bar, you could in many cases eliminate a couple steps. So, we’d go from 1) Highlight, 2) Click Create Entity, 3) Choose type, 4) Click create to 1) Highlight, 2) (in many cases) Click Create Task (or whatever else is important). If you needed to create any other entity, then you’d just fall back to the current behavior Instead of: [image] It could be something like: [image]

There is LOTS of room for improvement in the Fibery UI/UX experience, especially when it comes to keyboard shortcuts, navigation and optimization. TOO MUCH room for improvement. It is an impediment to adoption for me.

[image] rothnic: One issue I have is just that the most common type of entity I create in meetings are Tasks, but even though the Task type is part of my Meetings app, it isn’t recommended as one of the first options My other frustration is that although project is a relation field for both meeting notes and tasks, when I create a task in a meeting note, the project information doesn’t get populated in the task. I have to manually click each one. I know this is by design and requires careful consideration but it would really make free flow entity creation that much more intuitive. Full disclosure, I haven’t tried using automations to address this (might be possible with a nifty script)

[image] cannibalflea: I haven’t tried using automations to address this (might be possible with a nifty script) You can use this automation: [image] With this, when a task is created from a meeting (and therefore becomes linked to it) it will automatically be linked to the project that the meeting belongs to.

[image] rothnic: Too Many Options There are types that I have created that are helpers for other types and wouldn’t be something I’d typically want to create from a meeting. It would be nice if we could limit the entities that can be created in the rich text per Type. So, my Meetings type would have certain types that don’t make sense, but it might be ok for other Types. I certainly agree with this one, and I’m trying to think about how it might best be implemented without having to add a whole, complex UI/preferences area to set e.g. default search options per-type or something. This recent response seems to be related: [image] Filter search results based on Field Values Ideas & Features I sometimes also find myself looking for a way to exclude by default some objects from search (commits for instance) because they pollute the search results. It would be easy to include them back using the list on the right if needed. What I am starting to see is an increasing value from having more options on the Search dialog, but also some ways of either setting Defaults (per-user), or simply remembering previous settings… So here are some thoughts on adjustments to the Search process that might at least address part of your request, and possibly others: Differentiate between regular (e.g. Ctrl-K) Search and other types of searches, e.g. Create Entity From In-Line Text Search (CEFITS for short :smile:) There is already a difference between search dialogs in the text you see in the input field, which differentiates them, so maybe it’s already handled on the back-end Allow selection of multiple Types in search filtering I’m pretty sure this is a prerequisite for any solution to the entity proliferation problem in search, right? I don’t think it’s reasonable to try to precisely target only the Type you want to link to from every potential context - that suggests a whole, complex UI to handle it, which I’m trying to avoid. Once you have differentiation of search contexts, you can try to do more intelligent things with each context for search. What if we had an option (toggle) on the Search dialog for “CEFITS” that would limit search results to types that have a direct relationship with the current entity’s type? And/or a toggle that references a simple stored list of any types that were linked to from CEFITS in the past for that type (regardless of formal inter-type relationships, i.e. the option mentioned above) and filters to only those types? Provide an option (another toggle?) either on the Search dialog itself, or in user Preferences to “start with last search settings” or something. Or perhaps a toggle that is “Save as default search filter for this context” or something. Consider making it contextual per-“area”/search method, as above, so that Ctrl-K and CEFITS searches can have different saved filter starting points. Some of those may be good or bad ideas. Maybe all are bad. :smile: But in general I am just advocating for the idea of adding some more explicit control to the Search UIs, but trying to avoid option proliferation. In the fullest expression of the ideas above, you’d end up with I think only 3 extra toggles, which I think would bring a lot of additional benefit, at least for certain users/approaches. The main alternative I can think of would be something like a user preference area with either a series of toggles for every type (big UI, cumbersome), or maybe some kind of multi-select with Type search to select only those types users wanted to be enabled for search by default. I think my proposed option above could accomplish similar results for a majority of cases, even though it is less precise, while also being more nimble/fluid, exposing the options more to make them more discoverable, etc. Basically I am interested in what would be a “good enough” solution to the problem without being over-engineered.

[image]Create and link in one action Here’s a little tip that can be used to speed up creation and linking of entities. I just wanted to clarify so the original issue isn’t lost here, but I understand you were responding to a specific question. This particular request is in regard to how many clicks it takes to turn some text into an entity, not necessarily about the contextual linking. I think that should be covered by a separate request, like what @Matt_Blais linked above. This particular issue is more apparent the more databases there are in the workspace. Many times the type of entity you want to create gets lost in the sea of databases. So, one suggestion was to provide a quick link for the types that are already in the document, for example. Or, sorting the list differently. The idea is to provide the following improvement in the number of clicks it takes in most cases: [image] rothnic: So, we’d go from 1) Highlight, 2) Click Create Entity, 3) Choose type, 4) Click create to 1) Highlight, 2) (in many cases) Click Create Task (or whatever else is important).

Yes, indeed. I have separated out the posts that relate to ‘create-and-link’ into a new topic

[image] rothnic: This particular issue is more apparent the more databases there are in the workspace. Many times the type of entity you want to create gets lost in the sea of databases. This is a great point. I think for those that are comfortable keyboard shortcuts, current setup for creating entities is not too bad because after highlighting, pressing ctrl+e brings up the entity creation dropdown and you can search and narrow down the list, select the type (using arrow key) and create the new entity with ctrl+enter. This can be quite fast and would mean you don’t have to leave the keyboard. However, I think there might be a number of ways of improving this, especially when clicking: Allow admins/users to define a set of recommended/favourite entity types to link to (either at the type/database level or at the rich text-field level). This would make sure at least those show up at the top when you create or link to an entity. Your suggestion of using types already used is also a good way, but it seems you basically requires a lot of linking to be done before it provides a return. Using a type of algorithm that tracks and learns the types of entities that are linked to per database/type. This could be a good combination of 1 & 2 where you can seed the list at the beginning and then have it automatically adjust over time. In some weird and wonderful future, I image it might also be possible to infer/guess the type by the linguistic context, but I assume that would require us teaching the system what each database/type is. Seems like a wonderful thing but I assume not likely for a few good years. I actually like to use the “#” approach because you don’t have to highlight anything. However, you are unable to filter the database/type with your keyboard, and creating new entity seems impossible without using a mouse. If this workflow can also be improved, that would really make writing smoother.

Here’s a weirdness in the keyboard handling when using CTRL+E to create a new entity inline in a Rich Text: After you select the text and hit CTRL+E, the Type-selection popup appears and you start entering the name of the Type you want, and the options are filtered as you type. So far so good. At this point you can use the cursor up/down keys to move down and select one of the filtered Types in the list. HOWEVER, if you keep typing and filtering until there is only one remaining Type in the list, you can no longer select it with the cursor keys – you have to use the mouse now. :worried: It’s very misleading, because at this point you only see one Type remaining in the list (let’s assume it’s the Type you want), but if you hit CTRL+ENTER to create it now, that isn’'t what happens – instead Fibery creates an entity of the first type in the original list (which is no longer visible).

Another oddity - in a Rich Text, if you immediately “undo” after creating a new entity via Ctrl+E, the new entity is not deleted. This is confusing because it leaves unwanted entities.

Improve Speed of Creating Entities in Rich Text

Ideas & Features

Matt_Blais January 13, 2022, 9:55pm 8

Topic		Replies	Views
[DONE] Quick-Create an Entity Ideas & Features	15	544	October 31, 2024
April 16, 2026 / 🦍 Automatically link entities with more operators, Text color in rich text, Filter and sort relation selectors in Forms, Share with all users with a particular email domain Changelog	21	630	May 14, 2026
Create an new Entity "in-Entity" only using the Keyboard Ideas & Features	19	2632	August 12, 2023
Fast way to create task-entities Get Help	10	608	October 15, 2026
Too many clicks to create an inline entity mention Ideas & Features	6	155	April 10, 2024

Improve Speed of Creating Entities in Rich Text

Related topics