🪴 Scaling Synthesis

Search IconIcon to open search

Interfaces for adjusting a query

Last updated June 25, 2022

Authored By:: P- Rob Haisfield

tags: Q- What are powerful interfaces for entering information into a discourse graph

Not all edits to the query have to be within the query editor. In I- Provide Push and Pull as inline syntax to affect the related items section for a page, we outlined how push and pull work as an inline DSL to add to a related items query’s any clause.

C- User behavior within a well-designed choice architecture can be a signal of preferences. We can see how this happens with newsfeed management mechanisms. As people are looking through the results of a query, they might right click then select the option: “remove from query.” The menu path might look like the following, where each of the topics could be toggled:

1
2
3
4
{:remove {:itemID sladfkji4af4sdkf
          :author "John Doe"
          :topic-mentioned ["topic1"
                            "topic2"]}}

When people click on an “x” on the query result’s item, the smart default could be to remove that block’s UID from the query through (not (any: uid1 uid2)).

Imagine “economic inflation” were a topic mentioned in an item within your newsfeed query and you right clicked to remove that topic. This might translate into the following:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
(def muted-topics-list
  (any: "economic inflation"
        "veganism"))
(def muted-items-list
  (any: uid1
        uid2))
(def newsfeed
  (any: followed-people
        followed-interests)
  (not: (any: muted-authors-list
              muted-topics-list
              muted-items-list)))              

Alternatively, users might process the list of query results through highlighting and lowlighting. C- Highlighted and lowlighted search results map to how well results map to intentions, so the default assumption could be that lowlighting a block would remove that block from the query results. A block id would then have a queries-where-highlighted and queries-where-lowlighted property, listing the relevant queries.

It’s possible that users don’t always want to reify an entirely new query as an entity, and sometimes would like to simply filter a query. Given the compositional nature of the language I’m proposing, it should come as no surprise that we can apply a filter function to any list of query results.

1
2
3
4
5
(query:
 newsfeed
 (any: "behavioral economics"
       "web3")
 (not: "regulation"))

Roam has a GUI for manipulating these filters that can go beyond the language interface described above. For example, below, I’m filtering all linked references to [Rob Haisfield](Rob%20Haisfield) for [CLM](CLM) (claims) and [EVD](EVD) (evidence) that are connected.

If written in my proposed query syntax, this would look like the query below. An all: operator is assumed at the beginning of the query.

1
2
3
(query: "Rob Haisfield"
       "CLM"
       "EVD")