[xwiki-devs] [Iteration][UX] Nested: Page Actions
Hi devs, This iterations covers page actions: create, delete, rename, copy, move. Also it contains a proposal on the tree displayer inside page actions. http://design.xwiki.org/xwiki/bin/view/Proposal/NestedActions Thanks, Caty
Thanks Caty for this investigation. I need more time to process all this and voice my preferences but one idea I wanted to float is that of using TL for Simple Users but allowing Advanced Users to be able to select the Identifier. I’m still unsure if it’s a good idea or not but I think it’s an option we should evaluate. Thanks -Vincent On 16 Jul 2015 at 23:40:34, Ecaterina Moraru (Valica) ([email protected](mailto:[email protected])) wrote:
Hi devs,
This iterations covers page actions: create, delete, rename, copy, move. Also it contains a proposal on the tree displayer inside page actions.
http://design.xwiki.org/xwiki/bin/view/Proposal/NestedActions
Thanks, Caty
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, [email protected] <[email protected]> wrote:
Thanks Caty for this investigation.
I need more time to process all this and voice my preferences but one idea I wanted to float is that of using TL for Simple Users but allowing Advanced Users to be able to select the Identifier. I’m still unsure if it’s a good idea or not but I think it’s an option we should evaluate.
Thanks -Vincent
On 16 Jul 2015 at 23:40:34, Ecaterina Moraru (Valica) ([email protected] (mailto:[email protected])) wrote:
Hi devs,
This iterations covers page actions: create, delete, rename, copy, move. Also it contains a proposal on the tree displayer inside page actions.
http://design.xwiki.org/xwiki/bin/view/Proposal/NestedActions
Thanks, Caty
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Caty, Nice propositions, as always :-) = Create = For the Create, I would see the 'location' as the first attribute to fill. Not title, nor identifier. My thinking about that is that you take care of the widest information first and take care of the more specific information after. But maybe it's only me who think like that [1]. About TL vs TIL, I see 2 different possibilities. First you could enable an "advanced mode" to access this identifier. Second, the identifier could fill automatically based on title (like today in a wiki creation) but leave the opportunity to change it by the user (but maybe this is already what you expressed in your mockup, not sure of this point ^^). = Tree = Not a fan of the propositions that hide things. Therefore, Tree 2 inline seems the best in my opinion. = Delete = About Delete, the accordion looks nice to me. = Copy, Move, Rename = For Copy/Move/etc, I see that you put the ability to create a copy in the Move page. Usually, Move and Copy are 2 distinct actions (even if I agree that they're similar) and as a user, I expect to have 2 different actions accessible. So MCR2.A seems more appropriate to me. Hope this helps, [1] Note that as a French, it's a paradox because French often do the other way around (for example, for postal address or for dates, we go from the most specific information to the widest information [name, street, city], [day,month,year]). On 16/07/2015 23:40, Ecaterina Moraru (Valica) wrote:
Hi devs,
This iterations covers page actions: create, delete, rename, copy, move. Also it contains a proposal on the tree displayer inside page actions.
http://design.xwiki.org/xwiki/bin/view/Proposal/NestedActions
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org
On Fri, Jul 17, 2015 at 10:23 AM, Jean SIMARD <[email protected]> wrote:
Hi Caty,
Nice propositions, as always :-)
= Create = For the Create, I would see the 'location' as the first attribute to fill. Not title, nor identifier. My thinking about that is that you take care of the widest information first and take care of the more specific information after. But maybe it's only me who think like that [1].
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).
About TL vs TIL, I see 2 different possibilities. First you could enable an "advanced mode" to access this identifier. Second, the identifier could fill automatically based on title (like today in a wiki creation) but leave the opportunity to change it by the user (but maybe this is already what you expressed in your mockup, not sure of this point ^^).
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/Tree... - just for advanced users A.2 generate identifier from title - just as in wiki creation (as you already mentioned) I'm +1 for TL
= Tree = Not a fan of the propositions that hide things. Therefore, Tree 2 inline seems the best in my opinion.
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
= Delete = About Delete, the accordion looks nice to me.
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.
= Copy, Move, Rename = For Copy/Move/etc, I see that you put the ability to create a copy in the Move page. Usually, Move and Copy are 2 distinct actions (even if I agree that they're similar) and as a user, I expect to have 2 different actions accessible. So MCR2.A seems more appropriate to me.
+1 for MCR 2.A
Hope this helps,
Thanks for your vote. In order to reach a summary we would need more votes, so please give your opinion. Thanks, Caty
[1] Note that as a French, it's a paradox because French often do the other way around (for example, for postal address or for dates, we go from the most specific information to the widest information [name, street, city], [day,month,year]).
On 16/07/2015 23:40, Ecaterina Moraru (Valica) wrote:
Hi devs,
This iterations covers page actions: create, delete, rename, copy, move. Also it contains a proposal on the tree displayer inside page actions.
http://design.xwiki.org/xwiki/bin/view/Proposal/NestedActions
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hello, Caty, thanks for the proposal! These are my options regarding: - Create - 3rd picture from TIL: http://design.xwiki.org/xwiki/bin/download/Proposal/NestedCreate/createTitle... - Tree - Tree 2.A - Based on TIL is also my choice, since it doesn't hide things. - Delete - Delete 3. Accordion is my choice. It displays all the information needed and also a nice way to hide the things that you've already checked - less crowded than the others and it has the highest ease of use. - Rename, Move, Copy MCR 2.A is my option. I think seperate actions are more clearer and the end-user will not get mixed up in what he/she actually wants to achieve. Thanks, Gabriela *Gabriela Smeria* *Web Developer* [email protected] skype: smeria.gabriela On Thu, Jul 30, 2015 at 6:00 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
On Fri, Jul 17, 2015 at 10:23 AM, Jean SIMARD <[email protected]> wrote:
Hi Caty,
Nice propositions, as always :-)
= Create = For the Create, I would see the 'location' as the first attribute to fill. Not title, nor identifier. My thinking about that is that you take care of the widest information first and take care of the more specific information after. But maybe it's only me who think like that [1].
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).
About TL vs TIL, I see 2 different possibilities. First you could enable an "advanced mode" to access this identifier. Second, the identifier could fill automatically based on title (like today in a wiki creation) but leave the opportunity to change it by the user (but maybe this is already what you expressed in your mockup, not sure of this point ^^).
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/Tree... - just for advanced users
A.2 generate identifier from title - just as in wiki creation (as you already mentioned)
I'm +1 for TL
= Tree = Not a fan of the propositions that hide things. Therefore, Tree 2 inline seems the best in my opinion.
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
= Delete = About Delete, the accordion looks nice to me.
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.
= Copy, Move, Rename = For Copy/Move/etc, I see that you put the ability to create a copy in the Move page. Usually, Move and Copy are 2 distinct actions (even if I agree that they're similar) and as a user, I expect to have 2 different actions accessible. So MCR2.A seems more appropriate to me.
+1 for MCR 2.A
Hope this helps,
Thanks for your vote.
In order to reach a summary we would need more votes, so please give your opinion.
Thanks, Caty
[1] Note that as a French, it's a paradox because French often do the other way around (for example, for postal address or for dates, we go from the most specific information to the widest information [name, street, city], [day,month,year]).
On 16/07/2015 23:40, Ecaterina Moraru (Valica) wrote:
Hi devs,
This iterations covers page actions: create, delete, rename, copy,
move.
Also it contains a proposal on the tree displayer inside page actions.
http://design.xwiki.org/xwiki/bin/view/Proposal/NestedActions
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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/createTitle... [2] http://design.xwiki.org/xwiki/bin/download/Proposal/NestedTreeDisplayer/Tree... [3] http://design.xwiki.org/xwiki/bin/download/Proposal/NestedTreeDisplayer/Tree... On Thu, Aug 6, 2015 at 11:17 AM, Gabriela Smeria <[email protected]> wrote:
Hello,
Caty, thanks for the proposal!
These are my options regarding:
- Create - 3rd picture from TIL:
http://design.xwiki.org/xwiki/bin/download/Proposal/NestedCreate/createTitle...
- Tree - Tree 2.A - Based on TIL is also my choice, since it doesn't hide things.
- Delete - Delete 3. Accordion is my choice. It displays all the information needed and also a nice way to hide the things that you've already checked - less crowded than the others and it has the highest ease of use.
- Rename, Move, Copy MCR 2.A is my option. I think seperate actions are more clearer and the end-user will not get mixed up in what he/she actually wants to achieve.
Thanks, Gabriela
*Gabriela Smeria* *Web Developer* [email protected] skype: smeria.gabriela
On Thu, Jul 30, 2015 at 6:00 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
On Fri, Jul 17, 2015 at 10:23 AM, Jean SIMARD <[email protected]> wrote:
Hi Caty,
Nice propositions, as always :-)
= Create = For the Create, I would see the 'location' as the first attribute to fill. Not title, nor identifier. My thinking about that is that you take care of the widest information first and take care of the more specific information after. But maybe it's only me who think like that [1].
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).
About TL vs TIL, I see 2 different possibilities. First you could enable an "advanced mode" to access this identifier. Second, the identifier could fill automatically based on title (like today in a
wiki
creation) but leave the opportunity to change it by the user (but maybe this is already what you expressed in your mockup, not sure of this point ^^).
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/Tree...
- just for advanced users
A.2 generate identifier from title - just as in wiki creation (as you already mentioned)
I'm +1 for TL
= Tree = Not a fan of the propositions that hide things. Therefore, Tree 2 inline seems the best in my opinion.
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
= Delete = About Delete, the accordion looks nice to me.
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.
= Copy, Move, Rename = For Copy/Move/etc, I see that you put the ability to create a copy in the Move page. Usually, Move and Copy are 2 distinct actions (even if
I
agree that they're similar) and as a user, I expect to have 2 different actions accessible. So MCR2.A seems more appropriate to me.
+1 for MCR 2.A
Hope this helps,
Thanks for your vote.
In order to reach a summary we would need more votes, so please give your opinion.
Thanks, Caty
[1] Note that as a French, it's a paradox because French often do the other way around (for example, for postal address or for dates, we go from the most specific information to the widest information [name, street, city], [day,month,year]).
On 16/07/2015 23:40, Ecaterina Moraru (Valica) wrote:
Hi devs,
This iterations covers page actions: create, delete, rename, copy,
move.
Also it contains a proposal on the tree displayer inside page actions.
http://design.xwiki.org/xwiki/bin/view/Proposal/NestedActions
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Aug 10, 2015 at 7:17 PM, Eduard Moraru <[email protected]> wrote:
Hi,
= Create
+1 for TIL
Of course, I meant TL, as can be seen from the linked image and further explanations.
[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).
Starting to implement something along the lines of http://design.xwiki.org/xwiki/bin/download/Proposal/NestedCreate/createTitle... and we will see what we decide to do when the edit button is pressed for the location (modal popup or expanding section, etc). Thanks, Eduard
= 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/createTitle... [2] http://design.xwiki.org/xwiki/bin/download/Proposal/NestedTreeDisplayer/Tree... [3] http://design.xwiki.org/xwiki/bin/download/Proposal/NestedTreeDisplayer/Tree...
On Thu, Aug 6, 2015 at 11:17 AM, Gabriela Smeria < [email protected]> wrote:
Hello,
Caty, thanks for the proposal!
These are my options regarding:
- Create - 3rd picture from TIL:
http://design.xwiki.org/xwiki/bin/download/Proposal/NestedCreate/createTitle...
- Tree - Tree 2.A - Based on TIL is also my choice, since it doesn't hide things.
- Delete - Delete 3. Accordion is my choice. It displays all the information needed and also a nice way to hide the things that you've already checked - less crowded than the others and it has the highest ease of use.
- Rename, Move, Copy MCR 2.A is my option. I think seperate actions are more clearer and the end-user will not get mixed up in what he/she actually wants to achieve.
Thanks, Gabriela
*Gabriela Smeria* *Web Developer* [email protected] skype: smeria.gabriela
On Thu, Jul 30, 2015 at 6:00 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
On Fri, Jul 17, 2015 at 10:23 AM, Jean SIMARD <[email protected]> wrote:
Hi Caty,
Nice propositions, as always :-)
= Create = For the Create, I would see the 'location' as the first attribute to fill. Not title, nor identifier. My thinking about that is that you take care of the widest information first and take care of the more specific information after. But maybe it's only me who think like that [1].
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).
About TL vs TIL, I see 2 different possibilities. First you could enable an "advanced mode" to access this identifier. Second, the identifier could fill automatically based on title (like today in a
wiki
creation) but leave the opportunity to change it by the user (but maybe this is already what you expressed in your mockup, not sure of this point ^^).
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/Tree...
- just for advanced users
A.2 generate identifier from title - just as in wiki creation (as you already mentioned)
I'm +1 for TL
= Tree = Not a fan of the propositions that hide things. Therefore, Tree 2 inline seems the best in my opinion.
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
= Delete = About Delete, the accordion looks nice to me.
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.
= Copy, Move, Rename = For Copy/Move/etc, I see that you put the ability to create a copy in the Move page. Usually, Move and Copy are 2 distinct actions (even
if I
agree that they're similar) and as a user, I expect to have 2 different actions accessible. So MCR2.A seems more appropriate to me.
+1 for MCR 2.A
Hope this helps,
Thanks for your vote.
In order to reach a summary we would need more votes, so please give your opinion.
Thanks, Caty
[1] Note that as a French, it's a paradox because French often do the other way around (for example, for postal address or for dates, we go from the most specific information to the widest information [name, street, city], [day,month,year]).
On 16/07/2015 23:40, Ecaterina Moraru (Valica) wrote:
Hi devs,
This iterations covers page actions: create, delete, rename, copy,
move.
Also it contains a proposal on the tree displayer inside page actions.
http://design.xwiki.org/xwiki/bin/view/Proposal/NestedActions
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
Hi Caty, I feel the create UI has too many options. Even if they have defaults, the user may still loose time scanning / understanding what they mean (e.g. "is this setting useful to me?"). Ideally, the user should select at most the type of page to create (blank or from a template) before entering the edit mode. The rest could be changed afterwards, from edit mode (e.g. title) or after the document is saved (e.g. move to a new location). But this requires more work, so +1 for TL. Regarding the create tree, the document location is IMO the document reference, so the "parent" + the "identifier". Thus it doesn't make sense to me to have a separate identifier field and a location field. There should be only one Location field. When you edit the location you should be able to change the parent and the identifier. For the identifier a plain text input is enough. For the parent we can use the tree. The proposal that matches this is Tree 3, so +1 for that. +1 for Delete 1+2: Count + Link For move/copy/rename, I agree with Edy that it's best to have separate screens. For rename the way we specify the target page should be consistent with the create UI, as Edy suggested (i.e. title + location, and the location gets expanded into parent + identifier). For the move/copy we should reuse the "expanded" version of the Location field from the create UI (i.e. parent + identifier, where identifier is read-only of course). So something close to MCR 2.A. Thanks, Marius On Fri, Jul 17, 2015 at 12:40 AM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi devs,
This iterations covers page actions: create, delete, rename, copy, move. Also it contains a proposal on the tree displayer inside page actions.
http://design.xwiki.org/xwiki/bin/view/Proposal/NestedActions
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 < [email protected]>:
Hi Caty,
I feel the create UI has too many options. Even if they have defaults, the user may still loose time scanning / understanding what they mean (e.g. "is this setting useful to me?"). Ideally, the user should select at most the type of page to create (blank or from a template) before entering the edit mode. The rest could be changed afterwards, from edit mode (e.g. title) or after the document is saved (e.g. move to a new location). But this requires more work, so +1 for TL.
Regarding the create tree, the document location is IMO the document reference, so the "parent" + the "identifier". Thus it doesn't make sense to me to have a separate identifier field and a location field. There should be only one Location field. When you edit the location you should be able to change the parent and the identifier. For the identifier a plain text input is enough. For the parent we can use the tree. The proposal that matches this is Tree 3, so +1 for that.
+1 for Delete 1+2: Count + Link
For move/copy/rename, I agree with Edy that it's best to have separate screens. For rename the way we specify the target page should be consistent with the create UI, as Edy suggested (i.e. title + location, and the location gets expanded into parent + identifier). For the move/copy we should reuse the "expanded" version of the Location field from the create UI (i.e. parent + identifier, where identifier is read-only of course). So something close to MCR 2.A.
Thanks, Marius
On Fri, Jul 17, 2015 at 12:40 AM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi devs,
This iterations covers page actions: create, delete, rename, copy, move. Also it contains a proposal on the tree displayer inside page actions.
http://design.xwiki.org/xwiki/bin/view/Proposal/NestedActions
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
I’m fine with MCR2.A too for now. I think I’d have preferred a wizard approach with several steps. Rationale: - less items visible on each screen. I find it a bit overwhelming to try to cram everything on one screen - more space to add future refactoring options Thus I’d have liked to use a wizard approach similar to what we do for the Distribution Wizard or the Create Wiki wizard. For example have one step for viewing all affected pages when deleting or all page that will have their parents modified, etc. Also note that a nice option (while waiting for the alias solution, see http://markmail.org/message/d34smnyap5y6l24c) would be to have a checkbox to leave a redirect when Renaming or Moving wiki pages. If this is selected we would put a $response.sendRedirect(…) call as in http://extensions.xwiki.org/xwiki/bin/view/Extension/Redirect (this could be done later on ofc but it’s also not very complex to do and would provide a nice feature that is asked by xwiki users). Thanks -Vincent On 24 Aug 2015 at 12:54:04, Guillaume Louis-Marie Delhumeau ([email protected]) wrote: 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 < [email protected]>:
Hi Caty,
I feel the create UI has too many options. Even if they have defaults, the user may still loose time scanning / understanding what they mean (e.g. "is this setting useful to me?"). Ideally, the user should select at most the type of page to create (blank or from a template) before entering the edit mode. The rest could be changed afterwards, from edit mode (e.g. title) or after the document is saved (e.g. move to a new location). But this requires more work, so +1 for TL.
Regarding the create tree, the document location is IMO the document reference, so the "parent" + the "identifier". Thus it doesn't make sense to me to have a separate identifier field and a location field. There should be only one Location field. When you edit the location you should be able to change the parent and the identifier. For the identifier a plain text input is enough. For the parent we can use the tree. The proposal that matches this is Tree 3, so +1 for that.
+1 for Delete 1+2: Count + Link
For move/copy/rename, I agree with Edy that it's best to have separate screens. For rename the way we specify the target page should be consistent with the create UI, as Edy suggested (i.e. title + location, and the location gets expanded into parent + identifier). For the move/copy we should reuse the "expanded" version of the Location field from the create UI (i.e. parent + identifier, where identifier is read-only of course). So something close to MCR 2.A.
Thanks, Marius
On Fri, Jul 17, 2015 at 12:40 AM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi devs,
This iterations covers page actions: create, delete, rename, copy, move. Also it contains a proposal on the tree displayer inside page actions.
http://design.xwiki.org/xwiki/bin/view/Proposal/NestedActions
Thanks, Caty
participants (7)
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Gabriela Smeria -
Guillaume "Louis-Marie" Delhumeau -
Jean SIMARD -
Marius Dumitru Florea -
vincent＠massol.net