Batch Move Pages Design

[amilica]

Hello, today I’d like to discuss with you the batch move functionality, something that many people asked for.

Right now there are some ways of achieving this, but they are not very user-friendly or, at least, beginner-friendly. See this forum discussion.

Proposal Summary

Create a dedicated space where pages can be selected to create a batch of pages that can be moved somewhere, taking into consideration their rights.

Where would this UI be?

The Batch Move UI could be accessed through a new entry, named Batch Move, in the

dropdown of any page.

State 1

The user just got on the UI and hasn’t selected anything yet.

---

When accessing the UI, the tree loads only the first 10 pages of the current space.
If they have children, they are collapsed.

See the default settings and messages in the proposal page.

State 2: User selects stuff

How is the selection of pages made?

Every page will have a checkbox in front of its name in the tree. Initially, this checkbox is empty.

• For terminal pages (pages with no children), the checkbox only has 2 states (state 0 and state 1 from below).

• For parent pages (pages with children), the checkbox has 4 states (states 0,1,2,3).

These are the 4 possible states of the checkbox:

State 0: Empty Checkbox: The current page hasn’t been selected.

State 1: Blue Checked Checkbox: The current page has been selected.

State 2: Green Checked Checkbox: The current page and all of its children have been selected.

• Sub-case: If current page is in state 2 (green) and the user unchecks one of its children (however deeply nested it is), current page goes in state 1 (blue).

State 3: Unchecked Crossed Checkbox: All children of the current page have been selected, but the current page hasn’t been selected.

• Sub-case: If current page is in state 3 (crossed) and the user unchecks one of its children (however deeply nested it is), current page goes in state 0 (blue).

Case 1: User selects pages but doesn’t set destination

The section “Destination space tree after moving” will contain a warning box stating the number of pages selected and warning the user to set a destination path.

Case 2: User selects pages & sets destination

If there are pages selected, once the destination is set, the tree of the destination space would be rendered, including the selected pages. This is just a simulated tree, no actual page movement is done.

At this point, the Refresh tree button is not yet present.

If after this, the user selects more pages, the Refresh tree button appears and the tree gets hidden. If the user clicks the button, the tree gets rendered.

This behavior gets repeated every time the user selects some other pages or if the user changes the destination path .

State 3 & 4: Confirm move & status bar

You can see them in the proposal page:

• confirm selection modal
• status page (to be done, but it will mainly be a loading bar + how many pages moved successfully, how many did not, how many attachment did not move + the size of the destination space - pages and gigabytes)

What do you think?

[gabrielc]

Hi Adina! Great proposal!

Batch move pages was a feature I’ve seen requested many times, and it’s great to see it’s finally being worked on .

I like the design, however I find the states a bit confusing. It’s just hard for me to wrap my head around them .

I’d instead suggest aligning with HTML standards and using indeterminate checkboxes for incomplete selections.
I feel like this change would help people better understand the available states, and would spare the XWiki team from explaining what the possible states are and what they mean.

Sources:

- HTML: HyperText Markup Language | MDN

Indeterminate Checkboxes | CSS-Tricks

[tkrieck]

Hi Adina, thanks for tackling this issue. As Gabriel said, this is something important and requested. I liked the overall proposal, I just have a few suggestions below regarding more direct wording and placement of features.

@gabrielc

I’d instead suggest aligning with HTML standards and using indeterminate checkboxes for incomplete selections.

It seems nice for me as well. +1

My opinions overall:

The title “Move a batch of pages” seems odd to me. IMO, “Batch move”, would be better because that’s the name on the menu entry.

The whole section “Rights after moving” seems like an advanced function, and perhaps a less used one. I would group it under an “Advanced” toggle and hide them by default. We can then just inform the user with a helper text like “All moved pages will have the same rights applied, and incoming links will be updated (change)” under the preview, something like that. “Change” would open the advanced settings.

The label “Destination space tree after moving” could be renamed to “Move Preview” and brought below of “Where to move the selected pages”.

Also, “Where to move the selected pages” could be renamed to “Pages Destination”

With all of this, the source destination tree and the preview tree would be pretty much aligned, and it’s easier to see the reflected changes.

Regarding the trees, I think we will need scrollbars at some point, would it be possible to mock them up?

As a closing thought, all the helper text that are links should point somewhere, and needs to be defined.

Edit: I forgot to add, I don’t think we expose the user to the term “Space” anymore. I could be wrong, but if that’s the case I think it should be renamed to Page in your proposal.

That’s it for me, thank you for working on this proposal

[amilica]

@gabrielc

I’d instead suggest aligning with HTML standards and using indeterminate checkboxes for incomplete selections.
I feel like this change would help people better understand the available states, and would spare the XWiki team from explaining what the possible states are and what they mean.

Thanks a lot for this, Gabriel! It’s a good idea.
I initially had the plan to make the checkbox have only 3 states and it seems like what you proposed would’ve been the best implementation.

I opted for having 4 states for this following usecase:

The user wants to move all the children of a page, but not the page itself.

@gabrielc , @tkrieck and everyone else coming here, wdyt about this specific case?

[amilica]

Thanks a lot, Thiago! I agree with your ideas, I’ll make the edits

[gabrielc]

@amilica

The user wants to move all the children of a page, but not the page itself.

Hmm… It is indeed trickier.

In my head, the following implementation would make sense:

• If the user explicitly selects the parent page and then removes some of the child pages, then the parent page should display an indeterminate checkbox.
• if the user doesn’t explicitly select the parent page, but selects some of the child pages, the parent page should display an unchecked checkbox.

This is what would make sense to me, but I do see how people may get confused by it. I do think that previewing the updated page tree could help relieve the confusion though.

Up until this point, in other areas of XWiki, how were similar checkbox related issues tackled?

[tkrieck]

@amilica

@gabrielc , @tkrieck and everyone else coming here, wdyt about this specific case?

IMO, it’s a small convenience, for sure. But I’m not sure if the drawbacks are enough to justify it. We’ll need to implement it (more dev work), the interface gets more cluttered, and we need to explain a new concept for the user. So, in the spirit of keeping things simple, I’d go with the standard 3 state only.

[tkrieck]

@gabrielc

Up until this point, in other areas of XWiki, how were similar checkbox related issues tackled?

You can check in the Global Admin > Content > Export. There’s a tree with a tri-state checkbox there, but one that was custom made (I’m not sure why, probably bc it’s too old for the standard).

[mleduc]

@gabrielc

Up until this point, in other areas of XWiki, how were similar checkbox related issues tackled?

When exporting, it is already possible to right-click on page and select only its children

[surli]

Hi,

thanks for the proposal it’s interesting, and globally I’m +1 with those ideas.
I’ve just a question related to the behaviour you imagine for the move when various children pages are selected without their parent page.
So for example I have the hierarchy:

• Parent 1:
  • Child 1
  • Child 2
  • Child 3
• Parent 2:
  • Child A
  • Child B

The user select Child 2, Child 3 and Child B, and the destination is Space A. Do you think the user would always want to obtain:

• Space A:
  • Child 2
  • Child 3
  • Child B

Or can we imagine that they’d want to obtain:

• Space A:
  • Parent 1 (no page)
    • Child 2
    • Child 3
  • Parent 2 (no page)
    • Child B

And then if a user might want that, maybe we need an option for it?

[mleduc]

@amilica

The Batch Move UI could be accessed through a new entry, named Batch Move, in the dropdown of any page.

The screenshot seems to be broken
Also, isn’t an option to make this part of the existing page move form?
Feels odd to have a new form specifically for this use case.

@amilica

Hello, today I’d like to discuss with you the batch move functionality, something that many people asked for.

Can you detail to what was asked for initially? This feel very advanced.
If it’s just moving a page and its children in another location, that’s already possible.

Also, what is the hierarchy after the move?

Say you selection A.B.C and A.D, and move them to X.

What are the new references of the pages? Is it X.C and X.D of X.B.C and X.D?
What happens in case of conflict? Is the user warned beforehand, or one page at a time once the batch move action is started.

[tkrieck]

@mleduc

Can you detail to what was asked for initially? This feel very advanced.
If it’s just moving a page and its children in another location, that’s already possible.

This part I can answer, it came in part from this Jira (about the status) Loading... and also a discussion linked by Adina above Batch move documents - #2 by vmassol. There’s also this another discussion where a user needs to have some pages moved to a new place, Organizing My Wiki - #4 by mflorea.

It’s different from moving a page and all its children, that part is well covered by the current feature set.

It’s an advanced feature, sure, but I can see the need for it. At least from own experience moving files around in the OS (similar UC) and moving pages around in note taking apps.

[amilica]

@mleduc

When exporting, it is already possible to right-click on page and select only its children

It’s interesting that this exists, but I imagined the user experience would improve if this choice would be made quicker with less mouse movements.

@surli

The user select Child 2, Child 3 and Child B, and the destination is Space A. Do you think the user would always want to obtain:

• Space A:
  • Child 2
  • Child 3
  • Child B

Or can we imagine that they’d want to obtain:

• Space A:
  • Parent 1 (no page)
    • Child 2
    • Child 3
  • Parent 2 (no page)
    • Child B

This is a great question and I’m happy you brought this up.
My opinion on this is that we should go for the first version. Sure the user might want the second version for a part of the selection, but maybe not for the rest of the selection.

The UI/UX that would allow full freedom of movement is something with drag and drop, where you check pages and drag them somewhere in the tree. While it would be useful, I think the implementation would become even more complex.

@surli , @mleduc , @tkrieck wdyt of this?

[MichaelHamann]

@amilica

The UI/UX that would allow full freedom of movement is something with drag and drop, where you check pages and drag them somewhere in the tree. While it would be useful, I think the implementation would become even more complex.

I’m not sure, the tree library we use supports drag & drop. In DokuWiki’s move plugin, we have such a tree-based re-ordering of the whole wiki. Where I’m a bit worried is how usable that tree would be in a huge wiki with a relatively flat hierarchy, i.e., when you have a lot of pages on the same level. We wouldn’t load all items, of course, but it still might not be trivial to find the items.

[tkrieck]

@amilica

This is a great question and I’m happy you brought this up.
My opinion on this is that we should go for the first version. Sure the user might want the second version for a part of the selection, but maybe not for the rest of the selection.

That’s my opinion as well. An advanced option could help with the second UC though. Something like “Keep parent page” (not the best name).

@amilica

The UI/UX that would allow full freedom of movement is something with drag and drop, where you check pages and drag them somewhere in the tree. While it would be useful, I think the implementation would become even more complex.

Mind you that drag-and-drop has limitations on mobile and, even in desktop use, requires a certain amount of skill and dexterity from the user, so it shouldn’t be the only way of achieving this. It’s a nice feature, and I am all for it, but it needs clears signifiers and feedback for it to work, like drag handles.

[amilica]

@tkrieck

so it shouldn’t be the only way of achieving this.

Yep, I totally agree.
I think implementing both the initial proposal and the drag and drop one would be a significant amount of implementation effort, so we probably should go for the one that it’s more mobile friendly from the start

[mflorea]

@gabrielc

I’d instead suggest aligning with HTML standards and using indeterminate checkboxes for incomplete selections.

+1 in general, but for this particular case I think we should reuse what we have already: the page tree widget.

@tkrieck

Edit: I forgot to add, I don’t think we expose the user to the term “Space” anymore. I could be wrong, but if that’s the case I think it should be renamed to Page in your proposal.

Definitely, we need to refer to pages not spaces.

@amilica

The user wants to move all the children of a page, but not the page itself.

I don’t see the problem with this use case. If the parent page is not selected but some of its child pages are selected (it doesn’t really matter if it’s all or just one) then the parent state should be indeterminate.

What can be confusing is when you have the parent page checked and collapsed: you may think that it’s child pages are also selected, but it’s not necessarily the case (e.g. if you expand the parent, uncheck a child page and collapse the parent again). But I wouldn’t add additional states even for this.

@gabrielc

• If the user explicitly selects the parent page and then removes some of the child pages, then the parent page should display an indeterminate checkbox.
• if the user doesn’t explicitly select the parent page, but selects some of the child pages, the parent page should display an unchecked checkbox.

No, that’s not how it works. First you need to decide how the selection cascades:

• top → down: checking the parent will check all the child pages, unchecking the parent will uncheck all the child pages
• bottom → up: checking all the child pages will check the parent page, unchecking all the child pages will uncheck the parent page

These two are not exclusive. In our case, since you can move a page without its child pages, the bottom → up cascade doesn’t make sense (you want to be able to uncheck all the child pages without unchecking the parent page).

With only top → down cascade in place, the only interpretation of the indeterminate state is the one provided on the link you gave:

If any one or more of the sub-options have a different state than the others, the owning checkbox is in the indeterminate state.

i.e. if the parent is not itself selected and at least one of its descendant pages is selected then the parent state should be indeterminate.

@surli

Or can we imagine that they’d want to obtain:

• Space A:
  • Parent 1 (no page)
    • Child 2
    • Child 3
  • Parent 2 (no page)
    • Child B

This doesn’t make sense to me. You move a page, not a path. That’s what the refactoring APIs supports in any case. I mean, when you call move A.B.C to X.Y you get X.Y.C

Where we need to be careful though is when we move a parent page with partial children. In your example, moving Parent 1 to X, along with its Child 1 and Child 3 but without Child 2 would have to be done in steps:

• move Parent 1 to X without children
• move Child 1 and Child 3 to X.Parent 1

Currently, we can’t do this with a sigle call to the refactoring API. We’d have to add a new API that gets as input a “page tree selection”.

@mleduc

Also, isn’t an option to make this part of the existing page move form?
Feels odd to have a new form specifically for this use case.

Definitely, BUT if we add support for selectively checking the child pages when moving a parent page then we need to separate the move operation from rename. Batch rename is different than batch move and I don’t think we want to implement it. This means:

• We can keep “Move / Rename” for terminal pages
• But for nested pages we need 2 sections:
  • Move (allowing to selectively check the child pages and even uncheck the parent / root page, much like in the export dialog)
  • Rename (the current “Move / Rename” section, whose title is “Rename” anyway, once you open it)

So this basically means:

• adding a new Move section for nested pages
• renaming “Move / Rename” to “Rename” for nested pages

Thanks,
Marius