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/createTitle1.png 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/createTitle1.png > [2] > http://design.xwiki.org/xwiki/bin/download/Proposal/NestedTreeDisplayer/TreeInlineB1.png > [3] > http://design.xwiki.org/xwiki/bin/download/Proposal/NestedTreeDisplayer/TreeInlineB2.png > > > 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/createTitle1.png >> >> - 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/TreeOverlay1.png >> > - 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 >> > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
