Completing zoomed in item doesn't navigate to parent

Steps to reproduce

  • Have setting on to Hide ā€œcheckedā€ items (i.e., completed)
  • Zoom into parent item, with children or otherwise.
  • Complete item by pressing Cmd-Enter
  • Observe itā€™s still displayed, crossed out
  • Navigate to parent, item is still displayed, despite the setting

Expected result

  • Similar to Workflowy, I expect to be navigated to the parent item automatically when Iā€™m zoomed into a child and I complete that item
  • But even if I have to manually navigate out for some reason, I expect to have the item not displayed anymore when you navigate back to the completed itemā€™s parent

Actual result

  • Stay in crossed out item, pointlessly
  • See crossed out item in parent, even though it should be hidden

Environment

macOS Chrome Version 62.0.3202.62 (Official Build) (64-bit)


Additional comments

If the reason is to allow the user to accidentally undo the item completion, that can always be done with Cmd-Z instead. The much more common use case is completing items you actually want to complete.

The checked item not being hidden after zooming out is indeed a bug, will fix as soon as we can!

I donā€™t see the other thing (not automatically navigating to parent after current root is checked) as a bug though. I know youā€™re probably coming from years of using WorkFlowy, but not everything that WorkFlowy has but Dynalist doesnā€™t is a bugā€¦ :grimacing:

This is pretty similar to just indent (item goes to bottom) vs indent in place (item stays in place), some people want the latter behavior, but it has some added assumptions we donā€™t want to make. In this case, we donā€™t assume the user wants to navigate back to the parent. Maybe heā€™s still looking at the content, and all he wants to do is checking something. I donā€™t see good reason to navigate for him, sorry.

The best we can do is similar to how indentation in place is handled ā€“ an extra option is added, and those who want the assumption to be made can check that.

I hope thatā€™s understandable!

1 Like

If auto-zooming out after completion is added as an option, I would certainly welcome that. That would satisfy my case, and make the product more flexible. Although you obviously want to be careful making too many things configurable, as itā€™s going to hurt the maintainability of the product in the long-term.

But as far as ā€œmaybe heā€™s still looking at the contentā€, like I argued above, I think the standard behavior should satisfy the typical use case, not the 1% one. Usually when you mark something is done, itā€™s because itā€™s done, and youā€™re done with it. If you want to look at it some more, you an always undo the completion for a second, then re-do it. And this is especially true with the hide checked option on. If you want to look at checked items, wouldnā€™t that option be set to Show?

I donā€™t think you should go with just my opinion on this of course. Do we have polls as an option here? But my bet is that if you asked, ā€œDo you show completed items to stay on screen when theyā€™re set to be hidden?ā€, most would say no.

Yes, thereā€™s a poll section and anyone can post polls: šŸ“‹ Polls - Dynalist Forum

@Erica, great idea. I created the poll: Expected behavior when complete zoomed in item

Iā€™m a big fan of http://talk.dynalist.io/, btw, this is a great community platform.

Thanks! The forum just had its first anniversary. Discourse has worked nicely for discussions and polls.

1 Like

Latest blog post says:

[UI/minor] Fixed checked items not becoming hidden after checking the current root item and zooming out.

I refreshed the content page, but Iā€™m still seeing the same behavior. I check the parent item, zoom out, checked off item is still visible in the list.

Btw, some further behavior and possible another bug:

  • If I toggle Show / Hide to Show, then Hide again, the parent item correctly disappears
  • If I then hit Cmd-Z to undo, the parent item comes back, but its children are not visible at all, even though they were never checked off, only the parent item. This is true even if I zoom into that parent item.
  • If I toggle Show / Hide to Show, then Hide again, the children reappear

Please let me know if you something like a repro video to show this, but hopefully thatā€™s clear.

Sorry, that was a mistake, and Iā€™ve corrected the blog post.

It will be in production before next Monday though.

1 Like

It should be fixed in the web app now, please confirm @Alex_Pasternak?

The original bug seems to be better, and the parent disappears when you zoom out.

However, there is still the strange behavior I referenced where the children items appear/disappear depending on Show/Hide checkbox state when zoomed into the completed parent item, even though theyā€™re not themselves completed. I referenced this in more detail in the comment above. Once again, lmk if youā€™d rather have a separate bug report on this, but it seems pretty connected.

Yeah Iā€™d really appreciate that. We try to resolve bug as it was reported, and I believe thatā€™s the case for this bug, with its reproduction steps and expected/actual results. Separating them is better for communication and morale :slight_smile:

Any further to fixing this behavior, or making it configurable? Donā€™t you think itā€™s strange that this is an exception to the user-selected filter? My setting literally says Hide checked items, and yet Iā€™m able to see this checked item.

Itā€™s like the user said ā€œI only want to see red itemsā€ and then changes one to a green. DL here says ā€œI heard you, but this one used to be red, so you probably still want to see it?ā€ Nope. Itā€™s completed, I want it out of my sight right away.

Same thing when you set notes to hidden, but you will still see it when you start editing the note. I think the deal-breaker for us is that we do not want the zoom out behavior. So if we hide the root item, the page will be a blank pageā€¦

Iā€™d like to think itā€™s universally considered strange, but from the poll it looks like itā€™s debatable. Itā€™s not like the majority of users think the current behavior is completely normal either, otherwise the poll result would be more like 90% to 10% rather than 50% to 50%, so maybe we can add (yet) another advanced option for this.

1 Like

Hi @Alex_Pasternak,

Doing a bug clean-up right now, do you mind if I close this? Iā€™ve move it to be a feature request.

1 Like

Thanks for checking, sure. Since the current behavior is by design, a feature request to control it does seem more appropriate.

1 Like