Just a note about these proposals: their are not independent and should not necessarily be voted separated. They rather present main ideas we should debate on, like: A. Create: Ask user for the title instead and use 'identifier' to represent the page name; B. Tree: Decide how to display the tree + see if the tree can display the new page's location or just it's parent (also this name is problematic since it has legacy meaning); C. Delete: Replace the listing of children inside livetable with links to specialized views; D. Move: decide what actions we provide (and if we should combine some) + decide if we rather make them consistent (using a single conditional template) or we should opt for simplicity (and display just the fields the user would need); Also the copy for the labels is not final, but used just to show the functionality needed. Thanks, Caty On Fri, Jul 17, 2015 at 12:59 AM, vincent(a)massol.net <vincent(a)massol.net> wrote:

On Fri, Jul 17, 2015 at 10:23 AM, Jean SIMARD <jean.simard(a)xwiki.com> wrote: I think Title/Name of the page is much important than location, since this fields needs mandatory user input (at least as we don't provide random naming). The location can be determined by the location where the user clicked on 'Add' (currently we suggest creating child pages) so the user can just forget about that field and just click 'Create' (he can modify it if needed). Yes, this is one of the decisions we need to make: A.1 when we display the identifier? - always in order to be consistent with the wiki creation step (this is not really needed since advanced users are creating wikis); - on-demand: when expanding the location field, see http://design.xwiki.org/xwiki/bin/download/Proposal/NestedTreeDisplayer/Tre… - just for advanced users A.2 generate identifier from title - just as in wiki creation (as you already mentioned) I'm +1 for TL As I said Location can be auto-generated, so I don't see why we should burden the user with a tree that he might not need. Having the tree inline or as overlay may have some problem with large trees (anyway we will provide fixed dimensions). I'm +1 for Tree 3 I like Delete 2 (more preference since it's displayed as warning, not just informative) or Delete 1+2. The purpose of the Delete step is to warn the user the change will affect multiple pages. I'm not sure how important is to see the exact pages will be affect, but it's more important to see the impact/count. Clicking on the link will take the user to a more detailed view of the impact of his action. +1 for MCR 2.A Thanks for your vote. In order to reach a summary we would need more votes, so please give your opinion. Thanks, Caty

Hi, = Create +1 for TIL [1] +1 for 2.B - based on TL, with the mention that the unexpanded view is the one above, i.e. [1], and, when expanding you get [2] which can then be further expanded in an advanced mode to [3]. In other words, reverse in 2.B the position of the breadcrumbs with the tree selector so that, by default, you only see the breadcrumbs and can then edit (see the tree selector) and finally edit advanced (see the reference editor where you can input "holes" in the parent reference). = Delete I gues Delete 3: Accordion would be the nicest, allowing both to see and to select all the children/backlinks to affect (IMO we should not complicate things with individual children/backlinks selection), but be aware that we will have the same issue that we are currently discussing about displaying documents in the livetable, in a separate thread. The current document being deleted could be a top level document and underneath it there could be 2-3-10-20 levels of hierarchy which *will* introduce scalability issues. Given the above, I believe either "Delete 2: Link" (the extra highlighting would not hurt IMO, since it's a destructive operation) or "Delete 1+2: Count + Link" would be a better candidate. I also see an "pencil" (edit) icon next to the source section. I am not sure if we should allow changing the page to be delete in this view, since we are already on the delete action of a specific page. If we want a dedicated page for the delete operation (or other operations as well) then we should discuss it an do it as such, but mixing the 2 is not a good idea IMO. = Move/Rename/Copy Regarding the target field, we should reuse whatever UI control we decide to use for the create operation, to preserve consistency and minimise duplication. Mentioning it since I do not see this reflected in the proposals. IMO, it should be an implementation detail if we reuse the code in the background for these 3 operations, but the user should be presented with at least 2 (Move/Rename = Relocate? + Copy) or even 3 (Move + Rename + Copy) operations, so that his task is clear. = General note After going through this, my impression is that we risk cluttering the UI with all the possible options around the target field (tree + "holes" in references + ID + etc.) and we should be very careful to keep this to a minimum. Thanks, Eduard ---------- [1] http://design.xwiki.org/xwiki/bin/download/Proposal/NestedCreate/createTitl… [2] http://design.xwiki.org/xwiki/bin/download/Proposal/NestedTreeDisplayer/Tre… [3] http://design.xwiki.org/xwiki/bin/download/Proposal/NestedTreeDisplayer/Tre… On Thu, Aug 6, 2015 at 11:17 AM, Gabriela Smeria <gabriela.smeria(a)xwiki.com> wrote:

Hello. I just realized that I've forgotten to reply to this mail. About delete: My preference goes to accordion (closed by default). When closed, it is not very crowded, and you can easily have all necessary informations. Let's count: Caty: delete 2 or 1+2 Jean: delete 3 (accordion) Gabriela: delete 3 (accordion) Edy: delete 2 or 1+2 Me: delete 3 (accordion) Marius: delete 1+2 (http://jira.xwiki.org/browse/XWIKI-12268) Conclusion: delete 1+2: 3 votes delete 2: 2 votes + 1 non-binding vote So right now it's a bit tough to chose. We need more vote ASAP please, since I'm working on it. Thanks, Guillaume

About Move/Rename/Copy, I also say +1 for MCR2.A. So it seems MCR 2.A is the favorite choice in the community. Thanks, 2015-08-18 18:01 GMT+02:00 Marius Dumitru Florea < mariusdumitru.florea(a)xwiki.com&gt;gt;: -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project