This would enable the equivalent of WFx’s beloved move-to-child functionality.
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.
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”?
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?
Yes, you interpreted my attempt perfectly
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 I can stay organized easily!
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.
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.
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:
- Replaced “Move to child…” with “Move to child of…” (any help with any phrasing in English is always appreciated)
- Removed the limit on visible items when showing the list of children (didn’t notice it the first time)
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:
Can hotkeys be configurable? Then each user can make it how they like. That’s one feature of Dynalist that I enjoy.
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.
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.
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