I wanted to share an exciting update with you all. Your feedback and discussions on customizable workflow state markers have been incredibly insightful, and I’m thrilled to announce that I’m now in the early stages of designing this feature!
As we continue to build the database version of Logseq, we believe it’s the perfect opportunity to start work on this much-requested feature. Our aim is to create a more versatile and personalizable task management experience for all of you.
The feature will allow users to create, rename, and manage their task states, and also customize their appearance. It’s still in the design phase, but our goal is to provide a seamless, intuitive way to manage and customize your workflows directly in Logseq’s settings.
Your ideas, use cases, and opinions are invaluable in shaping this development, and I want to keep this conversation going. As I progress with the designs, I will be sharing updates and requesting your feedback to ensure we’re creating a feature that genuinely enhances your Logseq experience. This will probably most likely happen in the Discord #design channel as it’s my preferred medium for quick input.
Thank you for your continued support, patience, and most importantly, your input. Stay tuned for more updates on this feature soon!
Please allow the Checkbox to also appear at the end of the TODO. Many forms and journals have checkboxes as a last column and many brains work like that when checking on paper.
I 100% agree. I already do something similar because I have items that are “todo right now” (like a checklist) and items that are “todo far in future when a certain thing happens”, and I already organize those through…guess what! Tags
Tags are super powerful, can replace basically anything.
great you are working on this, just a suggestion: maybe take in account an option to have localized TODO keywords, I mean the workflow may be fine but user just wants those special words to be in the same language as the rest of the app… this ideally would extend for other words like SCHEDULED or NOW etc. -as they don’t look too good when mixed I think-
edit: for instance in spanish it could be something like: PENDIENTE ENCURSO COMPLETADO… words are way longer though
I love this concept its great! all I would like to add is keyboard shortcuts are key as long as u can use the ctr+enter to cycle them and have the ability to set a default. Then if u have it so when your cycling u can type a slash and be sent one namespace level deeper. E.g. to give a task “development/bug/open” u can do ctr+enter type the start of “production” then select from keyboard then u can use ctr+enter to cycle between “development/bug”, “development/design” etc etc then type another slash and cycle todo, doing etc etc
Just a possible idea but would mean you can add any tag to any item in any tag namespace ALL without having to remove you hands from the keyboard. Defiantly after a while the common ones you use would become complete muscle memory.
@futurized what are the advantages of using properties for tasks workflow instead of tags as explained here?
Notice that hashtags can be inline, so we could have compact one-line tasks. Properties instead force bigger blocks. Personally I like my tasks to have only one line.
I would love properties to be able to be placed anywhere inside the block (just like tags) and Logseq logic to be able to differentiate and use them as properties in an auto-hiding properties section. So, for example, I would have this task: - Buy the milk status::Task/TODO:: (- Buy the milk ::Task/TODO:: would mean the same thing and the status property name would be auto-infered due to the workflow definition somewhere in config.edn or in the namespace). The result would be - [ ] Buy the milk. One would not need to place the TODO text right after the bullet but Logseq would still place the Checkbox at the beginning of the block while having the status:: property in the properties section as well.
In the case of status: property one would not see the TODO because it will be transformed in a Checkbox by Logseq UI, but for other properties this would open up so many possibilities. For example: - In this book, author:: Dale Carnegie:: speaks about... would be rendered as - In this book, Dale Carnegie speaks about.... I am not suggesting the tehnical way to differentiate the property from its value and the surrounding text but the above would leave visible on-screen the value, while “pulling” into the properties section the author:: Dale Carnegie property:: value string.
Some of these are maybe feature-request material but I wanted to express here as well my need to have properties inline as tags can currently be placed.
PS: While writing the body of the block, one would refer to the saved properties as variable to be able to reuse them throughout without re-typing them again: - Another interestng point I find author:: making is that .. → - Another interestng point I find Dale Carnegie making is that ..
Cool suggestion. But I would add the property as dynamic variable to the mix and also block editor suggestions based on block text or properties values.
Wondering if there has been any progress on this recently?
I have been doing something similar to @alex0 suggestion, but of course its all manual (rather than clicking to change state, I have retype the tag.)
One further suggestion is that this be added to a workflow template as a property. By example, if a template is “Prepare Taxes” it might have a workflow:: property of “0:TODO, 1:DOING, 2:DONE” wheres a template for “Paying Bills” might have a workflow:: property of “0:DUE, 2:PAID”
In the DB version: yes, but tasks are implemented with the new “properties templates” i.e. you add the hashtag #task and then appear properties where you set to-do, done, priority, schedule ecc and you can create your custom workflows.
Neat, thanks for the info. I didn’t know they were tacking other stuff while working on the DB implementation. Is there a summary somewhere of done and planned work, as an alternative to reading through 2k+ commits?
