Spec for Checklist Change?

Many users requested changes to the way checklists work. That’s now a planned feature—hurray!

There are a bunch of competing ways the feature could be changed. Since the last forum thread about this was a while ago, and there isn’t a description in the Trello feature, could we get a provisional spec for the changes to checklist behaviour? @Erica

Current Behaviour

There is a “Make checklist” option with which you can make parents checklists. The parent, its children, and all of its direct descendants are now “checkable” (i.e., they have a checkbox next to them).

My Proposed Spec

There is a “Add/remove checkbox” option. So instead of making parents checklists, you make the individual tasks checkable. Then, a checkbox shows next to that item and that item only—as simple as that.

Importantly, if your cursor is in an item with a checkbox and you hit Enter, the new item also has a checkbox. If your cursor is in an item without a checkbox, the new item does not have a checkbox.

In addition to the “Add/remove checkbox,” there is also a “Make/Unmake checklist” option which works as so: When you click “Make checklist” on a list, it is as if you had clicked “Add checkbox” to all the descendants (not just children) of the list. If any children of a list have checkboxes, then instead an “Unmake checklist” option appears which simply removes checkboxes from all descendants.

Example

Say I have a “morning ritual” list with some children. I want to use checklist functionality per the new spec. I select the children and make them checkable. If I ever add new items, they will automatically inherit the checkabilty, so no problem.

If I want to manually make some items non-checkable, I just select them and make them uncheckable using the context menu.

Why is this Awesome?

It’s by far the simplest and most natural spec. Simplest to implement. Simplest to grasp. “Add checkbox” and “Remove checkbox”: Two words explain the whole thing. No one will have to figure out how the system works or get irritated when they don’t know how to do something.

I think this is the most flexible and accomodating option of all, while requiring the fewest clicks.

Also, some people (e.g., me) want to check all descendants, not just children, and some people just want to check children (e.g., @Vincent_Tang). I think this indicates clearly we need two options. This proposed spec accommodates both. I don’t really see how “traditional” spec could.

There are nice aspects of this spec, but a few questions:

  • Does it make making bulk check list hard? (i.e. will it be a lot of work to do what can be easily done right now)
  • “If your cursor is in an item without a checkbox, the new item also has a checkbox.” So every time you press Enter, even when the previous item doesn’t have checkbox, the next one will have one? Some thing must be wrong, am I misunderstanding something?
  • “Importantly, if your cursor is in an item with a checkbox and you hit Enter, the new item also has a checkbox.” Won’t this potentially cause problems? Say I want to quick add something after a checkbox item, with no intention to make it another checkbox. Now I have to remove the checkbox manually.

I’m voting for current behaviour + button&shortcut to add/remove checkbox
This way you can remove checkboxes from some items when you are in a checklist (and children of these ‘uncheckboxed’ items also shouldn’t have checkboxes.)
And you can also add checkboxes in some random places without creating checklists.

Just a matter of selecting and checking—basically just as easy. And the effort scales: Think about the flexibility. With the new feature you released of selecting non-adjacent items, users could go wild and check precisely whatever they want to for not a whole lot more effort.

Under the old system, one very basic action was easy, and everything else hard.

[quote=“Erica, post:3, topic:962”]
“If your cursor is in an item without a checkbox, the new item also has a checkbox.” So every time you press Enter, even when the previous item doesn’t have checkbox, the next one will have one? Some thing must be wrong, am I misunderstanding something?[/quote]

Whoops, that was a typo. If the previous item wasn’t checkable, the new one wouldn’t be either.

Well, under the alternative spec, if you wanted to add a non-checkable item, you would still have to first create the item, then mark it as non-checkable: exactly the same number of clicks.

Could you explain why you prefer the current behaviour? I’m merely curious.

What you describe can be achieved by “Add checkbox” spec too.

Because I don’t expect new node on the same level to inherit any setting from the previous node. When you for example create heading or add color to the node and press enter then the next node is normal. It should be the same with checkboxes in my opinion - if you want next nodes to have checkboxes then mark the parent as checklist (current behaviour) and remove checkboxes from some nodes if they are not needed (this is the change I would like to see) or add checkbox each time by yourself in normal list (this is the change I would like to see).

This gives me new idea - I sometimes DO want to have the same settings (color for example) from previous node. Maybe alt+ctrl+enter to duplicate node with all settings but without text? I will try to create this in powerpack. If DL team add new property to node as I’m proposing (node.has_checkbox = true/false) this could also copy this setting in the new node.

Or maybe we could have a toggle (keyboard shortcut) to turn on/off a ‘duplicate all settings from previous item/node’. So, while it’s on, a simple ENTER would copy checkbox presence, color etc from predecessor.

A disadvantage is that, implemented this way, it’s an all/nothing duplication thing.

1 Like

What is powerpack? Could you describe more how you would go about implementing this yourself? I’d be interested to know to hack around others things myself :slight_smile:

Here’s a problem with the “traditional” spec: There’s no way to achieve the following layout.

  • [ ] Foo
    • Bar
      • [ ] Baz

Now that’s simply inelegant and frustrating. The “simple” spec of “Add/remove checkboxes” allows all kinds of layouts.

Here’s a (solvable) problem with the “simple” spec of “Add/remove checkboxes”: Say you have a list of items which themselves have sub-items like so.

  • Foo
    • Bar 1
      • Baz 1a
      • Baz 1b
    • Bar 2
      • Baz 2a
      • Baz 2b

You want to make all the Bars and Bazes have checkboxes. But if you try to select all the Bars (which also highlights the Bazes) and then add checkboxes, the Bazes wouldn’t get checkboxes.

Solution: In addition to the “Add/remove checkbox,” have a “Make/Unmake checklist” option which works as so:

When you click “Make checklist” on a list, it is as if you had clicked “Add checkbox” to all the descendants (not just children) of the list. If any children of a list have checkboxes, then instead an “Unmake checklist” option appears which simply removes checkboxes from all descendants.

If it’s not too long, perhaps the “Make checklist” option could be called “Add checkboxes to children” to be totally clear.

+1 I want individually controlled checklists, as of right now its too confusing. I want more flexibility in choosing what to checkoff on

make behavior similar to how current behavior of how numbered child lists are

Basically, only first-level children inherit checkbox (their children do not)

I don’t use bulk checklists so parent-checkbox should be something that can be set in dynalist settings

But if you want to use this script for more than some playing around, it would be better to wait for new version, I’m rewriting it right now, it should be done later this week with couple of new features

1 Like

@Erica Some people, like @Vincent_Tang below, want to check just children, not all descendants.

Some people, me included for my travel checklist, want to check all descendants, not just children.

I think this indicates clearly we need two options. The “simple” spec accommodates both. I don’t really see how “traditional” spec could.

i think your spec makes the most sense, I still have trouble wrapping my head around all the possible ways you can manipulate checkboxes since I don’t use them that often

my major use for checklists is to highlight mostly items that are more important others when there are other items at the same level

this could be done with text formatting, color tagging, regular tags, etc but checkboxes are easy for me to look at and don’t take up extra space either