Allow hierarchical sorting and navigation in ‘/move to’ dialog

This would enable the equivalent of WFx’s beloved move-to-child functionality.

2 Likes

Can you tell me more, what is hierarchical sorting, how would you like to navigate inside the /Move To dialog?

The dialog for /Move To to list destinations according to the order that they are already arranged within Workflowy. See these two images for example. I’m asking that items within the calendar bullet should always appear before items in the projects bullet. This rule would also propagate to sub-bullets.

Presently, the /Move To dialogue presents options from the Projects bullet or even the Reference bullet much higher in the list than matching items in the Inbox, Next, or Calendar bullets.


I for one have often found myself in the situation where I want to move a node to another node for which I can only remember the location (ie the parent node). Being able to drill down within nodes inside the move to dialog would help me in such situations.

2 Likes

@nickbakerwashere

Could you please show me some more examples, ideally with the /Move To open, showing things you don’t expect. Maybe it’s related to me not knowing how it worked in WFx — forgive me my ignorance — but for some reason it’s very hard for me to understand the desired behavior you’re describing. Just as an exercise in understanding, would it make sense if I phrased it as “The higher a bullet is in the tree, the higher priority it should have in the /Move To dialog”?

@vincentnoel

Is it like you have this:

- Parent
  - Child A
  - Child B

…but don’t remember the “Child A”, and so you want to “list what’s inside” the Parent without leaving the /Move To dialog?

1 Like

Yes, you interpreted my attempt perfectly :slight_smile:

The higher a bullet is in the tree, the higher priority it should have in the /Move To dialog

Here’s an example of the /Move To dialogue that is challenging for me to use easily.

Here’s what WFx “move to child” looks like when I have it directed to display the children of “Calendar”. It’s so easy to use :slight_smile: I can stay organized easily!

1 Like

Yep that’s exactly it. I have many nodes in Parent and I want to move the current node in one of them, but I can’t remember its exact name (I just created it, or there are many nodes with similar names)
Usually I end up opening another workflowy window, find the parent, then the target, then go back to the other window etc.
To clarify: parents are usually broad categories, which exist in limited numbers, but can contain lots of stuff

Ah that’s similar to Tanas “Move to” behavior. You select the parent node and then choose nodes within it to get it to where you want it.

And does this second window, with the children, has a search of its own, or you kind of just tap-tap-tap around it until you get to the child you’re looking for?

Move to Children should be a separate feature request. However, here’s more info:

This link may help.

Here’s an excellent overview video.

Ah. Frank’s voice is so young and innocent in this video.

Move to Children should be a separate feature request

Okay, so I just implemented and pushed the “/Move To Child” command so we don’t have to talk about it anymore.

As for the original request to adjust the search algorithm, I’d need to convince another guy to work on it, and he’s currently busy working on the mobile UI, so no promises! But I’ll make this position known. The best way to push it forward is to continue mentioning it in response to the regular updates - the team reads these ones really carefully.

3 Likes

some feedback on the " move to child" command:

  • it is very useful and might solve my use case
  • the dialog that opens could be titled “move to child of…” (to make the intent clearer)
  • when I select a parent node using the dialog, I only see a small subset of the children therein, like 5. When someone uses the “move to child” command, it is probable that she is trying to move the node to a parent that has a lot of children, so showing only 5 of them would kinda defeat the purpose. (I know I can still search for the children by name, but then I could have just used the “move to…” command. The whole point is that I don’t know the name of the destination)

Nice!

Just pushed two changes to beta:

  1. Replaced “Move to child…” with “Move to child of…” (any help with any phrasing in English is always appreciated)
  2. Removed the limit on visible items when showing the list of children (didn’t notice it the first time)
3 Likes

This is wonderful! Thank you for implementing this so quickly!

Did you assign a keyboard shortcut to “Move to child of…”?

Thank you for this feedback. What platform are these “regular updates” published where I can mention it?

Did you assign a keyboard shortcut to “Move to child of…”?

I didn’t. Hotkeys is a delicate topic in the team, often needs deliberation.

What platform are these “regular updates” published where I can mention it?

Among other places, they’re also published on this forum, e.g. here’s the last one:

1 Like

Can hotkeys be configurable? Then each user can make it how they like. That’s one feature of Dynalist that I enjoy.

2 Likes

We’ve rewritten a bunch of stuff that needs to be rewritten to make the hotkeys configurable, but there’s still way to go. So, eventually — yes. Just not soon.

4 Likes

Ah. Frank’s voice is so young and innocent in this video.

Yeah… I sound a little like Rodolfo.

@anatoliy I’ve taken this for a spin in the desktop browser app and the mobile app, and it is really smooth. I love it. What makes it powerful is when you throw one of our new shortcuts into the mix. It makes it really precise. And I think I’m falling in love with mobile for just this feature alone.

I should make some new screencasts about the native WorkFlowy implementation now.

2 Likes

On mobile, it would be great if, when searching for the text of a shortcut, the associated node would show up as a result. On mobile it’s a lot faster to get into search (the icon is right there at the bottom right) than to get into the jump field

1 Like