[Proposal] Improve the management of inexistent WebHome with children

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Proposal] Improve the management of inexistent WebHome with children

Denis Gervalle-2
Hi devs,

I am opening this discussion to move the discussion started in an issue
(XWIKI-12628) to its proper place, the ML. (Discussing into JIRA is very
bad since it lower the audience, we tend to have done it too much recently).

So the issue is that, in the Nested Document concept, we can create
children to inexistent (WebHome) page. This introduce some abnormalities:
 - Administering inexistent page (including page rights, see
http://jira.xwiki.org/browse/XWIKI-12629)
 - Children of inexistent page (see http://jira.xwiki.org/browse/XWIKI-12628
)

Since we agree that having nodes in the tree of pages is fine without
having the intermediate document created, we definitely need to better show
this concept to the final user. It would be a pain to explain to a user
that access rights for page children of an inexistent page is administrable
from that inexistent page. It is also very poor when you navigate from the
breadcrumb to a inexistent page as a normal user to reach "The requested
page could not be found." with no way to navigate further.

These inexistent page are not necessarily invisible, there is links to
them, and showing that as "error" page looks inappropriate IMO. So there is
probably a couple of things we could do to improve this:

A) display the list of children in addition to the actual message
B) display a "default" and nice (not an error) dashboard on them that allow
navigation (with a button for those that can edit, to create the page)
C) create them all the time, with the dashboard above by default
D) do not propose links to those page in the breadcrumb to users without
edit right on them ?
E) ... (please add more idea)

I am in favor of B) currently, since I do not think we are in an "error"
case like A) seems to expose.
I am wondering if D) could be useful as well to limit navigation to those
page or not for user that will not find them so useful... but it may exists
opposite UC.

WDYT ?


--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Improve the management of inexistent WebHome with children

Guillaume Lerouge
Hi Denis,

thanks for your message. Please see my thoughts below.

On Tue, Sep 29, 2015 at 11:12 AM, Denis Gervalle <[hidden email]> wrote:

> Hi devs,
>
> I am opening this discussion to move the discussion started in an issue
> (XWIKI-12628) to its proper place, the ML. (Discussing into JIRA is very
> bad since it lower the audience, we tend to have done it too much
> recently).
>
> So the issue is that, in the Nested Document concept, we can create
> children to inexistent (WebHome) page. This introduce some abnormalities:
>  - Administering inexistent page (including page rights, see
> http://jira.xwiki.org/browse/XWIKI-12629)
>  - Children of inexistent page (see
> http://jira.xwiki.org/browse/XWIKI-12628
> )
>
> Since we agree that having nodes in the tree of pages is fine without
> having the intermediate document created,


I know that's what has been decided so far, but I was wondering what was
the rationale behind it? Is there a specific benefit that comes from
allowing this behavior?


> we definitely need to better show
> this concept to the final user. It would be a pain to explain to a user
> that access rights for page children of an inexistent page is administrable
> from that inexistent page. It is also very poor when you navigate from the
> breadcrumb to a inexistent page as a normal user to reach "The requested
> page could not be found." with no way to navigate further.
>

Agreed.

These inexistent page are not necessarily invisible, there are links to
> them, and showing that as "error" page looks inappropriate IMO.


Agreed.


> So there are probably a couple of things we could do to improve this:
>
> A) display the list of children in addition to the actual message
>

As you point out below, this doesn't fully solve the navigation problem
since you can only go down, not further up.


> B) display a "default" and nice (not an error) dashboard on them that allow
> navigation (with a button for those that can edit, to create the page)
> C) create them all the time, with the dashboard above by default
>

To me, B) and C) are almost the same in the end, though I'm not sure a
dashboard is best. I'd rather create an empty page, with the list of
children available from the menu and/or in a tab in the footer, as on every
other standard page.


> D) do not propose links to those page in the breadcrumb to users without
> edit right on them ?
>

How would you then display the breadcrumb? With holes in it? It would also
make the breadcrumb inconsistent with the URL.


> E) ... (please add more idea)
>
> I am in favor of B) currently, since I do not think we are in an "error"
> case like A) seems to expose.
> I am wondering if D) could be useful as well to limit navigation to those
> page or not for user that will not find them so useful... but it may exists
> opposite UC.
>
> WDYT ?
>

I think my favorite one is C). I don't really like having pages that exist
from a rights management and hierarchy standpoint but not from a content
standpoint - but maybe there's a good reason for this that I'm missing?

Thanks,

Guillaume

--
> Denis Gervalle
> SOFTEC sa - CEO
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Improve the management of inexistent WebHome with children

Denis Gervalle-2
On Tue, Sep 29, 2015 at 4:54 PM, Guillaume Lerouge <[hidden email]>
wrote:

> Hi Denis,
>
> thanks for your message. Please see my thoughts below.
>
> On Tue, Sep 29, 2015 at 11:12 AM, Denis Gervalle <[hidden email]> wrote:
>
> > Hi devs,
> >
> > I am opening this discussion to move the discussion started in an issue
> > (XWIKI-12628) to its proper place, the ML. (Discussing into JIRA is very
> > bad since it lower the audience, we tend to have done it too much
> > recently).
> >
> > So the issue is that, in the Nested Document concept, we can create
> > children to inexistent (WebHome) page. This introduce some abnormalities:
> >  - Administering inexistent page (including page rights, see
> > http://jira.xwiki.org/browse/XWIKI-12629)
> >  - Children of inexistent page (see
> > http://jira.xwiki.org/browse/XWIKI-12628
> > )
> >
> > Since we agree that having nodes in the tree of pages is fine without
> > having the intermediate document created,
>
>
> I know that's what has been decided so far, but I was wondering what was
> the rationale behind it? Is there a specific benefit that comes from
> allowing this behavior?
>
>
> > we definitely need to better show
> > this concept to the final user. It would be a pain to explain to a user
> > that access rights for page children of an inexistent page is
> administrable
> > from that inexistent page. It is also very poor when you navigate from
> the
> > breadcrumb to a inexistent page as a normal user to reach "The requested
> > page could not be found." with no way to navigate further.
> >
>
> Agreed.
>
> These inexistent page are not necessarily invisible, there are links to
> > them, and showing that as "error" page looks inappropriate IMO.
>
>
> Agreed.
>
>
> > So there are probably a couple of things we could do to improve this:
> >
> > A) display the list of children in addition to the actual message
> >
>
> As you point out below, this doesn't fully solve the navigation problem
> since you can only go down, not further up.
>

That's not fully true, since you have the breadcrumb. What I do not like,
is that it looks first as an error page, then propose a way out. IMO those
"empty" node are not errors, just nodes without content, just there for
supporting their children.


>
>
> > B) display a "default" and nice (not an error) dashboard on them that
> allow
> > navigation (with a button for those that can edit, to create the page)
> > C) create them all the time, with the dashboard above by default
> >
>
> To me, B) and C) are almost the same in the end, though I'm not sure a
> dashboard is best. I'd rather create an empty page, with the list of
> children available from the menu and/or in a tab in the footer, as on every
> other standard page.
>
>
> > D) do not propose links to those page in the breadcrumb to users without
> > edit right on them ?
> >
>
> How would you then display the breadcrumb? With holes in it? It would also
> make the breadcrumb inconsistent with the URL.
>

All I was proposing here is to remove the link, not the text, so you cannot
click on them to reach them. I agree, this is far from a perfect solution,
but since we have the Sibling viewer, it is not really breaking the
navigability of the site. I was just suggesting here a way that limit the
situation where a normal user reach those page, that could also be seen as
useless to reach (else the user should had create it). Any other place with
a link to those page should be treated the same. So only user with the
ability to really act on those pages (administering or creating them) will
have link to access them.


>
> > E) ... (please add more idea)
> >
> > I am in favor of B) currently, since I do not think we are in an "error"
> > case like A) seems to expose.
> > I am wondering if D) could be useful as well to limit navigation to those
> > page or not for user that will not find them so useful... but it may
> exists
> > opposite UC.
> >
> > WDYT ?
> >
>
> I think my favorite one is C). I don't really like having pages that exist
> from a rights management and hierarchy standpoint but not from a content
> standpoint - but maybe there's a good reason for this that I'm missing?
>
> Thanks,
>
> Guillaume
>
> --
> > Denis Gervalle
> > SOFTEC sa - CEO
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Improve the management of inexistent WebHome with children

Guillaume Lerouge
Hi Denis,

On Tue, Sep 29, 2015 at 11:56 PM, Denis Gervalle <[hidden email]> wrote:

> On Tue, Sep 29, 2015 at 4:54 PM, Guillaume Lerouge <[hidden email]>
> wrote:
>
> > Hi Denis,
> >
> > thanks for your message. Please see my thoughts below.
> >
> > On Tue, Sep 29, 2015 at 11:12 AM, Denis Gervalle <[hidden email]> wrote:
> >
> > > Hi devs,
> > >
> > > I am opening this discussion to move the discussion started in an issue
> > > (XWIKI-12628) to its proper place, the ML. (Discussing into JIRA is
> very
> > > bad since it lower the audience, we tend to have done it too much
> > > recently).
> > >
> > > So the issue is that, in the Nested Document concept, we can create
> > > children to inexistent (WebHome) page. This introduce some
> abnormalities:
> > >  - Administering inexistent page (including page rights, see
> > > http://jira.xwiki.org/browse/XWIKI-12629)
> > >  - Children of inexistent page (see
> > > http://jira.xwiki.org/browse/XWIKI-12628
> > > )
> > >
> > > Since we agree that having nodes in the tree of pages is fine without
> > > having the intermediate document created,
> >
> >
> > I know that's what has been decided so far, but I was wondering what was
> > the rationale behind it? Is there a specific benefit that comes from
> > allowing this behavior?
>

One use case I've thought of since yesterday: when you move a page within a
hierarchy without moving its children. For instance: say you have "A/B/C"
and "D/E/F", then you move "B" to the end of "D/E/F" without moving B's
children. You end up with "D/E/F/B".

However, you probably still want to have something where "B" used to be in
"A/B/C", but with no content in there. Thus the need.


> > > we definitely need to better show
> > > this concept to the final user. It would be a pain to explain to a user
> > > that access rights for page children of an inexistent page is
> > administrable
> > > from that inexistent page. It is also very poor when you navigate from
> > the
> > > breadcrumb to a inexistent page as a normal user to reach "The
> requested
> > > page could not be found." with no way to navigate further.
> > >
> >
> > Agreed.
> >
> > These inexistent page are not necessarily invisible, there are links to
> > > them, and showing that as "error" page looks inappropriate IMO.
> >
> > Agreed.
> >
> >
> > > So there are probably a couple of things we could do to improve this:
> > >
> > > A) display the list of children in addition to the actual message
> > >
> >
> > As you point out below, this doesn't fully solve the navigation problem
> > since you can only go down, not further up.
>
> That's not fully true, since you have the breadcrumb. What I do not like,
> is that it looks first as an error page, then propose a way out. IMO those
> "empty" node are not errors, just nodes without content, just there for
> supporting their children.
>

Ok, I hadn't understood that the breadcrumb would still be shown.

> > B) display a "default" and nice (not an error) dashboard on them that
> > allow
> > > navigation (with a button for those that can edit, to create the page)
> > > C) create them all the time, with the dashboard above by default
> > >
> >
> > To me, B) and C) are almost the same in the end, though I'm not sure a
> > dashboard is best. I'd rather create an empty page, with the list of
> > children available from the menu and/or in a tab in the footer, as on
> every
> > other standard page.
> >
> >
> > > D) do not propose links to those page in the breadcrumb to users
> without
> > > edit right on them ?
> > >
> >
> > How would you then display the breadcrumb? With holes in it? It would
> also
> > make the breadcrumb inconsistent with the URL.
> >
>
> All I was proposing here is to remove the link, not the text, so you cannot
> click on them to reach them. I agree, this is far from a perfect solution,
> but since we have the Sibling viewer, it is not really breaking the
> navigability of the site. I was just suggesting here a way that limit the
> situation where a normal user reach those page, that could also be seen as
> useless to reach (else the user should had create it). Any other place with
> a link to those page should be treated the same. So only user with the
> ability to really act on those pages (administering or creating them) will
> have link to access them.
>

I see. Indeed, this could work.

Thanks,

Guillaume

>
> > > E) ... (please add more idea)
> > >
> > > I am in favor of B) currently, since I do not think we are in an
> "error"
> > > case like A) seems to expose.
> > > I am wondering if D) could be useful as well to limit navigation to
> those
> > > page or not for user that will not find them so useful... but it may
> > exists
> > > opposite UC.
> > >
> > > WDYT ?
> > >
> >
> > I think my favorite one is C). I don't really like having pages that
> exist
> > from a rights management and hierarchy standpoint but not from a content
> > standpoint - but maybe there's a good reason for this that I'm missing?
> >
> > Thanks,
> >
> > Guillaume
> >
> > --
> > > Denis Gervalle
> > > SOFTEC sa - CEO
> > >
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Improve the management of inexistent WebHome with children

Marius Dumitru Florea
In reply to this post by Denis Gervalle-2
On Wed, Sep 30, 2015 at 12:56 AM, Denis Gervalle <[hidden email]> wrote:

> On Tue, Sep 29, 2015 at 4:54 PM, Guillaume Lerouge <[hidden email]>
> wrote:
>
>> Hi Denis,
>>
>> thanks for your message. Please see my thoughts below.
>>
>> On Tue, Sep 29, 2015 at 11:12 AM, Denis Gervalle <[hidden email]> wrote:
>>
>> > Hi devs,
>> >
>> > I am opening this discussion to move the discussion started in an issue
>> > (XWIKI-12628) to its proper place, the ML. (Discussing into JIRA is very
>> > bad since it lower the audience, we tend to have done it too much
>> > recently).
>> >
>> > So the issue is that, in the Nested Document concept, we can create
>> > children to inexistent (WebHome) page. This introduce some abnormalities:
>> >  - Administering inexistent page (including page rights, see
>> > http://jira.xwiki.org/browse/XWIKI-12629)
>> >  - Children of inexistent page (see
>> > http://jira.xwiki.org/browse/XWIKI-12628
>> > )
>> >
>> > Since we agree that having nodes in the tree of pages is fine without
>> > having the intermediate document created,
>>
>>
>> I know that's what has been decided so far, but I was wondering what was
>> the rationale behind it? Is there a specific benefit that comes from
>> allowing this behavior?
>>
>>
>> > we definitely need to better show
>> > this concept to the final user. It would be a pain to explain to a user
>> > that access rights for page children of an inexistent page is
>> administrable
>> > from that inexistent page. It is also very poor when you navigate from
>> the
>> > breadcrumb to a inexistent page as a normal user to reach "The requested
>> > page could not be found." with no way to navigate further.
>> >
>>
>> Agreed.
>>
>> These inexistent page are not necessarily invisible, there are links to
>> > them, and showing that as "error" page looks inappropriate IMO.
>>
>>
>> Agreed.
>>
>>
>> > So there are probably a couple of things we could do to improve this:
>> >
>> > A) display the list of children in addition to the actual message
>> >
>>
>> As you point out below, this doesn't fully solve the navigation problem
>> since you can only go down, not further up.
>>
>
> That's not fully true, since you have the breadcrumb. What I do not like,
> is that it looks first as an error page, then propose a way out. IMO those
> "empty" node are not errors, just nodes without content, just there for
> supporting their children.
>
>
>>
>>
>> > B) display a "default" and nice (not an error) dashboard on them that
>> allow
>> > navigation (with a button for those that can edit, to create the page)
>> > C) create them all the time, with the dashboard above by default
>> >
>>
>> To me, B) and C) are almost the same in the end, though I'm not sure a
>> dashboard is best. I'd rather create an empty page, with the list of
>> children available from the menu and/or in a tab in the footer, as on every
>> other standard page.
>>
>>
>> > D) do not propose links to those page in the breadcrumb to users without
>> > edit right on them ?
>> >
>>
>> How would you then display the breadcrumb? With holes in it? It would also
>> make the breadcrumb inconsistent with the URL.
>>
>

> All I was proposing here is to remove the link, not the text, so you cannot
> click on them to reach them.

We don't necessarily have to remove the link. We can make the link
appear as plain text, as we do with the last breadcrumb item. This
will discourage the simple users from clicking on the link, while
still allowing the advanced users to access those nodes.

The only problem is that there won't be any visual difference between
a breadcrumb item that corresponds to:
* the current page
* a missing document
* a document for which the current user doesn't have view right

Does it matter?

I'm +1 for B for the moment.

Thanks,
Marius

> I agree, this is far from a perfect solution,
> but since we have the Sibling viewer, it is not really breaking the
> navigability of the site. I was just suggesting here a way that limit the
> situation where a normal user reach those page, that could also be seen as
> useless to reach (else the user should had create it). Any other place with
> a link to those page should be treated the same. So only user with the
> ability to really act on those pages (administering or creating them) will
> have link to access them.
>
>
>>
>> > E) ... (please add more idea)
>> >
>> > I am in favor of B) currently, since I do not think we are in an "error"
>> > case like A) seems to expose.
>> > I am wondering if D) could be useful as well to limit navigation to those
>> > page or not for user that will not find them so useful... but it may
>> exists
>> > opposite UC.
>> >
>> > WDYT ?
>> >
>>
>> I think my favorite one is C). I don't really like having pages that exist
>> from a rights management and hierarchy standpoint but not from a content
>> standpoint - but maybe there's a good reason for this that I'm missing?
>>
>> Thanks,
>>
>> Guillaume
>>
>> --
>> > Denis Gervalle
>> > SOFTEC sa - CEO
>> >
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs