Logseq’s current task management is best in class for the new generation of networked knowledge managers, but one thing I think would make it better is the ability to apply some of these task management features at the page level (rather than just to blocks). My idea is to be able to mark pages with TODO/DOING/NOW/LATER markers just like task blocks. Together with my other request to have a Page Specific NOW section, I think this would enhance the way task management works for complex projects.
Hello and thank you for this request.
I am specifically interested in topics around task management, because that is also my main usecase with Logseq.
May I briefly explain how I currently handle it:
-
For each major task I create a separate tag in the form
#task.ProjectName.Topic.date
. -
Since each tag also has its own page, there is also a page for each major task.
-
On this page I have the following structure as content:
-
[#C] #BACKLOG.task description (what is the task about)
- Info / Links
- some infos and links regarding this task
- ToDos
- TODO Name → do something
- TODO Name → so something else
- Protocol
- ┤date├ detailed infos about what was going on over time
- Info / Links
What do I do, when this task has been completed? → I rename the page (the tag) and replace the word “task” with “done”.
#task.ProjectName.Topic.date
becomes #done.ProjectName.Topic.date
This renaming has the effect that when searching for tasks (“open tasks”), these entries no longer appear and wherever there was previously #task.xyz, there is now the tag done.xyz - a clear indication that this task has been completed.
So I mimic something like you requested - I coded the state of the task/page into the page title. Starting pages with “task” or “done” is something like your request to mark whole pages as TODOs.
I’m not sure I’d prefer that. Because then there is a mixture between todos as individual steps to a task/project and the status of the task/project itself. A query for open todos would then perhaps return both open projects and open individual tasks.
But perhaps this problem could be solved simply by defining a separate workflow (separate status definition) for the status of the pages. Something like what is generally suggested here:
I find the suggestion really interesting (even though I currently have a different solution) and am curious to see if there will be any progress on this.
Perhaps one more comment on
As you can see from the structure above, I have specifically grouped all todos in one section. For the task management of projects I have deliberately decided not to distribute the totos of projects arbitrarily.
I handle this quite differently than in the journal, where information that accumulates throughout the day is mixed with small todos and where the journal queries are very important for me.
I hope this has helped to get the discussion going.
This is doable today using page properties.
I am currently working on something like that:
With the properties you can say that a page is a project, and that it is active or not (or now, later).
I use a template to add the properties:
template:: project
category:: projects
status:: #Completed [[🗄 Archives]] [[Active]] [[Someday/Maybe]] [[Later]]
area::
goal::
related-to::
tags::
time-investment::
reward::
impact::
Yes, it is doable, but Logseq already has built-in task management features for blocks, so why not extend these to pages as well? It will allow for tighter integration between the two, and I don’t see any down sides?
I agree with you on that. Projects should be first class citizen
That looks very interesting and just what I have been looking for.
As I am quite new to Logseq and has not gotten to grips with its query system, use of page properties and page tags yet, could you please post an example page of how the properties and tags have been implemented?
Also, are all the properties in your table fetched from the pages directly, even the status (as it seems you actually define the options directly in the template, which I assume would not be needed if fetched from each page)?
Thanks.
You can see my workflow here:
I’m surprised that pages aren’t themselves ‘taskable’. Why can’t I add a property to a page like TODO
or DONE
or NEXT
?
Yes, I think this is the best way to do it. There should be a “task” property which can have the values “TODO” “DONE” “DOING” etc.
Then these would show up just as normal queries for tasks, with all the other DOING or LATER tasks - perhaps with a special icon or indicator that it is a page, such as [p] (like in search).
@janbaykara’s comment got me wondering if I’m not overthinking how to do projects in logseq?
I took some time to write up my new approach to project management, one that I find simpler and more intuitive than what I was doing before. Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
@Luhmann Smart approach.
Do those queries for tasks render TODO(s) written out of the Project page itself?
It can be anywhere as long as they are tagged with the project.
That’s what I didn’t get from the post and template you shared. It probably didn’'t work on my implementation since my tag for project is a inherited one like #PARA/project . Could that be?
TODO This is a task for the #PARA/Project [[Project X]] ?
What it didn’t work neither is the Dynamic Variable <% current page %> .
I have to admit that I love this idea of considering Project another “big” TODO and deploy a system around that.
I am not great at the advanced query syntax. I got a lot of help in the forums to get my system to work, but I don’t really know how to modify it for your use case. Maybe someone else here can figure it out?
You are right. I would learn a bit more about advanced query syntax before jumping into implememt them into my process.
Regardless query syntaxis, what I keep missing is if tagging Tasks or just adding the Project page [[mention]] for your system to perform.
I will often add something like this to my journal page:
- [[project name]]
- TODO remember to do x
This works fine for me, but I think you can do it a number of other ways as well.
I would definitely need to see a short video or gif of your setup. I don’t see yet why there is a need to tagging the Project TODO as #project, unless there is some requirement from a query point of view.
Thanks for the examples, so far.
That is just so I can query a list of all unfinished projects.
I cannot achieve what you describe. This is my test, using the advanced query set you shared. The only change I made is replacing your #project by my #PARA/project.
#+BEGIN_QUERY
{:title [:h3 "Related Tasks"]
:query [:find (pull ?b [*])
:in $ ?query-page
:where
[?p :block/name ?query-page]
[?b :block/marker ?marker]
[?b :block/refs ?p]
[?ref :block/name "PARA/project"]
(not [?b :block/refs ?ref])
[(contains? #{"TODO" "DOING" "NOW" "LATER" "WAITING"} ?marker)]]
:inputs [:query-page]
:result-transform (fn [result]
(sort-by (fn [b]
(get b :block/priority "Z")) result))
:breadcrumb-show? false
:group-by-page? false
:collapsed? false
}
#+END_QUERY
#+BEGIN_QUERY
{:title [:h3 "Checklist"]
:query [:find (pull ?b [*])
:in $ ?tag
:where
[?b :block/marker ?marker]
[(contains? #{"TODO"} ?marker)]
(page-ref ?b ?tag)
[?ref :block/name "PARA/project"]
(not [?b :block/refs ?ref])]
:inputs [:query-page]
:result-transform (fn [result]
(sort-by (fn [b]
(get b :block/priority "Z")) result))
:breadcrumb-show? true
:table-view? false
}
#+END_QUERY
#+BEGIN_QUERY
{:title [:h3 "Completed Related Tasks"]
:query [:find (pull ?b [*])
:in $ ?query-page
:where
[?p :block/name ?query-page]
[?b :block/marker "DONE"]
[?b :block/refs ?p]
[?ref :block/name "PARA/project"]
(not [?b :block/refs ?ref])
]
:inputs [:query-page]
:result-transform (fn [result]
(sort-by (fn [b]
(get b :block/priority "Z")) result))
:breadcrumb-show? false
:group-by-page? false
:collapsed? false
}
#+END_QUERY
What I found as potential issue is the hastag inheritance #Tag/subtag within the advanced query. Changing for a simple tag seems to work.
Could someone confirm if tag inheritance is compatible with Advanced queries?
I found the issue:
I was using the PARA/project in UPPERCASE and the Advanced Query is Case Sensitive, thus para/project.