Distinguish checklist vs non-checklist child of checklist parent

🌟Features
#1

Example of Current Behaviour

Step 1

Start with this:

  • Foo
    • [ ] Bar
    • Baz

Step 2

Make Foo a checklist

  • [ ] Foo
    • [ ] Bar
    • [ ] Baz

Step 3

Unmake Foo a checklist

  • Foo
    • [ ] Bar
    • Baz

Problems with Current Behaviour

Hidden Information

Given the list in after Step 2, you could not have predicted what happened in Step 3. This is because there was ‘hidden information’ about whether Bar and Baz were explicitly marked as checklists or not. I think hidden information is bad.

This Trello card

There’s no way to force Baz to look not like a checklist while having Foo look like a checklist.

The Solution

Not have making an item a checklist automatically make its children checklists too, as inspired by Inspired by the topic Distinguish completed vs uncompleted sub-item of completed parent

Toggle checklist at any level at will
#2

I’ll just mention my post from here, to add to this topic.

1 Like
#3

I didn’t follow this part: you can tell from if the children have a checkbox in front of it, no?

#4

I edited the lede; take a look at it now.

#5

Ah, that’s definitely much more clear what you meant.

One thing about outliner is its structure and inheritance… if B is a child of A, it should inherit many properties if not otherwise specified, e.g. is checklist, is completed. It’s sometimes hard to say which properties should get inherited and which should not. :confused:

#6

In any case, hidden information is no good. So the alternative solution is to erase any prior information about whether children were checklists or not. In other words, in Step 3, Foo, Bar and Baz all would be non-checklists.

I think the originally proposed solution is better than this alternative solution. Under the original solution, to get the alternate solution behaviour, I can just select the item as a whole, thereby selecting descendants as well, and then make all of them checklists. However, under the alternative solution, to get the original solution behaviour, I… can’t do anything. I would have to remember what the descendants looked like before and manually recreate all of that.

I think it’s better to make the user be a little more explicit than to erase their information.

#7

One particular case is the creation of new items. I think they should inherit both completed-ness and checklist-ness of the item the cursor was in previously (i.e., the previous item).

#8

That’s an interesting idea. Why should they inherit from the previous item rather than the parent item?

#9

Because that’s where your cursor just was and thus provides the most relevant contextual information.

My parent lists sometimes have checklist and non-checklist items, so information from the parent item isn’t necessarily as relevant.

Does that make sense?

#10

Yes that makes sense.

I guess it depends on how strict the hierarchy structure is in your mind. For example, if we have a list like this:

  • Animals
    • Mammals
      • Dogs
      • Cats

I would think cats would inherit things from “mammals” and then “animals”, but not from “dogs”. That’s what I mean.

Of course, if you treat bullet items like lines in a text file, what you said makes perfect sense. If the line I’m on is bold, and I press Enter, the next line should be bold too, because of “contextual information”. I 100% agree with that. It’s really about how to balance these two models. :confused:

#11

Really? I think even with the hierarchy structure people would have lists like this:

  • Biology
    • To Do
      • [ ] Read textbook
      • [ ] Solve problems
      • X
    • Notes
      • Charles Darwin wrote The Origin of Species.
      • Gregor Mendal wrote Experiments on Plant Hybridization.

In this case, when you insert an item at X, it should be a checklist. Thus, it shouldn’t inherit properties from the parent but rather from the previous item.

2 Likes
Distinguish completed vs uncompleted sub-item of completed parent
Distinguish completed vs uncompleted sub-item of completed parent
#12

I see.

I think our expectations are based on different assumptions.

My assumption is that “Make checklist” makes all its children have checkboxes, just like “make numbered list”. A confusing thing is that the numbered list itself does not have numbered in front it, but a checklist does have a checkbox in front of it. This is inconsistency on our part.

For the behavior you’re describing (the next item should inherit properties from the previous item rather than the parent item), you’re thinking of the option as “Starting a checklist from here”.

Is my understanding correct?

1 Like
#13

Ah, yes; excellent point.

See below.

Here’s what makes most sense to me

Numbered lists should stay the way they are

To be more specific…

… a ‘numberlist’ property on an item makes its direct descendants (not all descendants) numbered.

The alternative solution is confusing

The alternative solution is for the ‘numberlist’ property to make just the item itself numbered. But what happens in situations like this?

1. Foo — numberlist
*  Bar — not a numberlist
X. Baz — numberlist

Should X be 1 or 2 or 3? There’s no clear answer.

Checklists should behave like completion

To be more specific…

The ‘checklist’ property of an item makes it have a checkbox—as simple as that. Descendants are not affected.

For why, see the lede and this post.

What’s the alternative solution?

The most sensible alternative solution is to make the ‘checklist’ property make its direct descendants checkable.

Only “direct descendants” and not “all descendants” because of this Trello card.

Only “direct descendants” and not “direct descendants plus the item” itself because of this point that @Erica makes:

The alternative solution is less flexible

i.e. it supports a strict subset of working styles with marginal increased convenience for any working style. See this post.

Conclusion

Ultimately, I think both solutions make sense; one just makes more sense to me than the other.

The solution I favor would indeed make the checklist functionality different from the numbered list functionality, but I think it’s worth it and not confusing if the wording is changed:

Instead of “Make/unmake Checklist,” the option could read “Show/hide checkbox” or “Make/unmake checkable.”

(To make the transition without affecting the way existing lists look, I guess all the descendants of lists with the ‘checklist’ option currently should get assigned the ‘checklist’ property as well, and then switch for the UI change can be flipped.)

#14

Update: this is added in the latest web version, coming to all platforms soon.

1 Like
#16

Hi! I’m brand new to Dynalist and I’m trying to make a checklist with non-checkbox subitems. If I understand you correctly, this should be implemented in the web version since March of last year, but I can’t find that option anywhere. Where should I look? Thanks!

#17

Hi @Alison_Castle,

Sorry for the misunderstanding, what you described is not the topic of this post. It’s a long post, but you should understand the difference if you read it through.

What you described is an existing feature request: https://trello.com/c/yoj6qb8o/75-force-item-to-not-have-checkbox (you can vote for it in this link). Sorry it’s not available in Dynalist yet.

#18

Since I don’t have a Trello account I can’t vote, but I do hope you will add this feature!

1 Like