On Discord tienson wrote:
Thank you all for the feedback on the query builder, it’s something we’re going to design && implement soon.
So if you have any suggestions on the implementation, please create a post on Logseq Forum to keep it organized
The macOS finder has a good UX alread, and numerous other apps have copied and adapted it. For instance, see 2Do, Hazel, NameMangler, and HoudahSpot.
2 Likes
I’m thinking about an interface with a drop-down menu where you can select the type of item you want to query, the attribute(s), the operators of your choice and “+” buttons to add more items/attributes. So it would be like
- The dropdown menu: (Page|Block|Property|Task)
- A field for attributes (Page/Tag/Block/Property Name) or a drop-down menu: (todo|doing|done|now|later,…) if you chose “task” as the attribute
- A drop-down menu to choose an operator: (and/not/or/…)
- And then the same pattern as above goes on: fields and drop-down menus to choose: type, attribute, operator.
- Then a “+” sign to add more type menus, attribute fields and operator menus.
I hope this explanation is understandable. It’s hard to describe an interface and it’s functioning.
2 Likes
To me the ability to display journal date for blocks defined in the journal is essential. It would be great if it could be one of the columns and the table could be easily sorted by it.
Hi all,
this is a mockup inspired by indented lists:
- the relation between lines is considered “AND”
- the first dropdown menu lists options like “Property, Reference, Parent page, OR and NOT”
- the next dropdown menus display different options, for example if the filter is “Property” the second menu lists property keys and the third menu lists values
- special options like “See below” or “OR” are meant to be used with indented lines
- the special option “Range” introduces two more dropdown menus
What do you think of this “framework”? Is there any use case that you think is not covered?
Edit: here there are some additional UI niceties:
- assuming the bullet point reminds the multiplication sign
•or*and normally the lines are in aANDrelation - the bullets points of children blocks when selecting
ORfrom the first dropdown menu could be rendered as a+sign, like in Boolean Algebra - the bullet point of a block with
NOTselected from first dropdown menu could be rendered as the sign-(minus)
5 Likes
The following is not strictly about the query builder but on making it easy to discover:
- In various places of Logseq UI, like (Un)Linked References sections, it could be possible to apply filters with the same query builder UI
- Those places would act as “entry points” to discover queries
- The first filter would be fixed and not editable, for example “Linked References” could be filtered with query builder UI but the first filter “References from
<current page>” could greyed out - the equivalent query syntax (
{{query ...}}) could be displayed (but greyed out) while using the builder and a “Copy” button could let the user copy in and later paste it elsewhere, eventually re-editing it with query builder or the usual syntax
Edit, here there is a mockup:
4 Likes
I think in the same way there could be many types of filters, like has a tag, has a parent with a tag, links to pages, pages link here, is a ref, on a whiteboard, different types of whiteboard shapes.
The tree structure allows some filters to have more sub filters.
Like this, it seems almost possible to prototype this in normal Logseq with a plugin. 
1 Like
In case we want options on how to display results (list, table etc), sort them and group them, I tried to expand my concept:
The results of the example above would look like this:
2 Likes
I don’t know if it would be part of the builder but I would really appreciate auto-suggestion / auto-completes when trying to build a query. Similar to how you get suggestions when typing a / or >, except within the query and with relevance to the things that can be entered in a query.
{{query (|)}}
(Where the cursor is at the |) Would display the things like and or property page-tags page-property sort-by… Etc. I know it’s not an exhaustive list but it would be fantastic if it could do that
I like that your UX mock-up includes sorting options as well. That is important.
I like the concept in general. I specially like that you use the logseq outline functionality to nest things.
A few questions:
Filter by section
- in your example you look for blocks and use a property, is that coincidence or can you also use page-properties and vice-versa? I ask as I currently can not show the page-name when using block properies in the query. This is not convenient. And as every block is on a page that should be possible.
- I would change the “see below” in the second bullet to “sub-query”. To make it more evident what is meant. I had to look twice to understand what you meant.
- If I understand correctly in the sub-query mentioned in the previous bullet you would get as a result all authors with a birthday between 1700 and 1800 (independ of the nationality) and all authors with nationlity of Italy or russia (independ of year of birth). I think you don’t mean to but that is what the OR means to me. If you only mean to get authors from Italy or Russia with a birthdate between 1700 and 1800 you should use AND.
- When you start mixing OR and AND then the use of () to group conditions togehter is much advised.
Sort by section
- In the sort results by section I do not understand the need for the first row. Just property birthday as the first sort and add further nested sorts as second and third sorting values.
- Also remove the display result as list should be removed from the sort by section and get an section of it own “Display as” section (or include it in the main “Filter by” section.
Group by section
- For the “Group results by” section I do not understand the need for the first row. It adds nothing in my point of view.
- When you group on a property the sorting is included (how can you group otherwise). So i do not understand the “sort these groups on” option. What else then value would you sort a group on?
- Display could be handy depending on the new “Display as” section. For example when display as is set to table then there could be an option to show group as column or as header. But that is rather advanced I think.
- I do not understand what you mean when you say that “results can be group multiple ways”? I guess you mean nested groups which should be add as nested grouping like sorting. But you can’t have multiple root lines as you call them being a first grouping. Or I do not understand what you mean.
Interesting topic this … I thank you for your effort to make the nice-looking UX concepts. At the same time I think it is very important to have a good thorough discussion about the UX as the mean complaint currently with Queries is that it is to complex. So ease of use should be top priority. Even meaning that some functions are not included. Use of AND or OR should be logically derrived from the UX. Same as the grouping and sorting.
Looking forward to more discussion … 
Hi, thank you for the detailed feedback.
As far as I understand, Logseq has a complex data structure under the hood and Advanced (Datalog) Queries can do all sort of things with that. Instead Simple Queries try to abstract some concept on top of them, for example {{query [[tag]]}} is more complicated under the hood than it seems.
This Query Builder is supposed to support way more use cases than Simple Queries but without exposing Logseq inner data structure to the user like Advanced Queries. In conclusion I think it could have all sort of abstractions where it makes sense and there is no need to discuss them now and indeed I didn’t cover that aspect at all, I just proposed some ideas on how to input the data. The discussion on which filter to include is another topic compared to my concept. So feel free to discuss it independently from my concept.
I agree that “see below” is not great and I used it just as a placeholder, but “sub-query” is not an improvement to me and it’s technically not correct.
No, it’s supposed to be AND. Between lines there is an AND relation. Instead the OR is added with a special filter in a parent block and has effect on its children. It’s the first thing I wrote in my first post.
The indentation is supposed to let us avoid parentheses.
There are no multiple sorting options and it refers to results. This means that if you want to sort results by something that is linked to them, in my example authors’ birthdays, you need that “see below” filter. Otherwise specifying “Property Birthday” alone without the first line would be “sorting by books birthdays” instead of “sorting books by their authors’ birthdays”.
This may make sense, I placed it there to mirror the structure of the Group by section below.
What I said about sorting applies here too.
Everything else, for example you can decide to group results by author but instead of sorting authors by name you may want to sort them by birthday:
- Bob
- ...
- ...
- Alice
- ...
(suppose Bob comes before Alice when sort by birthday)
Not sure what you mean but I think I covered this use case: a first grouping option could be a list and a second one a table. This way you would get multiple tables in an indented list. About which columns should be displayed in table view, in case we want to specify that in the query builder (now it is specified in the properties of the block where the query is) I think the “table view” option could trigger more UI elements like other filters do and let the user set columns.
Have you seen the last image with Nation Author Book in red/green/yellow? Those are the results (books) and multiple grouping (by nationality first, by author then).
Any update on the progress for this?
3 Likes
As the link that alex has shown, Tienson is working on the builder and the discussion in this thread is considered 
4 Likes
This is very exciting. I think it will really unlock the power of Logseq for many more users.
