Improve Speed of Creating Entities in Rich Text

[rothnic]

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:

It could be something like:

[Matt_Blais]

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.

[cannibalflea]

@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)

[Chr1sG]

@cannibalflea

I haven’t tried using automations to address this (might be possible with a nifty script)

You can use this automation:

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.

[Oshyan]

@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:

Filter search results based on Field Values

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 )
  • 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. 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.

[Matt_Blais]

Related: Make "creation context" available to scripts

[rothnic]

@Chr1sG

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:

@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).

[Chr1sG]

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

[cannibalflea]

@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:

1. 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.
2. 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.
3. 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.
4. 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.

[Matt_Blais]

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.

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).

[Matt_Blais]

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.

[cannibalflea]

@Matt_Blais

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.

Can confirm this and can see that it can be quite annoying.

@cannibalflea

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.

I actually use the ‘#’ approach quite a lot and have been wondering if it is possible to use a key combination or another character/series of characters to allow you to select or type out the entity type. This would make the process fully keyboard based and in my opinion much quicker.

[Oshyan]

I’ve just moved a vote here. This issue is increasingly problematic for me as I build out a fairly complex Fibery database model. I’ll probably end up with 30-40 DBs at the least, and that is just unmanageable when I am trying to link in Rich Text.

I think my and Rothnic’s thoughts above outline some reasonable solutions, but I’ve also warmed toward the idea of having per-Workspace or maybe even per-Database default settings. I’ll also point out that “insight generation”, one of the biggest long-term goals of Fibery, is probably going to be best enabled by flexible Linking/Relations, not by linking within DBs with static Relations. Obviously you can setup e.g. a Relation between Feedback Item and Insight, and use the Relation Selector to pick a related Insight. But this misses out on the amazing Highlight Linked Text feature and provides poor context. So this feature request has some conceptual relationship to this current roadmap item, but I would argue it is at least as important for the long-term goals:

Filter and sort in relation Field selector

Some similar solutions might work here for Rich Text Linking, and not require the addition of an additional place to set these defaults. However I think there is on key missing element, probably due to the focus of that feature on relation selection, rather than linking in Rich Text, and that is: you need an ability not just to filter but to manually sort the possible Databases to link to.

This could be implemented with a simple manual ordering option with widely-used Fibery drag handles (e.g. for Field ordering). And if that were the case it could still be a Creator option set in the Link Search dialog itself I guess? (there would need to be a way to invoke the setting of the default vs. the adjustment of a Link Search for one-off use) An alternative, giving more space for good UI, etc. would be to have a Database Settings area where you could re-use the Filter and Sort UI/components to define the Default Databases to show for linking from each Database (alternatively this could be defined on a global Workspace level, which would still be a big step forward at least for my purposes). In addition to the Filter + Sort you’d need manual ordering, as I mentioned.

I think you’d also want a simple toggle for “Show recent at the top” or similar, which would have a short section of maybe the 4 most recently linked DBs from that DB. And there are probably one or two other options I’m forgetting about.

In the future it’d also be great to have a Sort option for DB linking that is “activity”-based, as others have suggested above, and again this should be optional, e.g. “Use Activity-based Sort/ranking” would show the DBs most frequently linked to at the top. This is different than recent sort, e.g. you linked to DB X from Rich Text today, but it’s the first time you’ve ever done so, and DB Y has been linked to 50 times in the past. DB X should probably not be above DB Y in the link list!

I hope we can see some progress here soon.