[xwiki-users] [Brainstorming] Home Page concept (was Re: New Page Has No Parent)

[vinc...@massol.net]

Hi Edy and all,

On 5 Jan 2016 at 11:52:24, Eduard Moraru 
(enygma2...@gmail.com(mailto:enygma2...@gmail.com)) wrote:

> Hi Randy,
>  
> From your choice of words (and your continued usage of the now deprecated
> "spaces" macro on the homepage, as observed in the screenshot you`ve
> provided), I understand that you still see things in terms of "creating
> spaces" and "creating documents inside spaces" in 7.4 and, IMO, that`s
> really the issue.
>  
> In case you`ve missed it from the release notes, starting with 7.2, we`ve
> introduced the notion of Nested Pages [1], which means that you no longer
> have the notion of "pages inside spaces", but always "pages inside pages".
> Technically, it is actually implemented by always creating a "space" when
> you create a page from the UI, but the user should see it as if he is
> always creating a page.
>  
> = Use Case 1 =
>  
> When your users go to your homepage and create a new page "under the Main
> space", they are actually creating a nested page (old "space"), under the
> homepage (document called "Main") of your wiki. If you change [2] the
> homepage of your wiki to point to a different document instead (say
> "Some.Other.Homepage"), I`m fairly sure that you do not want your users to
> start creating new pages as children of that page (e.g.
> "Some.Other.Homepage.NewUserPage"), because that is what the alternative
> would lead to.
>  
> The logic behind the original decision of handling the homepage differently
> was that, even as Guillaume was hinting, the homepage is seen as the "root"
> of your wiki. Creating a page from the root should result in creating top
> level pages, not child pages. If you wanted to create a child page of
> something from the homepage, you would explicitly do so by selecting a
> parent. Not selecting a parent while on the homepage would logically imply
> that you want to create a page in the wiki (i.e. top page).
>  
> I`m curious why do you find it normal the other way around, i.e. landing on
> the wiki (i.e. not navigating somewhere in particular) + creating a new
> page => resulting in creating a child page of the "Main" page (which
> happens to be the homepage).
>  
> If you always create child pages of the homepage ("Main" page), on the long
> run, all your URLs will be /Main/This/Page, /Main/That/Page,
> /Main/That/Other/Page, etc... but ultimately, what is this "Main", and why
> is it that important to drag it along in all your page URLs? (of course,
> again, if you change your homepage to "Some.Other.Homepage", all your urls
> will be prefixed by that!)
>  
> = Use case 2 =
>  
> Now, another way of looking at this would be that, for some reason, you
> *really* want to keep all your content under some top level page (e.g. as
> Vincent suggested, a "Content" container page), perhaps to separate it from
> applications (which, for historic reasons, currently are also located in
> the top level) like Blog, Sandbox, etc. or any other reason.
>  
> The only limitation in this usecase is if you also want to use that
> container page ("Main", "Content", etc.) as your homepage. In this case,
> indeed, I see no other solution but to modify the createinline.vm template
> or for us to drop this behavior altogether.
>  
> ---
>  
> Conclusion so far:
> We have 2 use cases regarding a new page's parent. They can both coexist,
> except that, in some cases, the 2nd use case is limited by the first use
> case. If we consider this limitation to be a deal breaker, then we are left
> with 2 choices:
> A. Drop use case 1 (i.e. always propose the current page as parent of the
> new page, regardless if the current page is the homepage or not)
> B. Make use case 1 configurable (i.e. enable or disable it completely, in
> case you are suffering from the limitation of the second use case; this
> allows the user to decide if it's useful or not)
>  
> Of course, if option B is what we go for, we also need to figure out where
> we would put such a configuration.
>  
> I would be in favor of option B (since I obviously believe that use case 1
> is something useful for the majority of cases), but have no idea on the
> location of the configuration.
>  
> WDYT?

I agree about what you’ve said above. However I think the main problem comes 
from the fact that the user doesn’t know:
* That he’s on a special page (home page). He sees himself/herself on the 
Main/WebHome page, i.e. in the Main space.
* The user doesn’t realize that the home page of his/her wiki is a virtual page 
that can be configured to point to any page and that it just happens that by 
default it’s been set to point to Main.WebHome. 
* It can even be argued that the home page doesn’t exist and that the user is 
redirected to the page configured in the main wiki’s descriptor, i.e. 
Main.WebHome and thus when you click “+” to add a new page you’re not on the 
home page anywhere but on Main.WebHome.

So, I see 2 choices:

1) Option A, i.e. "drop use case 1 (i.e. always propose the current 

Re: [xwiki-users] [Brainstorming] Home Page concept (was Re: New Page Has No Parent)

[Eduard Moraru]

Hi Vincent,

Thanks for creating a new thread, since that`s what I should have done
myself.

I approached this as a discussion about what is the good/sensible default
that better fits 80-90% of the user's needs, as opposed to not having this
default and the user ending up with "Main" (or whetever else) everywhere
(i.e. cons of not doing Use Case 1).

On Wed, Jan 6, 2016 at 10:39 AM, vinc...@massol.net 
wrote:

> Hi Edy and all,
>
> On 5 Jan 2016 at 11:52:24, Eduard Moraru (enygma2...@gmail.com(mailto:
> enygma2...@gmail.com)) wrote:
>
> > Hi Randy,
> >
> > From your choice of words (and your continued usage of the now deprecated
> > "spaces" macro on the homepage, as observed in the screenshot you`ve
> > provided), I understand that you still see things in terms of "creating
> > spaces" and "creating documents inside spaces" in 7.4 and, IMO, that`s
> > really the issue.
> >
> > In case you`ve missed it from the release notes, starting with 7.2, we`ve
> > introduced the notion of Nested Pages [1], which means that you no longer
> > have the notion of "pages inside spaces", but always "pages inside
> pages".
> > Technically, it is actually implemented by always creating a "space" when
> > you create a page from the UI, but the user should see it as if he is
> > always creating a page.
> >
> > = Use Case 1 =
> >
> > When your users go to your homepage and create a new page "under the Main
> > space", they are actually creating a nested page (old "space"), under the
> > homepage (document called "Main") of your wiki. If you change [2] the
> > homepage of your wiki to point to a different document instead (say
> > "Some.Other.Homepage"), I`m fairly sure that you do not want your users
> to
> > start creating new pages as children of that page (e.g.
> > "Some.Other.Homepage.NewUserPage"), because that is what the alternative
> > would lead to.
> >
> > The logic behind the original decision of handling the homepage
> differently
> > was that, even as Guillaume was hinting, the homepage is seen as the
> "root"
> > of your wiki. Creating a page from the root should result in creating top
> > level pages, not child pages. If you wanted to create a child page of
> > something from the homepage, you would explicitly do so by selecting a
> > parent. Not selecting a parent while on the homepage would logically
> imply
> > that you want to create a page in the wiki (i.e. top page).
> >
> > I`m curious why do you find it normal the other way around, i.e. landing
> on
> > the wiki (i.e. not navigating somewhere in particular) + creating a new
> > page => resulting in creating a child page of the "Main" page (which
> > happens to be the homepage).
> >
> > If you always create child pages of the homepage ("Main" page), on the
> long
> > run, all your URLs will be /Main/This/Page, /Main/That/Page,
> > /Main/That/Other/Page, etc... but ultimately, what is this "Main", and
> why
> > is it that important to drag it along in all your page URLs? (of course,
> > again, if you change your homepage to "Some.Other.Homepage", all your
> urls
> > will be prefixed by that!)
> >
> > = Use case 2 =
> >
> > Now, another way of looking at this would be that, for some reason, you
> > *really* want to keep all your content under some top level page (e.g. as
> > Vincent suggested, a "Content" container page), perhaps to separate it
> from
> > applications (which, for historic reasons, currently are also located in
> > the top level) like Blog, Sandbox, etc. or any other reason.
> >
> > The only limitation in this usecase is if you also want to use that
> > container page ("Main", "Content", etc.) as your homepage. In this case,
> > indeed, I see no other solution but to modify the createinline.vm
> template
> > or for us to drop this behavior altogether.
> >
> > ---
> >
> > Conclusion so far:
> > We have 2 use cases regarding a new page's parent. They can both coexist,
> > except that, in some cases, the 2nd use case is limited by the first use
> > case. If we consider this limitation to be a deal breaker, then we are
> left
> > with 2 choices:
> > A. Drop use case 1 (i.e. always propose the current page as parent of the
> > new page, regardless if the current page is the homepage or not)
> > B. Make use case 1 configurable (i.e. enable or disable it completely, in
> > case you are suffering from the limitation of the second use case; this
> > allows the user to decide if it's useful or not)
> >
> > Of course, if option B is what we go for, we also need to figure out
> where
> > we would put such a configuration.
> >
> > I would be in favor of option B (since I obviously believe that use case
> 1
> > is something useful for the majority of cases), but have no idea on the
> > location of the configuration.
> >
> > WDYT?
>
> I agree about what you’ve said above. However I think the main problem
> comes from the fact that the user doesn’t know:
> * That he’s on a special page (home page). He sees himself/herself on the
> 

Re: [xwiki-users] [Brainstorming] Home Page concept (was Re: New Page Has No Parent)

[Guillaume Lerouge]

Hi,

On Wed, Jan 6, 2016 at 1:54 PM, Eduard Moraru  wrote:

> Hi Vincent,
>
> Thanks for creating a new thread, since that`s what I should have done
> myself.
>
> I approached this as a discussion about what is the good/sensible default
> that better fits 80-90% of the user's needs, as opposed to not having this
> default and the user ending up with "Main" (or whetever else) everywhere
> (i.e. cons of not doing Use Case 1).
>
> On Wed, Jan 6, 2016 at 10:39 AM, vinc...@massol.net 
> wrote:
>
> > Hi Edy and all,
> >
> > On 5 Jan 2016 at 11:52:24, Eduard Moraru (enygma2...@gmail.com(mailto:
> > enygma2...@gmail.com)) wrote:
> >
> > > Hi Randy,
> > >
> > > From your choice of words (and your continued usage of the now
> deprecated
> > > "spaces" macro on the homepage, as observed in the screenshot you`ve
> > > provided), I understand that you still see things in terms of "creating
> > > spaces" and "creating documents inside spaces" in 7.4 and, IMO, that`s
> > > really the issue.
> > >
> > > In case you`ve missed it from the release notes, starting with 7.2,
> we`ve
> > > introduced the notion of Nested Pages [1], which means that you no
> longer
> > > have the notion of "pages inside spaces", but always "pages inside
> > pages".
> > > Technically, it is actually implemented by always creating a "space"
> when
> > > you create a page from the UI, but the user should see it as if he is
> > > always creating a page.
> > >
> > > = Use Case 1 =
> > >
> > > When your users go to your homepage and create a new page "under the
> Main
> > > space", they are actually creating a nested page (old "space"), under
> the
> > > homepage (document called "Main") of your wiki. If you change [2] the
> > > homepage of your wiki to point to a different document instead (say
> > > "Some.Other.Homepage"), I`m fairly sure that you do not want your users
> > to
> > > start creating new pages as children of that page (e.g.
> > > "Some.Other.Homepage.NewUserPage"), because that is what the
> alternative
> > > would lead to.
> > >
> > > The logic behind the original decision of handling the homepage
> > differently
> > > was that, even as Guillaume was hinting, the homepage is seen as the
> > "root"
> > > of your wiki. Creating a page from the root should result in creating
> top
> > > level pages, not child pages. If you wanted to create a child page of
> > > something from the homepage, you would explicitly do so by selecting a
> > > parent. Not selecting a parent while on the homepage would logically
> > imply
> > > that you want to create a page in the wiki (i.e. top page).
> > >
> > > I`m curious why do you find it normal the other way around, i.e.
> landing
> > on
> > > the wiki (i.e. not navigating somewhere in particular) + creating a new
> > > page => resulting in creating a child page of the "Main" page (which
> > > happens to be the homepage).
> > >
> > > If you always create child pages of the homepage ("Main" page), on the
> > long
> > > run, all your URLs will be /Main/This/Page, /Main/That/Page,
> > > /Main/That/Other/Page, etc... but ultimately, what is this "Main", and
> > why
> > > is it that important to drag it along in all your page URLs? (of
> course,
> > > again, if you change your homepage to "Some.Other.Homepage", all your
> > urls
> > > will be prefixed by that!)
> > >
> > > = Use case 2 =
> > >
> > > Now, another way of looking at this would be that, for some reason, you
> > > *really* want to keep all your content under some top level page (e.g.
> as
> > > Vincent suggested, a "Content" container page), perhaps to separate it
> > from
> > > applications (which, for historic reasons, currently are also located
> in
> > > the top level) like Blog, Sandbox, etc. or any other reason.
> > >
> > > The only limitation in this usecase is if you also want to use that
> > > container page ("Main", "Content", etc.) as your homepage. In this
> case,
> > > indeed, I see no other solution but to modify the createinline.vm
> > template
> > > or for us to drop this behavior altogether.
> > >
> > > ---
> > >
> > > Conclusion so far:
> > > We have 2 use cases regarding a new page's parent. They can both
> coexist,
> > > except that, in some cases, the 2nd use case is limited by the first
> use
> > > case. If we consider this limitation to be a deal breaker, then we are
> > left
> > > with 2 choices:
> > > A. Drop use case 1 (i.e. always propose the current page as parent of
> the
> > > new page, regardless if the current page is the homepage or not)
> > > B. Make use case 1 configurable (i.e. enable or disable it completely,
> in
> > > case you are suffering from the limitation of the second use case; this
> > > allows the user to decide if it's useful or not)
> > >
> > > Of course, if option B is what we go for, we also need to figure out
> > where
> > > we would put such a configuration.
> > >
> > > I would be in favor of option B (since I obviously believe that use
> case
> > 1
> >