PSA: checkbox revamp is live

Read more here: https://blog.dynalist.io/psa-checkbox-revamp/

3 Likes

Hi,

Currently it doesn’t work for me in the Windows desktop app. It does work in the web app. Do I have to wait for the Windows app to update?

Woop, thanks for this! Single checkboxes make a really nice way to separate tasks out from other items, both visually and through search … it’s been so long since I wanted this I had forgotten I even did, but very happy now :slight_smile:

Edit: I wonder if there’s a way through the manual CSS to change the look of a checkbox further e.g. the background colour … probably

If you do the migration steps first on the web app, the desktop app won’t be broken (it will look the same as before), so I suggest you do the migration on web right now.

Windows app release will come very soon (within a day or two).

Thanks for the kind words! :slight_smile:

Checkboxes are a little tricking to CSS. If you know how you want them to look, we may be able to help (please start a thread in help/developer category though).

Thank you for your quick response!

I might be missing something. If I have a list like so:

  • Top Level
    1. Level One
    2. Level One
      • Level two
      • Level two
      • Level two
    3. Level One

And I select “top level” > “add checkmark to children” that works as expected, all items have checkmarks except “top level.” But if I do the same thing with a “level one” item, both that item and the children have checkmarks. Shouldn’t it only be the “level two” items that have checkmarks? Or is it expected that “add checkmark to children” adds it to the parent as well? Sorry, I’m having a hard time understanding what the default behavior is supposed to be right now…

Do you need to manually migrate all lists in all documents via the web app to get it working in the desktop app?

Because, I just created a brand new document in the web app, and I don’t have the new option to only add the checklist to the parent node:

This is what the new document looks like without the menu open, I have not applied any checkboxes anywhere in this document so there’s nothing to migrate, and the doc was created a couple of mins ago so was def created after the new feature launch:

The “add checkbox to children” option does add a checkbox to itself too.

I understand it’s a bit counter-intuitive; it’s for the consideration that something should happen when the parent has no children at all. It used to confuse many users when the old “Add checkbox to children” doesn’t do anything, even though we have renamed the option from “Make checklist” to “Add checkbox to children”.

But now I think about it, we can display a little message saying there’s no children to add checkbox too, which should solve this case. Will fix, sorry about the confusion!

The desktop app update hasn’t been updated yet, so I would suggest waiting for the update if you use both platforms.

That’s on the web app? Weird. Have you refreshed the page, if I may ask?

Thank you Dynalist team! The new checkbox functionality is taking a little getting used to, but I love that I can now have checkbox items where the children do not have checkboxes. That means I can finally tuck notes under my tasks.

I also appreciate that when I type ENTER on a checkbox item, the sibling/child is also a checkbox item. :+1:

Thanks for continually improving a great service!

Craig

3 Likes

“it’s for the consideration that something should happen when the parent has no children at all.”

But it happens even if it does have children!

I meant that was the motivation which led to the mistake. It will be fixed very soon, if I didn’t make myself clear.

1 Like

I like the new checkbox functionality, thank you.

What I don’t like guys is how you managed the change. I was expecting an automatic migration, to have checkboxes exactly as they were before the upgrade. Now I have an uncertainty situation where I don’t know whether a particular item was meant to have a checkbox or not, and this is everywhere. You’re giving me some homework in a very, very busy day.

Dynalist for me means reliability, that’s my first priority. This is a step backward I have to say, with all respect and appreciation for this great tool and you great guys.

1 Like

I’m really sorry about the inconvenience, Francesco.

Internally we talked about lots of solutions with automatic migration, because it was what we wanted at first. It also seemed natural to us that people should automatically get the new behavior without doing anything.

However, after lots of discussion, we realized that

  1. With automatic migration, we’re generating new revisions for all Dynalist users. On your version history, you should be able to trace each change, we do not want to have a bunch of revisions by “Dynalist system”;

  2. Automatic migration is more error prone and increases chance of messing up with everyone’s data, unlike changing it yourself intentionally. Like you, we wanted Dynalist to be reliable and don’t want to risk chance of data loss unnecessarily;

  3. Manual migration makes sure that the user knows about the change. With automatic migration, we imagine many more people will be confused about why the old way of making lists is no longer working.

For these reasons, we decided not to go the automatic migration route. I just wanted to explain some reasoning we had and let you know that we have considered the more pain-free automatic migration.

Sorry to hear that, this is especially an issue if you don’t have the time to migrate everything in one pass.

If it’s only one pass, it’s more obvious that anything under a parent with checkbox used to have checkboxes.

2 Likes