11 Aug
2015
11 Aug
'15
3:55 p.m.
On Mon, Aug 10, 2015 at 7:17 PM, Eduard Moraru <enygma2002(a)gmail.com> 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/createTitl…
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/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,
Caty, thanks for the proposal!
These are my options regarding:
- Create -
3rd picture from TIL:
http://design.xwiki.org/xwiki/bin/download/Proposal/NestedCreate/createTitl…
- 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*
gabriela.smeria(a)xwiki.com
skype: smeria.gabriela
On Thu, Jul 30, 2015 at 6:00 PM, Ecaterina Moraru (Valica) <
valicac(a)gmail.com> wrote:
this
not
your
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Fri, Jul 17, 2015 at 10:23 AM, Jean SIMARD
<jean.simard(a)xwiki.com>
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 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 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
trees
= 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 (anyway we will provide fixed dimensions).
I'm +1 for Tree 3
just
= Delete =
About Delete, the accordion looks nice to me.
I like Delete 2 (more preference since it's displayed as warning, not 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 opinion.
Thanks,
Caty
actions.
[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 >
> http://design.xwiki.org/xwiki/bin/view/Proposal/NestedActions
>
> Thanks,
> Caty
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Jean Simard
jean.simard(a)xwiki.com
Research engineer at XWiki SAS
http://www.xwiki.com
Committer on the XWiki.org project
http://www.xwiki.org
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs