Grey out but do not strike through sub-items that are not explicitly marked as complete themselves but have a completed parent
Context and Use Case
I have a list of big projects, each with tasks. I mark less important projects as completed so I can toggle their visibility quickly. Sometimes, I zoom into a completed project. At that point in time, I want to see which tasks are completed or not.
By the way
I brought this up on Twitter a couple of months ago, but I didnât see it in the Trello roadmap yet, so I wanted to hear about the status (and am curious if other people run up against this as well!).
Thanks for an awesome product and such an awesome way to provide feedback!
I have a similar experience with turning items into todoâs (with checkboxes). So I guess it would be a matter of rewriting/altering the code that formats items like this to just make it based on an individual level, and then seeing which method is more popular; either having to highlight and bunch of items and then formatting it accordingly, or just compromise and then see if can be undone.
I donât know how the code works, but to clarify what I was thinking as a possible solution: create a style targeting completed items that (a) strikes through the item and (b) greys out the item (c) greys out any children of the item.
Also, just to be clear, the style should only care about onscreen things. If weâre zoomed into a particular item, the completion status of any ancestors shouldnât matter!
I was just saying that since it is a bit annoying to deal with (in other areas as well), a granular level of formatting items might serve as a fix for this in the meantime, just like how Workflowy handles items.
Edit: Things are currently âaffectedâ by being treated as lists:
Adding checkboxes
Marking things as complete
Deleting a top level point deletes the entire list (which I guess could stay).
Now that I think about it some more⌠would it be a little unexpected for some users?
For example, letâs say you have
A
B
C
D
and A is a checklist.
When someone checks A, he could expect B, C, D to all be checked automatically as a result. In other words, heâs using checking A as the shortcut to check, A, B, C, and D. Thoughts on this?
The proposed fix shouldnât be confusing as the uncompleted sub-items are greyed out.
I think they the current system is more confusing for users when they uncheck the parent item and suddenly certain sub-items become unchecked. Hidden information is no good.
Ah, I see. Letâs close that feature request in favor of the fix proposed here.
But the checkboxes are checked. Thatâs the confusing part.
In the example I provided above, after A has been checked off, B, C, and D will look greyed out but not checked. Thatâs the thing I was concerned about.
I knew what you meant; I just think greyed-outness is enough to make the uncheckedness not confusing. Something clearly happens that makes the sub-items look completed. But itâs easy to tell itâs because of the parent list. Best of both worlds.
I see what you mean. I now have an idea of how to implement it, and Iâll see how it works out when I try it. Sometimes you never know before you try it.
Maybe we need to grey the subitems of the checked list a little more, but we can probably figure something out.
I agree exactly with Yatharthâs request and suggested implementation.
I use Dynalist to make outlines of information for writing. When I use something from the outline in my paper, I check it off. Sometimes I use a piece of information that is a parent, but I donât use all of its children, so I donât want all of the children checked when the parent is checked.
Yatharthâs suggestion is pretty much the way Workflowyâs âCompleteâ function works.
Weâre fixing this one, and I think we have some misunderstandings to clear out about the other thing (i.e. this post). Would really appreciate it if you can reply over there to let me know your thoughts.
Well, letâs say Dynalist gets a recurring reminders feature, something like a grocery list or list of ingredients would be something you wouldnât want to re-enter.
Although I do agree that on some level things like tasks are bound to be deleted anyway, there are some exceptions, as mentioned above.