Manage todo's using properties?

Questions & Help
1

I’m trying to setup a better structured workflow to manage todo’s for work.
For this I have some ‘default fields’ I want to include in the todo’s besides the due date or some hash tags. Ie I want to add effort and impact and stakeholder information.

Intuitively I was looking at inputting tasks like this:

* [[sub-project]]
  * /TODO the task that needs to be done #subtopic
    * priority:: med
    * who:: John Doe
    * effort:: high
    * impact:: med
    * related_project::

I’d love to have a table listing all the todo’s on the [[sub-project]] page. Ideally a table per subtopic and showing the properties as columns

not sure if this is possible in the current setup, and looking for suggestions as to how set something up like this.

key thing is to have the input as easy as possible (from the journal page)

1 Like
2

Does Logseq querying has something like a LEFT JOIN ?

I could imagine using a task_id as a reference in line and then use the properties in a seperate block with the task_id?

something like

* [[sub-project]]
  * /TODO the task that needs to be done #subtopic #task_id123
    * task_id:: task_id123
    * priority:: med
    * who:: John Doe
    * effort:: high
    * impact:: med
    * related_project::

and then query this somehow and join on the task_id?

3

Welcome.

You are asking for many things at once. Most of them can be done, but maybe not everything. Should move one step at a time and see how it goes. Don’t expect to get it right on first effort. I would suggest that you provide some actual block examples and a basic query, then we can help you build on top of this.

As a first clue, properties go in the same block.

4

thanks. That’s actually what I’m trying to do here.
I’m trying many different things that almost do what I aim to achieve, but the desired input remains what I put in the opening post: TODO and then properties in a child block

I tried a ‘work around’ that is only slightly less intuitive to input but is visually not so appealing (empty first line with the checkbox and topic in the todo )

the block input then is

TODO task:: something todo #some_topic
topic:: some_topic
priority:: B
who:: john doe
effort:: high
impact:: high

and then just use the query:

{{query (and (task TODO) [[some_topic]])}}

The other thing I was trying and wondering about is how to combine 2 queries.

In the desired layout (see my opening post) the properties are in the child block of the TODO. I can pull the TODO and I can pull the child block. But not sure how I can do both at the same time so I can display both the actual TODO and the properties in 1 table.

5
  • Logseq’s current design assumes that properties are either:
    • in the same block with their object
    • in an ancestor block
  • Your approach asks for the inverse, i.e. properties in a child block.
    • One problem with that approach is that a parent may have multiple children, each one of them with its own properties.
    • Another issue is that normally the “something to do” text would need more blocks to properly outline the task.
      • It is rare for the properties to need more space than the rest of the description.
  • I don’t see how moving the properties one level down improves:
    • the easiness of input:
      • Sounds very subjective.
    • the visuals:
      • Sounds like this is a workaround instead of a direct solution.
        • For a direct solution, could explore:
          • custom.css
          • plugins
      • Are you trying to hide the properties or something?
        • But then you want them present in the results.
  • Combining/joining information from multiple blocks in a single result needs advanced queries with some clojure.
    • There is no need for explicit id, as the parent-child relationship is already kept in the database.
    • I would avoid going there that early, unless it was absolutely necessary.
  • Overall, you could expand some more on what you really need, before focusing on candidate solutions.
    • From your part this may be obvious, but not for the typical Logseq user.
6

thanks for your reply!
I agree that this is highly subjective!

what I’m looking for is a way to both input and visualize tasks that is as intuitive (for me, subjective) as possible. Otherwise I find myself missing tasks (I don’t write them down, just do them) if they are small or really have to sit down to input the ones that came in and I missed up to that point.

My current (and therefor most intuitive) way for any input is to use the bullets for hierarchy and level of detail. So Im someone who will use

  • topic
    • some other topic
      • some remarks
      • more remarks, perhaps about a someone [[john doe]]
      • etc.

Thats why I was looking at inputting my task in this way, going from a topic/project to some area/topic and then the task (call it a ‘title’) and only then the details.
But if I should/could use another way to manage this that would be good as well. Looking for ways to achieve what I’m looking for as well as opinions/experiences on how others manage this.

The end result needs to be (amongst others) a table view of tasks (titles, brief description) with the additional info like priority, effort, impact, etc.
This is meant to go over with others to align on what needs to be done and on priorities.

What I also was considering is just inputting the task (title) and make it a page for the additional info? That might make sense as well even though it might be slightly higher (mental) effort

7

You can postpone turning a hierarchy of blocks into a page, until the need becomes obvious.

  • But meanwhile, it is a good idea to treat the root block as if it was a page.
    • Among other benefits, that would make the transition very easy.

To easily utilize the automatic table of properties (thus avoiding custom code), should put the properties in the same block with the title of the task.

  • Arguably, this is where they belong anyway.

It is generally good practice to keep the structure of data as close to their desired visualization as possible.

  • Among other benefits, it helps the user’s memory find what they need.
    • And that is another reason for not moving the properties to a separate block.

There are many options to consider:

  • Bullets are hierarchical by their nature. However, using them for level of detail (i.e. outlining) is more fitting than using them for topic hierarchy. Alternatives are:
    • namespaces (easier, but limiting and not scaling well)
      • That would look like [[project/sub-project]]
    • properties (more difficult, but more enabling and scaling better)
      • That also has various options, like:
        • multiple properties to describe the topic in detail
        • multiple values to categorize the topic under more than one parent
      • The various topics could have internal relationships in their own pages, keeping the tasks themselves light.
      • Coming database version makes properties easier to work with.
  • Generally a reference from a child to a parent is more flexible than placing the child directly under the parent:
    • Position limits to a single parent.
      • In theory there is a correct single parent, but it is not immediately obvious which one.
        • Especially the journal is not the correct parent in most cases.
    • Changing position means moving, instead of simply editing.
      • The less moving, the better (especially for memory).
  • As a graph grows bigger, effective filtering becomes a challenge.
    • Tags and properties are easier to filter than hierarchies.
  • Some of the properties could be weak choices:
    • e.g. property who:: sounds wrong
      • could be owner:: or assignee etc.
    • may be better to become inline references directly inside the description
      • could be [[john doe]] to do this
8

Ok I see now where it seems I was making things too complicated.
I tried (again?) and it works perfectly if I simply do the input as:

* TODO some item todo #some_topic
   impact:: high
   effort:: med
   assignee:: [[john doe]]

as you said in one bullet. I think I just read somewhere that properties needed to be the first thing in the block (page?), but the input this way is exactly doing what I want.

apologies for the confusion and many thanks for the good pointers :slight_smile: