Create a query from CMD+K with a quick-edit overlay

[keen orchid]

Sometimes search returns no good hits, but what I really want is a small, focused query I can tweak quickly and reuse later.

So it would be great if Logseq let me create a query straight from CMD+K, then opened it in the same preview overlay we already use for creating new tags from the search panel. There I could define the clauses of the query, see live results, and quickly save it as a node, without losing my previous context.

This would encourage the creation of “fleeting queries” that I can reuse later if needed or never come back to. And it matches the existing quick-edit experience for creating tags, but also the recent Quick Add overlay (⌘ + E). For consistency, the same overlay should apply to creating new objects (proposal here) and creating new properties ([proposal here](#1437785565272739911 message)).

I made a mockup video of my idea and I'm curious what other think of this concept, and how the property-style query builder feels to you. I've been sitting on this idea for a while now – I explored a similar concept in early 2024 [here](#design message). Nice to have: a simple UI option to add the new query inline on the current page.

[quartz oar]

Sounds like a nice thing to have. I don't think I will use it very often though.

One thing I noted is that cluttering the menu with alternative options ("create page", "create query") would bother me. And there is an alternative way. Every query has the tag "Query". For consistency, it can be used here also. Typing in cmd+k "something #Query" could create an overlay without adding a new option to the menu.

[keen orchid]

Oh yeah, good point on typing #Query, I like that a lot to keep the menu clean and still give power users a fast path.
In general I share the concern about clutter that keeps me away from quickly getting to actual search results. But i'm also thinking about novice users that haven't discovered all these handy shortcuts yet. Maybe a middle ground:

• Keep Create as a collapsed group at the top (with the same list item group header as Nodes / Commands have). By default it shows just one primary action.
• Let me press ⌘↓ to show more create options (page, query, class, property), and ⌘↑ to collapse again.
• Add a tiny footer hint: “Type #Query to create a query” so newbies discover the shortcut without more rows.

That way we get:

• clean menu by default,
• a visible affordance for people who don’t know the shortcut yet,
• and a quick keyboard way to expand to all "Create" options when needed (for example in the future i might want to "Create whiteboard" instead of "Create page")

[keen orchid]

Also I'm curious, what are your thoughts on the property style query editor idea?

[quartz oar]

Yeah, that is the real issue too. I am not sure if there are "iconic" UI examples for solving this conflict.

The first thing that comes to mind is Raycast, where all menu items are listed in Settings and can be disabled there. By default, some of them are on and some are off, but a new user has a chance to discover them sooner or later, while trying to find an optimal setup.

It is just one of the options; your idea could work too.

[quartz oar]

Talking of the builder, it would be better to listen to you about the goals and solutions you are looking for.

My general, and a bit out of touch takes are:

1. Democratizing technology with visual forms is a nice idea. The question is the balance of simplicity and richness of the form. For example, as I see, with this builder it is impossible to create a query like "all tasks that are not 'Done'".

The logical "not" in a builder is often realized by an additional component (besides "variable" and "value"). Here are the examples of the Notion and Obsidian forms

While these forms are common for users, they are a bit "wordy" comparing to your proposal. But it is possible to have almost the same power without adding a lot of choices.

2. Another limitation of the mockup form is the lack of "empty" values. I think it is a common use case where you want to find some missing data: tasks without deadlines, movies that you neither watched nor are going to watch, etc.

3. Finally, I would also consider the form as a transition to advanced queries. Without demanding an understanding of the Datalog language, the form could translate some key ideas of that language. That would add some value of educating the user and getting them ready for a more powerful instrument.

A similar ideas can be found in some other proposals on the forum, where people tried to find a right visual representation of Datascript logic:
https://discuss.logseq.com/t/query-builder-ux-concepts/12656

[keen orchid]

I love Raycast! ❤️

[keen orchid]

It's not super clear in the flow i shared above, but "Not" is an operator you can select when you "Add clause"… clicking it would add another bracket… I am currently working on a code-based interactive prototype to work through edge cases and problems. will share here with you, when it's presentable 🙂

[keen orchid]

yeah i think a code toggle could be really nice for switching from visual query builder to raw code. atm the only we thing we get is clicking next to the filter pills and it turns into the simple query code.

[quartz oar]

That makes sense, right. And it's a nice way to simplify the form visually.

[keen orchid]

Yeah my dream is that the query builder feels like the Logseq outliner, in that it uses the same visual primitives of indented block rows and properties

and ofc ideally it can be operated fully keyboard-driven

[quartz oar]

I can picture a node with three properties as a way to represent a Datomic fact. Since properties are technically children of a node, they kind of mirror your idea of translating outliner experiences.

Plus, this structure gives the similar feeling that the user will get with the same query as the code, even though there are some simplifications compared to more advanced query syntax.

[quartz oar]

This idea is so productive, leading me to create numerous templates with queries. One of the templates is just an empty query:

New query #template
{:query [:find (pull ?b [*])
         :where
         
]}

With different mechanics, such as using templates instead of cmd+k, it essentially achieves the same goal. On any page, I invoke a template to either reuse a query or create a new one. And I can quickly make a query reusable by adding the "template" tag.

[balmy meadow]

Did you create any templates with a query that uses dynamic variables?

[balmy meadow]

The concept is excellent for UI centric users.
But I wonder if, and when there is a refresh of the simple query, we could get in addition:

• query and filter combined
• In search, we could have a composable search, similar to how GitHub and others are doing.
  Idea: #car and &owner:User1 or &drive:User2
  What car is owned by User1 and driven by User2?

This will open the path to natural querying and filtering, maybe using AI.

[quartz oar]

I used a query with ":current-page" in template for journal pages, but recently discovered that it’s unnecessary in my case.

And why are you asking?

[balmy meadow]

":current-page" is one of those that I am referring to. If you need that functionality but aren't using it, what are you doing to make the query reusable without modification every time the template is applied?

[quartz oar]

I’m not sure if I understood the question correctly. Please let me know if that’s the case.

The situations where I reuse queries don’t necessarily require dynamic data. Perhaps only special filters, but that’s it. Usually, the goal is to have all the necessary data on a single page.

For instance, in the chess example, I can read a chess book while taking notes. However, I also want to view my previous notes on similar games (in the same opening, for example). So, I add the same chess query to the current page with my notes.

I think such queries are similar to embedded nodes