Improve Speed of Creating Entities in Rich Text

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:

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.

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)

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.

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:

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

1 Like